Ein Nutzer öffnet eine frisch angeforderte Passwort-Reset-Mail, landet aber wieder am normalen Login oder gerät in eine Weiterleitungsschleife. Solange der Link nicht mit vollständigem Schlüssel am vorgesehenen WordPress-Handler ankommt, kann kein neues Kennwort gesetzt werden. Die Diagnose muss daher bei der erzeugten URL beginnen und jeden Redirect bis zum Ziel verfolgen.
Was bei einem Passwort-Reset weitergeleitet wird
Ein WordPress-Passwort-Reset enthält eine Benutzerkennung und einen zeitlich begrenzten Einmalschlüssel. Beide Werte müssen auf dem richtigen Host, unter dem erwarteten Pfad und über das passende Protokoll beim Reset-Handler eintreffen. Ändert ein Redirect den Host oder entfernt Query-Parameter, fällt WordPress häufig auf den normalen Login zurück.
Auch Mail-Sicherheitsdienste können Links umschreiben oder vorab aufrufen. Deshalb reicht es nicht, nur die Adresse im Browser zu betrachten: Verglichen werden die von WordPress erzeugte URL, die tatsächlich zugestellte Adresse und die Redirect-Kette im Browser. Geheimnisse gehören dabei weder in Screenshots noch in Protokolle; für den Vergleich genügen Parameternamen, Zeitpunkte und gehashte Werte.
Ein realistisches WordPress-Beispiel
WordPress erzeugt den Reset-Link noch mit einem alten HTTP-Host. Ein CDN leitet zunächst auf HTTPS und anschließend auf die neue kanonische Domain um. Beim zweiten Sprung gehen die Reset-Parameter verloren, sodass der Benutzer nur die Login-Seite sieht. Die Korrektur der WordPress-URLs und der Host-Weiterleitung stellt den vollständigen Zielpfad wieder her.
Danach wird ein neuer Link angefordert. Der alte Link bleibt ungültig, der neue lässt sich genau einmal verwenden, und das bisherige Kennwort wird nach erfolgreichem Reset abgelehnt. Damit ist nicht nur die Navigation, sondern der gesamte Sicherheitsablauf geprüft.
Warum eine vollständige Redirect-Kette wichtig ist
Eine Weiterleitung kann auf mehreren Ebenen entstehen: WordPress, Login-Plugin, Webserver, Reverse Proxy, CDN oder Mail-Sicherheitsdienst. Wird nur der letzte Sprung untersucht, bleibt die Stelle verborgen, an der Host, Pfad oder Parameter verändert wurden. Pauschale Ausnahmen für alle Redirects würden zwar das Symptom überdecken, könnten aber kanonische URLs und HTTPS-Schutz schwächen.
Besonders kritisch sind gemeinsam gecachte Reset-Antworten. Passwort-Reset-Seiten und ihre Parameter sind benutzerspezifisch und dürfen nicht wie öffentliche Inhalte behandelt werden.
Der einfache Weg für Einsteiger
- Fordern Sie für ein eigens vorgesehenes Testkonto einen neuen Reset-Link an und verwenden Sie nur die neueste Mail.
- Prüfen Sie in WordPress die Website- und WordPress-Adresse sowie den kanonischen HTTPS-Host.
- Öffnen Sie den Link in einer sauberen Browsersitzung und notieren Sie jeden Host- und Pfadwechsel, ohne Schlüsselwerte zu speichern.
- Kontrollieren Sie Weiterleitungen im Login-Plugin, am Webserver und im CDN. Ändern Sie jeweils nur eine verantwortliche Regel.
- Nehmen Sie Passwort-Reset-Seiten aus öffentlichen Cache-Regeln und aus Regeln heraus, die unbekannte Query-Parameter entfernen.
- Fordern Sie nach der Korrektur erneut einen Link an und prüfen Sie Kennwortänderung, Anmeldung, Abmeldung sowie die Ablehnung des bereits verwendeten Links.
Der technische Weg
Erfassen Sie für jeden Hop Statuscode, Location-Header, Host, Protokoll, Pfad und vorhandene Parameternamen. Vergleichen Sie die WordPress-Ausgabe außerdem mit der vom Mail-System zugestellten URL. So lassen sich Anwendung, Mail-Umschreibung, Proxy und CDN voneinander trennen.
Testen Sie mit einem Wegwerfkonto, ob ein Link-Scanner den Schlüssel vor dem Benutzer aufruft oder verändert. Ein Reset-Schlüssel darf deshalb jedoch niemals wiederverwendbar gemacht werden. Benötigt die Organisation eine Ausnahme, muss sie eng auf den unterstützten Reset-Pfad und den verantwortlichen Sicherheitsdienst begrenzt werden. Dokumentieren Sie den Lebenszyklus des Testschlüssels – erzeugt, zugestellt, erstmals geöffnet, angenommen, verbraucht und abgelaufen – nur mit Zeitstempeln und nicht umkehrbaren Kennungen.
Risiken, häufige Fehler, Backup und Rollback
Ändern Sie nicht gleichzeitig WordPress-URLs, Webserver-Regeln und CDN-Weiterleitungen. Sonst ist weder die Ursache noch ein verlässlicher Rückweg erkennbar. Halten Sie vor Änderungen an Login und URL-Konfiguration eine Administratorsitzung sowie den serverseitigen Notfallzugang offen.
Führt die Korrektur zu falschen Hosts, unterbrochenen Anmeldungen oder neuen Schleifen, stellen Sie die zuletzt geänderte Regel auf den dokumentierten Vorzustand zurück. Verwenden Sie zum Test anschließend einen neu erzeugten Reset-Link; bereits aufgerufene oder abgelaufene Schlüssel sind kein verlässlicher Kontrollfall.
So unterstützt AIOWS:
AIOWS Login Manager
AIOWS Login Manager verwaltet unterstützte Einstellungen rund um den WordPress-Login. Bei Problemen mit Passwort-Reset-Links ist das Modul vor allem dann relevant, wenn eine eigene Login-Adresse oder eine andere Login-Manager-Regel den Reset-Pfad beeinflusst. Administratoren können die aktuelle Konfiguration an einer Stelle prüfen und erkennen, welche AIOWS-Einstellung überhaupt Teil der Redirect-Kette sein kann.
Die Fehleranalyse beginnt dennoch bei einem frisch erzeugten WordPress-Link. Prüfen Sie zunächst Website-Adresse, HTTPS-Host und die externen Weiterleitungen. Erst wenn ein Sprung auf eine Login-Manager-Einstellung zurückgeht, sollte genau diese Einstellung kontrolliert geändert werden. Eine funktionierende Administratorsitzung bleibt dabei geöffnet; weitere IP-, Prüf- oder Authentifizierungsregeln werden nicht gleichzeitig angepasst.
Nach der Korrektur gehört der vollständige Benutzerablauf zur Abnahme: Reset anfordern, Mail empfangen, Link einmal öffnen, neues Kennwort setzen, mit dem neuen Kennwort anmelden und den alten beziehungsweise bereits verbrauchten Link ablehnen. Die Tests erfolgen über den öffentlichen Host und in einer sauberen Browsersitzung, damit weder eine alte Sitzung noch ein lokaler Cache das Ergebnis verfälscht.
Login Manager kann keine fehlerhafte CDN-Weiterleitung, Mail-Link-Umschreibung oder falsche WordPress-Basis-URL außerhalb seiner Einstellungen reparieren. Führt eine Änderung zu einer Aussperrung, setzen Sie nur die betroffene Login-Manager-Option über die offene Sitzung oder den vorbereiteten Notfallzugang zurück. Dokumentieren Sie Pfad, Änderung und Testergebnis, ohne Reset-Schlüssel offenzulegen.
Passende AIOWS-Artikel
- wp-admin-Weiterleitungsschleife: WordPress-Login reparieren
- WordPress-Loginfehler: Cookies sind blockiert oder nicht unterstützt
- WordPress meldet mich ständig ab: Ursachen und Lösungen
Fazit und empfohlener Weg
Verfolgen Sie einen frisch erzeugten Reset-Link vom WordPress-Ausgang bis zum Ziel und bestimmen Sie den ersten Redirect, der Host, Pfad oder Parameter verändert. Korrigieren Sie nur diese Ebene und testen Sie anschließend einen neuen Schlüssel über den vollständigen Ablauf. Einmaligkeit und Ablauf des Reset-Links bleiben dabei unangetastet.
