10

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.

Improve this question
6
  • are you using uri parameter ?
    – Himanshu Pathak
    Oct 30, 2015 at 10:31
  • @DavidLukac On which URI you have Access Denied? Does it recognise the token and redirects first?
    – kenorb
    Oct 30, 2015 at 10:36
  • @HimanshuPathak The URI is directly in the alias.
    – David Lukac
    Oct 30, 2015 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, 2015 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, 2015 at 13:25

4 Answers 4

Reset to default
15

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

Improve this answer
4
  • 1
    Thanks, this worked for me. One would think drush does that validation first
    – Piyin
    Sep 29, 2017 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 protected] to log in as that user.
    – pjcdawkins
    Nov 3, 2017 at 8:42
  • Unblock the user via drush: drush user:unblock admin
    – Achraf JEDAY
    Jan 9, 2020 at 13:34
  • Print user information using drush: drush user-information 1
    – Achraf JEDAY
    Jan 9, 2020 at 13:37
5

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!

Improve this answer
3

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

Improve this answer
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.

Improve this answer
5
  • when you say 'delete password' do you mean delete values in users.pass?
    – petednz - fuzion
    Jun 8, 2017 at 10:22
  • @petednz-fuzion Per this comment, yes.
    – rovr138
    Aug 8, 2017 at 17:04
  • Thanks for clarifying that "I deleted the password in the database" == "delete values in users.pass field"
    – petednz - fuzion
    Aug 8, 2017 at 18:38
  • drush upwd worked for me!
    – Eric Johnson
    Sep 27, 2017 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, 2017 at 8:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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