web-dev-qa-db-fra.com

Personne ne peut se connecter et accéder au message refusé

Le site a fonctionné jusqu'à hier et tout à l'heure, il se comporte étrangement.

  • Le site est pas créé avec des fonctionnalités, un vidage d'archive comprenant le code et la base de données est copié sur le serveur, et l'ancienne installation est remplacée manuellement par la nouvelle (malheureusement). Maintenant, c'est irrelavant qui se passe également sur le serveur local.
  • Aucun module de mise en cache n'est installé. L'API de session n'est pas également installée.
  • Le thème est défini sur "sept" (thème d'administration principal, au cas où).
  • Le chien de garde ne contient aucune erreur, avertissement ou information à l'exception de la "session ouverte pour l'utilisateur xyz" habituelle;
  • Le fichier de paramètres ne contient aucune directive de cookie spéciale. Ça ne l'a jamais fait.
  • Le site fonctionne sur php 5.6, Apache 2.2, CentOS 6. PHP fonctionne en tant que fast-cgi. Comme toujours.
  • C'est Drupal 7.

Je vais sur example.com/user/login, saisissez le nom d'utilisateur et le mot de passe, le formulaire est envoyé avec succès, la page est redirigée vers example.com/user/%uid (essayé à la fois uid 1 et d'autres utilisateurs). et boum! J'obtiens un accès refusé . Et l'utilisateur n'est pas connecté.

Si je tronque la table sessions avec truncate table sessions Je peux me connecter une seule fois, avec n'importe quel utilisateur. Là encore, personne ne peut se connecter, même pas uid 1.

Également avec un lien de réinitialisation de mot de passe (en utilisant la commande drush uli Je peux me connecter sans problème).

J'ai désactivé tous les modules contrib et le thème, mais le même problème persiste.

Qu'est-ce qui cause de tels problèmes avec les sessions? des idées?

7userssessions
7
hkoosha

Le problème était ip_geoloc module. Il gâchait la variable $ _SESSION, une solution est donnée sur la file d'attente des problèmes (pour l'instant!) Et l'auteur du module est d'accord. Il est très probable que cela se produise en raison d'une mauvaise configuration de ma part. L'utilisateur a réussi à se connecter, mais immédiatement sa session a été invalidée. D'une manière ou d'une autre, sa désactivation ne suffisait pas et son répertoire devait être déplacé hors de Drupal. Je suis sûr à 100% qu'aucune de ses fonctions ou API n'est utilisée ailleurs. Peut-être un problème de cache?

Leçon apprise:

En cas de problème de connexion, essayez de vérifier la variable $ _SESSION sur le serveur en utilisant devel et ses fonctions d'aide (par exemple dpm , dsm , dd , ... ou en dernier recours var_export) et pas avec votre console de développeur google/firefox.

C'est la troisième fois que je fais face à ce comportement étrange et la première fois que j'ai pu réparer. Si vous rencontrez ce problème, essayez de suivre cette liste de contrôle:

Demande toi:

  • La troncature de la table sessions résout-elle le problème?
  • forçant une modification du mot de passe utilisateur résout-il le problème?
  • Avez-vous ajouté une configuration particulière à votre settings.php? par exemple base_url, cookie_domain, ...
  • UID 0 existe-t-il dans votre base de données (c'est-à-dire utilisateur anonyme)?
  • Un module - redirection est-il installé? search404 , redirect , global_redirect , ...
  • Avez-vous un module personnalisé activé?
  • Y a-t-il des problèmes avec votre thème?
  • Avez-vous des modules modifiant le chemin, par exemple path_alias?
  • Avez-vous un module modifiant le comportement de connexion? par exemple logintoboggan
  • Avez-vous activé un module de mise en cache? par exemple authcache , memcache , session_cache , boost , vernis , ...
  • Avez-vous un module de contrôle d'accès activé? par exemple, établi, content_access, acl, og_access, ...
  • Et enfin, avez-vous activé un module qui change l'utilisateur $ _SESSION? par exemple session_api , session_cache , ip_geoloc , ...

Lieux à visiter/Choses à faire

  • Regardez les messages de surveillance des drupals. Si vous ne pouvez pas vous connecter, utilisez drush watchdog-show --tail pour voir ce qui se passe.
  • Si vous exécutez Apache et mod-php, consultez le journal des erreurs d'Apache, généralement dans/var/log/Apache/error_log pour les systèmes * nix.
  • Si vous exécutez php-fpm, consultez le journal php-fpm, assurez-vous qu'il n'y a pas de problème de communication avec le démon php, comme les en-têtes ne sont pas perdus. si vous ne voyez aucun journal des erreurs, essayez d'exécuter votre site avec le serveur interne drush/php. la commande est drush rs ou drush rs the.ip.goes.here:thePort
  • faire une sauvegarde complète, désactiver tous les modules avec cette commande APRÈS avoir fait une sauvegarde complète (vous pouvez faire une sauvegarde avec drush ard ou simplement la base de données drush sql-dump > db.sql ou utiliser le module backup_migrate)
    drush dis -y $(drush pml --nocore --status=enabled --pipe) -> cette commande ne fonctionne que dans les systèmes * nix, je ne connais pas la traduction directe pour Windows.
  • Définissez votre thème par défaut sur quelque chose de ... sûr! comme sept ou guirlande. Si vous ne pouvez pas vous connecter, utilisez ces commandes drush:
    drush en seven && drush vset theme_default seven;
  • Surveillez la variable $ _SESSION avec n'importe quel outil de débogage, voyez si son contenu est correct, ok, sain.
  • Pour tous les processus et démons impliqués dans le traitement d'une requête (nginx, php-fpm, Apache, vernis ...) assurez-vous qu'ils ont tous un accès en écriture à leur répertoire tmp.

Bonne chance pour le débogage!

13
hkoosha

Ce qui a fonctionné pour moi, c'était d'activer et de configurer le $cookie_domain variable dans settings.php (car j'ai un site accessible par 2 domaines différents).

Faites attention au commentaire avant cette variable! Le nom de domaine doit commencer par un point. EX:

$cookie_domain = '.example.com';

Bonne chance!

4
Heitor Althmann