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

  1. Dokumentieren Sie WordPress-, Plugin-, Client-, Connector- und Serverversionen vor jeder Änderung.
  2. Prüfen Sie, ob die exakt verwendete URL mit gültiger HTTPS-Verbindung lädt.
  3. Prüfen Sie die globale Verfügbarkeit von Application Passwords in der aktiven Umgebung.
  4. Prüfen Sie die Verfügbarkeit für den genauen WordPress-Benutzer.
  5. Prüfen Sie alle plausiblen Benutzer statt den aktuellen Administrator als Eigentümer anzunehmen.
  6. Prüfen Sie den Abschnitt Application Passwords des relevanten Profils, ohne Geheimnisse offenzulegen.

Die kleinste passende Korrektur anwenden

  1. Stellen Sie die exakten WordPress- und REST-URLs über HTTPS bereit, bevor Application-Password-Authentifizierung aktiviert wird.
  2. Korrigieren Sie vertrauenswürdige Proxy- und Origin-Verarbeitung, damit WordPress die ursprüngliche HTTPS-Anfrage erkennt.
  3. Entfernen oder begrenzen Sie den deaktivierenden Filter erst nach Bestätigung der gewünschten Sicherheitsrichtlinie.
  4. Erlauben Sie Application Passwords nur für den dedizierten Benutzer der Integration.
  5. 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

Quellen und Überprüfung

Diese Seite wurde anhand der folgenden Primärquellen überprüft. Letzte Quellenprüfung: .