web-dev-qa-db-fra.com

`drush uli` génère un lien correct mais résulte en 'Accès refusé'

J'ai configuré un alias Drush pour mon site Web (hébergé sur un hébergement partagé), l'alias fonctionne correctement, car des commandes comme drush status, drush cc all, etc. travail. Le problème vient avec drush uli. Il génère le lien de connexion unique, le domaine est correct, tout semble correct, mais lorsqu'il est entré dans un navigateur, il en résulte standard Drupal

Accès refusé

page.

Partie de la configuration de l'alias et quelques problèmes intéressants autour de path-alias- es, les relations avec les paramètres de la base de données, son utilisation et sa pertinence, les alias sont à l'origine discutés dans page des problèmes de Drush sur GitHub .

Informations techniques:

  • Il s'agit d'une installation propre Drupal 7, sans modules contrib.
  • Je peux me connecter en utilisant un mot de passe (même en utilisant un mot de passe défini via drush upwd en utilisant le même alias).
  • J'ai vérifié toutes les sources possibles (comme tronquer la table sessions, etc.) discutées dans problème similaire mais différent sur StackExchange.
  • J'ai essayé différents navigateurs et effacé les caches et cookies de navigateur, comme suggéré dans diverses discussions similaires sur Drupal.org, le tout sans succès.

Alias ​​Drush:

$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',
);

L'alias fonctionne correctement pour d'autres commandes telles que l'effacement des caches et drush status confirme que Drupal est correctement démarré.

7drush
8
David Lukac

Je ne sais pas exactement pourquoi le drush uli arrive à Accès refusé. Je soupçonne que c'est quelque chose avec la validation/génération des liens à usage unique et/ou un horodatage incorrect dans la table tilisateurs.

La solution supprimait le mot de passe dans la base de données. (Le changer via drush upwd ou directement dans Drupal n'a pas fonctionné.) Après avoir supprimé le mot de passe de l'utilisateur, j'ai pu exécuter drush uli.

2
David Lukac

Cela peut se produire lorsque l'utilisateur est bloqué. La définition de l'état sur 1 dans le tableau Utilisateurs peut le résoudre.

9
xtfer

Je viens de le rencontrer dans une configuration de développement local .. s'est avéré être le $cookie_domain paramètre validé dans settings.php... si ce paramètre est défini sur l'URL de production, vous obtiendrez pas un cookie valide, et l'accès ne sera donc jamais accordé. Remplacement $cookie_domain pour correspondre à l'environnement de développement local dans local-settings.php a fait l'affaire!

2
Tyler Fahey

Vérifiez également le table d'inondation . Il est possible qu'il existe des enregistrements qui sont des tentatives infructueuses par adresse IP qui bloquent l'accès.

2
Scott Shipman