Application Passwords fehlen im WordPress-Benutzerprofil
Die vom Assistenten verwendete URL wird nicht tatsächlich über HTTPS ausgeliefert.
Dokumentieren Sie WordPress-, Plugin-, Client-, Connector- und Serverversionen vor jeder Änderung.
Wahrscheinliche Ursachen
- Die vom Assistenten verwendete URL wird nicht tatsächlich über HTTPS ausgeliefert.
- Der Browser nutzt HTTPS, aber WordPress erkennt die Anfrage am Origin nicht als sicher.
- Ein Sicherheits-Plugin, Must-use-Plugin oder benutzerdefinierter Filter deaktiviert Application Passwords global.
- Application Passwords sind für den von der Integration gewählten WordPress-Benutzer nicht verfügbar.
- Die Anmeldedaten gehören zu einem anderen WordPress-Benutzer als vom Client erwartet.
Diagnosereihenfolge
- Dokumentieren Sie WordPress-, Plugin-, Client-, Connector- und Serverversionen vor jeder Änderung.
- Prüfen Sie, ob die exakt verwendete URL mit gültiger HTTPS-Verbindung lädt.
- Prüfen Sie die globale Verfügbarkeit von Application Passwords in der aktiven Umgebung.
- Prüfen Sie die Verfügbarkeit für den genauen WordPress-Benutzer.
- Prüfen Sie alle plausiblen Benutzer statt den aktuellen Administrator als Eigentümer anzunehmen.
- Prüfen Sie den Abschnitt Application Passwords des relevanten Profils, ohne Geheimnisse offenzulegen.
Die kleinste passende Korrektur anwenden
- Stellen Sie die exakten WordPress- und REST-URLs über HTTPS bereit, bevor Application-Password-Authentifizierung aktiviert wird.
- Korrigieren Sie vertrauenswürdige Proxy- und Origin-Verarbeitung, damit WordPress die ursprüngliche HTTPS-Anfrage erkennt.
- Entfernen oder begrenzen Sie den deaktivierenden Filter erst nach Bestätigung der gewünschten Sicherheitsrichtlinie.
- Erlauben Sie Application Passwords nur für den dedizierten Benutzer der Integration.
- Erstellen Sie eine dedizierte WordPress-Identität statt das menschliche Administratorkonto zu verwenden.
Ergebnis überprüfen
- Jede Anmeldeinformation besitzt Eigentümer, Zweck, Ersteller, Status und Widerrufsentscheidung.
- Die authentifizierte Anfrage entspricht dem vorgesehenen dedizierten Benutzer.
- Der REST-Index antwortet über die kanonische HTTPS-URL und zeigt erwartete Namespaces.
- Der Abschlussdatensatz enthält Versionen, Evidenz, Änderung, Prüfung und Rollback ohne Geheimnisse.
Was Sie nicht tun sollten
- Vergeben Sie keinen Administratorzugriff nur damit ein Verbindungstest gelingt.
- Teilen Sie kein Application Password, keinen Authorization-Header, Token oder Cookie in Prompt, Ticket, Log oder Screenshot.
- Bearbeiten Sie WordPress Core oder Drittanbieter-Plugin-Dateien nicht als ersten Diagnoseschritt.
- Fügen Sie keinen ungeprüften dauerhaften Proxy-Workaround vor Bestätigung des Vertrauenspfads hinzu.
- Löschen Sie unbekannte Anmeldedaten nicht vor Dokumentation von Eigentümer, Zweck und letzter Nutzung.
Verwandte Leitfäden
- WordPress Application Passwords sind deaktiviert: Ursachen und sichere Prüfungen
- WordPress-Anwendungspasswörter für KI-Verbindungen
- So finden Sie WAP Application Passwords in WordPress
- So ermitteln Sie den WordPress-Benutzer eines KI-Assistenten
- WordPress erkennt HTTPS hinter Cloudflare oder einem Reverse Proxy nicht
Quellen und Überprüfung
Diese Seite wurde anhand der folgenden Primärquellen überprüft. Letzte Quellenprüfung: .
- Application Passwords · WordPress Developer Resources
- wp_is_application_passwords_available() · WordPress Developer Resources
- wp_is_application_passwords_available_for_user() · WordPress Developer Resources
- Application Passwords REST API Reference · WordPress Developer Resources