WordPress "Reauth = 1" Anmeldeschleife und "Cookies sind blockiert" Fehler. Wie habe ich das behoben?

Das gefürchtete Problem mit der Anmelde-Umleitungsschleife für das Admin-Panel von WordPress "Reauth = 1" hat mich diesmal gebissen, und ich teile die Informationen darüber, wie ich es behoben habe, in diesem Beitrag. Ich bin kein Experte für Apache, Linux oder WordPress, aber die Informationen hier können anderen helfen, die sich der gleichen Situation gegenübersehen.

Eine der drei Konfigurationsänderungen, die ich in der Hosting-Systemsteuerung vorgenommen habe, verursachte die Anmeldeschleife für WordPress Admin.

Änderung 1

Ich habe meine Domain an CloudFlare angehängt und das CloudFlare WordPress Plugin installiert. Das CDN hat einwandfrei funktioniert.

Änderung 2

In der Plesk-Systemsteuerung habe ich eine Verbindung zu meiner WordPress-Installation hergestellt. Plesk zeigte ein rotes Schild in der Nähe meiner WordPress-Installation, das mich beim Klicken aufforderte, die Sicherheit meiner WordPress-Installation zu überprüfen. Es sagte:

Zeigen Sie die Ergebnisse der Sicherheitsüberprüfung für die ausgewählten WordPress-Installationen an. Wenn einige Daten die Sicherheitsprüfung nicht bestanden haben, können Sie diese Daten in der Liste auswählen und ihre Sicherheit erhöhen.

Ich wähle Sicherheitsschlüssel aus der Liste aus und klicke auf Sicher.

Die Beschreibung des Sicherheitsschlüssels lautet:

WordPress verwendet Sicherheitsschlüssel (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY und NONCE_KEY), um eine bessere Verschlüsselung der in den Cookies des Benutzers gespeicherten Informationen sicherzustellen. Wenn die Sicherheitsüberprüfung fehlgeschlagen ist und Sie die WordPress-Installation sichern möchten, werden gute Sicherheitsschlüssel generiert und für Ihre WordPress-Installation hinzugefügt.

Änderung 3

Startete nginx von Services Management in Plesk.

$config[ads_text6] not found

Anmeldeschleife

Als ich das nächste Mal versuchte, mich bei WordPress anzumelden, wurde es einfach auf die Seite "Reauth = 1" umgeleitet. Wenn ich absichtlich ein falsches Passwort eingegeben habe, wurde darauf hingewiesen, dass das Passwort falsch war. Das Authentifizierungsmaterial funktionierte also einwandfrei, wurde jedoch aus irgendeinem Grund zur Reauth-URL umgeleitet, wenn die richtigen Anmeldeinformationen verwendet wurden. Hier ist eine Liste von Dingen, die ich ausprobiert habe, und keiner von ihnen (außer vielleicht # 15 unten) hat geholfen.

  1. Löschte den Webbrowser-Cache vollständig und probierte verschiedene Browser aus.
  2. Nginx gestoppt, wie über ein Caching-Problem gelesen (nginx.conf)
  3. Das CloudFlare-Plugin wurde über Plesk deaktiviert, da es für einige Benutzer die WP-Verwaltungsfunktionen beeinträchtigte
  4. ALLE Plugins deaktiviert und der Server neu gestartet
  5. Optimierte und reparierte die Datenbank über PhpMyAdmin
  6. Verifizierte Site-URL in der Tabelle wp_options. Es war richtig
  7. Verifizierte Berechtigungen für die Verzeichnisse wp-config file, wp-admin und wp-includes
  8. WP_HOME und WP_SITEURL in wp-config.php hinzugefügt
  9. Generierte neue SALT- oder Secret-Schlüsselcodes und fügte sie zu wp-config.php hinzu
  10. Aktivierte das Thema Twenty Sixteen
  11. Gepostet in WordPress-Foren und absolut keine Antwort
  12. Meine Website wurde aus dem neuesten VaultPress-Backup wiederhergestellt
  13. Aktivierter Entwicklungsmodus in CloudFlare
  14. Stellen Sie CloudFlare PageRule so ein, dass das Caching für Admin-Seiten (WP- *) umgangen wird.
  15. Hat meine Site von CloudFlare getrennt

Es gab viele andere Dinge, die ich zusätzlich zu den oben genannten getan habe, von denen einige trivial sein können. Ich habe ernsthaft über diese Optionen nachgedacht:

  1. Wenden Sie sich für 79 US-Dollar an die professionelle Hilfe von CloudTech (über das MT Admin Panel). Eine Korrektur ist jedoch nicht garantiert.
  2. Setzen Sie Plesk DV auf die Standardeinstellungen zurück. Aber alles wiederherzustellen würde viel Zeit in Anspruch nehmen.
  3. Emergency Restore Request, erneut für 79 US-Dollar. Es wird nur der Inhalt der Website wiederhergestellt, was ich bereits mit VaultPress getan habe.
  4. Verwerfen Sie den Server und wechseln Sie zu verwaltetem Premium WordPress Hosting vom selben Anbieter. Dabei werden die Standardservereinstellungen verwendet.
  5. Wenn die Unterstützung von MT nicht geholfen hat, wechseln Sie zu DreamHost

Viele Ideen gingen mir durch den Kopf und ein ganzer Tag wurde verschwendet. Wenige Stunden nach dem Trennen meiner Website von CloudFlare gibt WordPress jetzt eine andere Fehlermeldung aus. Es heißt jetzt "Cookies sind blockiert", obwohl alle meine Webbrowser Cookies akzeptieren.

Behoben es Atlast!

Schritt 1:

In der wp-config habe ich diese Zeilen entfernt, die die geheimen Schlüssel enthielten:

 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') 

Schritt 2:

Die Datei wurde mit UTF-8-Codierung gespeichert (sie wurde als ANSI angezeigt). Dies kann zwar NICHT das Problem verursachen ... aber ich habe es gerade versucht.

Endlich konnte ich mich beim WordPress Admin Panel anmelden. Ich habe dann neue Sicherheitsschlüssel generiert, mich von WordPress abgemeldet und mich wieder angemeldet. Es funktionierte!

Was hat das Problem überhaupt verursacht?

Während die meisten Beiträge im Internet auf das aktuelle CloudFlare-Plugin hinwiesen, war dies in meinem Fall nicht der Fall. Ich vermute, Plesks Sicherheitsüberprüfung (in Änderung 2 oben) hat sie gebrochen, da ich mich erst nach dem Entfernen der geheimen Schlüssel aus der Datei wp-config.php anmelden durfte. Natürlich habe ich dann neue Sicherheitsschlüssel generiert, die die Datei wp-config.php aktualisiert haben. Ich habe meine Site dann erneut an CloudFlare angehängt und das Plugin aktiviert.

Zum Glück ist das Problem bisher nicht aufgetreten!

Moral der Geschichte (sagte ich mir): Spielen Sie nicht mit den Einstellungen in Plesk, wenn Sie nicht wissen, was Sie tun. Nehmen Sie jeweils eine Änderung vor und dies auch nur, wenn dies unbedingt erforderlich ist, damit Sie wissen, welche Einstellung ein Problem verursacht. Linux / Apache ist nicht wie Windows… sie sind komplexer, zumindest für mich. Wenn dieser Beitrag Ihnen geholfen hat oder Sie zusätzliche Eingaben zur Behebung dieses Problems haben, teilen Sie Ihre Gedanken bitte im Abschnitt "Kommentare" unten mit.

Ähnlicher Artikel