Hey guys,

I had a few hours today to scratch a long-standing personal itch, having to do with needing to authenticate twice before getting to work on a Drupal site... first via SSH, and then via /user.

The result is a drush command that will print to the console a one-time use login link to the current website.


alex@viper:~$ cd /var/shared/sites/crdcn/site

alex@viper:/var/shared/sites/crdcn/site$ ls
CHANGELOG.txt  cron.php  index.php          INSTALL.pgsql.txt  INSTALL.txt  MAINTAINERS.txt  modules   robots.txt  sites   update.php   xmlrpc.php
COPYRIGHT.txt  includes  INSTALL.mysql.txt  install.php        LICENSE.txt  misc             profiles  scripts     themes  UPGRADE.txt

#by default it assumes you want to login as 'admin'
alex@viper:/var/shared/sites/crdcn/site$ drush login-link
Use one of the following URLs to automatically log in to your site:                                                                                                                                 [success]
http://crdcn.ewdev.ca/user/reset/1/1277413816/f5db5c699ca2bc8760eabf895534c2d5/login                                                                                                                [ok]

#allows lookup by uid or by username...
alex@viper:/var/shared/sites/crdcn/site$ drush login-link 5
alex@viper:/var/shared/sites/crdcn/site$ drush login-link --username=dave

#ll is an alias for 'login-link'
alex@viper:/var/shared/sites/crdcn/site$ drush ll 
Use one of the following URLs to automatically log in to your site:                                                                                                                                 [success]
http://crdcn.ewdev.ca/user/reset/1/1277413811/05fc8fceae8ad5a08b2e2e911e787eb4/login                                                                                                                [ok]

I'm assuming that being able to execute a drush command means you have full control of the site. Is that a fair assumption?

Note that because usually Drush doesn't have access to the site URI, this command tries to pull it out of the watchdog table.
Thanks to this, placing the file login_link.drush.inc into /opt/drush/commands makes it work with every site on my server.

Making a Drupal module out of this is overkill, and a module would need to be installed for each Drupal site on a server.
I'm not sure if this belongs as a core drush command, but thought I'd put it out there.
If not, what's the conventional method for sharing Drush commands with the community?

Thanks,
Alex Dergachev
Co-Founder, Evolving Web
http://evolvingweb.ca

CommentFileSizeAuthor
#5 login_link_refactored.txt3.18 KBdergachev
login_link.drush_.inc_.txt3.46 KBdergachev

Comments

moshe weitzman’s picture

moshe weitzman commented
Project: Drush » Drush extras
Version: » 7.x-1.x-dev

Moving to drush_extras project. Its too specialized for drush core IMO.

the way to gain the uri is for the the command to receive a --url option. you can hard code that once in a drushrc.php file so you never have to think about it.

dergachev’s picture

dergachev commented

@moshe,

Agreed, this isn't necessarily something "robust" enough to include with Drush Core.
Is drush_extras going to be a Drupal module, or a suite of Drush plugins?
I would imagine that with most drush commands, (as with shell scripts), you'd want to install them once per server, not per Drupal project.
Is there a concept of a "Drush plugin" that would fit this?

greg.1.anderson’s picture

greg.1.anderson commented

A "drush plugin" is a Drupal "module" that does not have any Drupal module code in it, but does contain drush commands. Drush recognises such a module as a drush plugin, and will store it in a common location (e.g. $HOME/.drush) rather than sites/all/modules. Try drush dl drush_make to see it work.

I'm backlogged on a lot of my drush tasks, including checking in the drush_extras project, but when I create it, it will behave as described above.

dergachev’s picture

dergachev commented

Replying to Moshe's comment in the blog post: http://evolvingweb.ca/story/login-command-line-drush-login-link#comment-116

Relying on the --uri is how the command was originally intended to be used. And if you do provide a domain with the --uri or drushrc, the command will use it, falling back to the watchdog table only when necessary.

Most developers don't have a drushrc specifying a domain for each of perhaps a dozen sites on a server. The main benefit of this command is to save a little bit of typing, and scouring the watchdog table is a (surprisingly effective) hack to achieve that.

The fact that I resorted to such unsatisfying hack suggests that the Drupal DB could (somehow) a "default" domain to be associated with the site, which could be overriden by the actual domain specified by Apache. I suspect there must be lots of other Drush commands that will be hobbled by this deficiency.

dergachev’s picture

dergachev commented
StatusFileSize
new login_link_refactored.txt3.18 KB

James McKinney, one of our developers, cleaned up the code considerably.

greg.1.anderson’s picture

greg.1.anderson commented

Yeah, I'm not terribly happy about the watchdog-table business either. A few comments on it. First, it will need to work with postgres before it can be committed. Second, I'm a bit concerned about performance of the 'distinct', etc. when the watchdog table gets large. And finally, I think that base url handling should be in drush core rather than in one particular command.

Of course, I'll be flexible on the last one, as I don't think an unsatisfying solution such as searching the watchdog table is likely to get committed there. At a minimum, you should factor out a function to find the base url, and call that from drush_login_link.

Yes, base url handling is a problem for a number of drush commands and use cases, and the usual solution is to insure that --uri is always specified correctly for your site. This does not always work well, though, e.g. with site aliases, --uri must match the name of the folder in 'sites', so if you use 'default' for the folder name, then --uri will never be correct when you're using site aliases. Drush core could use some improvement vis-a-vis the base url handling in drush 4.

greg.1.anderson’s picture

greg.1.anderson commented
Status: Needs review » Needs work
dergachev’s picture

dergachev commented
Status: Needs work » Needs review

@greg.1.anderson

That's just the explanation I was hoping to get, thanks!

greg.1.anderson’s picture

greg.1.anderson commented
Status: Needs review » Needs work

Simultaneous editing changed the status back to 'needs review'; pls at least fix postgres compatibility and factor out a separate watchdog function here prior to commit.

moshe weitzman’s picture

moshe weitzman commented
Status: Needs work » Closed (duplicate)

Committed a simpler version at #942642: Add command allowing to impersonate as any user

bulldozer2003’s picture

bulldozer2003
king/sire
commented

Since this thread comes up near the top in search engines, drush currently includes the user-login (uli) command for this.

$ drush help user-login
Display a one time login link for the given user account (defaults to uid 1).

Examples:
 drush user-login ryan node/add/blog       Displays and opens default web browser (if configured or    
                                           detected) for a one-time login link for the user with the   
                                           username ryan and redirect to the path node/add/blog.       
 drush user-login --browser=firefox        Open firefox web browser, login as the user with the e-mail 
 --mail=drush@example.org                  address drush@example.org and redirect to the path          
 admin/settings/performance                admin/settings/performance.

Arguments:
 user                                      An optional uid, user name, or email address for the user to 
                                           log in as. Default is to log in as uid 1. The uid/name/mail  
                                           options take priority if specified.                          
 path                                      Optional path to redirect to after logging in.

Options:
 --browser                                 Optional value denotes which browser to use (defaults to  
                                           operating system default). Set to 0 to suppress opening a 
                                           browser.                                                  
 --mail                                    A user mail address to log in as.                         
 --name                                    A user name to log in as.                                 
 --uid                                     A uid to log in as.

Aliases: uli