| Project: | Drush extras |
| Version: | 7.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (duplicate) |
Issue Summary
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
| Attachment | Size |
|---|---|
| login_link.drush_.inc_.txt | 3.46 KB |
Comments
#1
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.
#2
@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?
#3
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_maketo 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.
#4
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.
#5
James McKinney, one of our developers, cleaned up the code considerably.
#6
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.
#7
#8
@greg.1.anderson
That's just the explanation I was hoping to get, thanks!
#9
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.
#10
Committed a simpler version at #942642: Add command allowing to impersonate as any user