Le redouté problème de boucle de redirection de connexion au panneau d'administration WordPress "Reauth = 1" m'a mordu cette fois, et je partage les informations sur la façon dont je l'ai corrigé, dans ce post. Je ne suis en aucun cas un expert des trucs Apache, Linux ou WordPress, mais les informations ici peuvent aider ceux qui se trouvent confrontés à la même situation.
L'une des trois modifications de configuration que j'ai apportées au panneau de configuration d'hébergement a provoqué la boucle de connexion de l'administrateur WordPress.
Changement 1
J'ai attaché mon domaine à CloudFlare et installé le plugin CloudFlare WordPress. Le CDN a parfaitement fonctionné.
Changer 2
Dans Plesk Control Panel, je me suis connecté à mon installation WordPress. Plesk a montré un panneau rouge près de mon installation WordPress qui, lorsque je clique dessus, me demande de vérifier la sécurité de mon installation WordPress. Ça disait:
Affichez les résultats du contrôle de sécurité pour les installations WordPress sélectionnées. Si certaines données n'ont pas réussi le contrôle de sécurité, vous pouvez sélectionner ces données dans la liste et renforcer leur sécurité.
Je sélectionne Clés de sécurité dans la liste et clique sur Sécurisé.
La description de la clé de sécurité indique:
WordPress utilise des clés de sécurité (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY et NONCE_KEY) pour assurer un meilleur cryptage des informations stockées dans les cookies de l'utilisateur…. Si le contrôle de sécurité a échoué et que vous choisissez de sécuriser l'installation de WordPress, de bonnes clés de sécurité seront générées et ajoutées pour votre installation WordPress.
Changer 3
Démarrage de nginx à partir de la gestion des services dans Plesk.
Boucle de connexion
La prochaine fois que j'ai essayé de me connecter à WordPress, il a simplement redirigé vers la page "Reauth = 1". Si j'ai délibérément tapé un mauvais mot de passe, il a dit que le mot de passe était incorrect. Ainsi, les éléments d'authentification fonctionnaient bien, mais pour une raison quelconque, ils étaient redirigés vers l'URL Reauth lorsque des informations d'identification correctes étaient utilisées. Voici une liste de choses que j'ai essayées, et aucune d'entre elles (sauf, peut-être # 15 ci-dessous) n'a aidé.
- Vider complètement le cache du navigateur Web et essayer différents navigateurs.
- Nginx arrêté, comme lu sur un problème de mise en cache (nginx.conf)
- Plugin CloudFlare désactivé via Plesk, car il a cassé les fonctionnalités de WP Admin pour certains utilisateurs
- Tous les plugins désactivés et redémarré le serveur
- Optimisation et réparation de la base de données via PhpMyAdmin
- URL du site vérifiée dans la table wp_options. C'était correct
- Autorisations vérifiées pour les fichiers wp-config, wp-admin et wp-includes
- WP_HOME et WP_SITEURL ajoutés dans wp-config.php
- Généré de nouveaux codes de clé SALT ou Secret et ajouté à wp-config.php
- Activé le thème Twenty Sixteen
- Publié dans les forums WordPress, et absolument aucune réponse
- Restauration de mon site à partir de la sauvegarde VaultPress la plus récente
- Mode de développement activé dans CloudFlare
- Définissez CloudFlare PageRule pour contourner la mise en cache des pages d'administration (WP- *)
- Détaché mon site de CloudFlare
Il y a eu beaucoup d'autres choses que j'ai faites en plus de ce qui précède, dont certaines peuvent être triviales. J'envisageais sérieusement ces options:
- Recherchez l'aide professionnelle de CloudTech (via MT Admin Panel) pour 79 $, mais un correctif n'est pas garanti.
- Réinitialisez Plesk DV aux paramètres par défaut. Mais tout restaurer prendrait beaucoup de temps.
- Demande de restauration d'urgence, encore une fois pour 79 $. Seul le contenu du site est restauré, ce que j'ai déjà fait depuis VaultPress.
- Jeter le serveur et passer à l'hébergement WordPress Premium géré par le même fournisseur. Il utilise ainsi les paramètres de serveur par défaut.
- Si le support de MT n'a pas aidé, passez à DreamHost
Beaucoup d'idées me traversaient l'esprit et une journée entière a été perdue. Quelques heures après avoir détaché mon site de CloudFlare, WordPress lance maintenant un message d'erreur différent. Il indique désormais "Les cookies sont bloqués", bien que tous mes navigateurs Web soient configurés pour accepter les cookies.
A corrigé Atlast!
Étape 1:
Dans la config wp, j'ai supprimé ces lignes qui contenaient les clés secrètes:
define ('AUTH_KEY' define ('SECURE_AUTH_KEY' define ('LOGGED_IN_KEY' define ('NONCE_KEY' define ('AUTH_SALT' define ('SECURE_AUTH_SALT' define ('LOGGED_IN_SALT' define ('NONCE_SALT' Étape 2:
Enregistré le fichier avec l'encodage UTF-8 (il montrait comme ANSI). Bien que cela ne soit PAS à l'origine du problème… mais je viens de l'essayer.
Enfin, j'ai pu me connecter au panneau d'administration WordPress. J'ai ensuite généré de nouvelles clés de sécurité, déconnecté de WordPress et reconnecté. Ça a marché!
Qu'est-ce qui a causé le problème en premier lieu?
Alors que la plupart des publications sur Internet pointaient vers le récent plugin CloudFlare, ce n'était pas le cas dans mon cas. Je suppose que le contrôle de sécurité de Plesk (dans le changement n ° 2 ci-dessus) l'a cassé, car ce n'est qu'après avoir supprimé les clés secrètes du wp-config.php que j'ai été autorisé à me connecter. Bien sûr, j'ai ensuite généré de nouvelles clés de sécurité, mis à jour wp-config.php. J'ai ensuite re-attaché mon site à CloudFlare et activé leur plugin.
Heureusement, le problème n'est pas apparu jusqu'à présent!
Morale de l'histoire (je me suis dit): ne jouez pas avec les paramètres de Plesk si vous ne savez pas ce que vous faites. Et faites un changement à la fois et cela aussi seulement si c'est absolument nécessaire, afin que vous sachiez quel paramètre est à l'origine d'un problème. Linux / Apache n'est pas comme Windows… ils sont plus complexes, du moins pour moi. Si ce message vous a aidé ou si vous avez des informations supplémentaires pour résoudre ce problème, veuillez partager vos réflexions dans la section Commentaires ci-dessous.
