6

I have set up a Drush alias for my website (hosted on a shared hosting), the alias works correctly, because commands like drush status, drush cc all, etc. work. The problem comes with drush uli. It generates the one-time login link, the domain is correct, everything looks all right, but when entered into a browser, it results in standard Drupal

Access Denied

page.

Part of setting up the alias and some interesting issues around path-alias-es, relations to database settings, it's usage and relevancy the aliases is originally discussed in Drush issues page on GitHub.

Technical information:

  • This is a clean Drupal 7 installation, without contrib modules.
  • I can log in using password (even using password set via drush upwd using the same alias).
  • I have checked all possible sources (like truncating sessions table, etc.) discussed in similar but yet different issue on StackExchange.
  • I have tried different browsers and cleared browser caches and cookies as suggested in various similar discussions on Drupal.org, all without luck.

Drush alias:

$aliases['myalias'] = array(
  'uri' => 'mysite.com',
  'root' => '/home/mysite.com/web',
  'path-aliases' => array(
    '%drush' => '/home/.composer/vendor/drush/drush',
   ),
  '%files' => '/home/mysite.com/web/sites/mysite.com/files',
); 

The alias works correctly for other commands like clearing caches and drush status confirms that Drupal is bootstrapped correctly.

  • are you using uri parameter ? – Himanshu Pathak Oct 30 '15 at 10:31
  • @DavidLukac On which URI you have Access Denied? Does it recognise the token and redirects first? – kenorb Oct 30 '15 at 10:36
  • @HimanshuPathak The URI is directly in the alias. – David Lukac Oct 30 '15 at 13:18
  • @kenorb The Access Denied is directly on the token URL. The watchdog says: 415 | 0 | access denied | user/reset/1/1445605040/kxvcztB8oYE5PdRDS02j_Gsef_5eI1gcSvzuSenzotE/login | ... http://example.com/user/reset/1/1445605040/kxvcztB8oYE5PdRDS02j_Gsef_5eI1gcSvzuSenzotE/login so the location and URI and URL all seem to be correct. – David Lukac Oct 30 '15 at 13:22
  • @DavidLukac Do you have Access Denied when you're using invalid token? I've tested this link and it gets redirected (so it recognised that the token is not right) and it's showing the message You have tried to use a one-time login ..., so at least not Access Denied. – kenorb Oct 30 '15 at 13:25
7

This can happen when the user is blocked. Setting the status to 1 in the Users table may resolve it.

  • Thanks, this worked for me. One would think drush does that validation first – Piyin Sep 29 '17 at 19:21
  • Beware. The command drush uli logs you in as user 1 by default. User 1 is often blocked for a reason: it can bypass any access checks, so the account is a potential security risk (especially as its username is often the same across sites, "admin"). The solution is to set up a different user account with as many administrator permissions as you need, which you could do once via user 1 (then block it). Use drush uli UID, drush uli 'username' or drush uli email@example.com to log in as that user. – pjcdawkins Nov 3 '17 at 8:42
2

I'm not exactly sure why the drush uli gets to Access Denied. I suspect it's something with validation/generation of the one time links and/or incorrect timestamp in the users table.

The solution was deleting the password in the database. (Changing it via drush upwd or directly in Drupal didn't work.) After deleting the user's password I was able to run drush uli.

  • when you say 'delete password' do you mean delete values in users.pass? – petednz - fuzion Jun 8 '17 at 10:22
  • @petednz-fuzion Per this comment, yes. – rovr138 Aug 8 '17 at 17:04
  • Thanks for clarifying that "I deleted the password in the database" == "delete values in users.pass field" – petednz - fuzion Aug 8 '17 at 18:38
  • drush upwd worked for me! – Eric Johnson Sep 27 '17 at 20:45
  • Beware... as I mentioned above, user 1 is an account you should be protecting carefully. Of course if it's your development site on a local machine, go ahead by all means. – pjcdawkins Nov 3 '17 at 8:50
1

Also check the flood table. Its possible there are records that are failed attempts by IP address that are blocking access.

1

Just ran across this in a local dev setup.. turned out to be the $cookie_domain setting that was committed in settings.php... if this is set to the production URL, you will not get a valid cookie, and therefore access will never be granted. Overriding $cookie_domain to match the local dev environment in local-settings.php did the trick!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.