Fehlerbehebung

Prüfen Sie:

• Die Client-ID gehört zur ausgewählten Umgebung.
• Die Redirect URI stimmt exakt mit einem registrierten Wert überein.
• response_type ist code.
• scope enthält unterstützte, durch Leerzeichen getrennte Werte.
• PKCE verwendet code_challenge_method=S256.

Setzen Sie die Anmeldung nicht fort. Stellen Sie sicher, dass derselbe Browser das Transaktions-Cookie erhalten hat, Cookie-Pfad und SameSite-Einstellungen den Callback abdecken und die Transaktion weder abgelaufen noch bereits verwendet wurde. Starten Sie nach dem Fehler eine neue Anmeldung.

Prüfen Sie:

• Der Authorization Code ist weder abgelaufen noch bereits verwendet worden.
• Die Token-Anfrage verwendet dieselbe Redirect URI wie die Autorisierungsanfrage.
• Der ursprüngliche PKCE Verifier entspricht der Challenge.
• Client-Zugangsdaten und Token-Endpoint gehören zur selben Umgebung.
• Die Anfrage ist formularcodiert.

Senden Sie das Access Token als Authorization: Bearer …. Senden Sie kein ID Token, Refresh Token und keinen Authorization Code an UserInfo. Ist das Access Token abgelaufen, verwenden Sie serverseitig ein gültiges Refresh Token oder starten Sie eine neue Anmeldung.

Stellen Sie sicher, dass der entsprechende Scope angefordert und autorisiert wurde. Profil-Claims können optional sein. Implementieren Sie deshalb einen sicheren Fallback und setzen Sie nicht voraus, dass jedes Konto jedes Feld enthält.

Prüfen Sie, ob die Funktion für das Asset aktiviert und in seiner Lizenz enthalten ist. Standard Login, Analytics und Campaign werden separat lizenziert, wie unter Lizenzen beschrieben.

Verwenden Sie für die Cache-Konfiguration auf WordPress-Seite nur Cookies, die an die WordPress-Domain gesendet werden. Das DocID^® WordPress-Plugin verwendet die folgenden Cookie-Muster:

• docid_session_id kennzeichnet eine authentifizierte DocID^®-Sitzung. Konfigurieren Sie Seiten-Caches so, dass bei vorhandenem Cookie keine zwischengespeicherte Antwort ausgeliefert wird.
• docid_oauth_binding_* wird vorübergehend verwendet, während der Browser die OAuth-Anmeldung abschließt. Cachen Sie lokale OAuth-Start- und Callback-Anfragen nicht und umgehen Sie den Cache, wenn ein Cookie mit diesem Präfix vorhanden ist.
• wordpress_logged_in_*, wordpress_sec_* und wordpress_* sind standardmäßige WordPress-Authentifizierungs-Cookie-Muster, die bei aktivierter Bereitstellung nativer WordPress-Konten verwendet werden. Behalten Sie die üblichen WordPress-Cache-Ausschlüsse für angemeldete Benutzer bei, einschließlich angepasster Entsprechungen, falls Ihre Website die WordPress-Cookie-Konstanten überschreibt.

Schließen Sie außerdem alle durch DocID^® geschützten URLs sowie lokale OAuth-Start-, Callback-, Abmelde- und Fehlerhinweis-Anfragen vom Seiten-Caching aus. Leeren Sie nach einer Änderung der Cache-Regeln bereits zwischengespeicherte Weiterleitungen für geschützte URLs. Gleichen Sie nur Cookie-Namen oder -Präfixe ab; zeichnen Sie niemals vollständige Cookie-Werte in Cache-Regeln oder Protokollen auf.

Senden Sie an support@docid.pro:

• betroffene Umgebung und betroffenes Asset
• ungefähren Zeitpunkt mit Zeitzone
• eine sichere Korrelations- oder Request-ID
• Seite und Schritt, bei dem das Problem aufgetreten ist
• den OAuth-Fehlercode, falls einer zurückgegeben wurde

Senden Sie niemals Client Secrets, Authorization Codes, Access Tokens, Refresh Tokens oder vollständige Session-Cookies.