Speicherort der Logdateien

• /wp-content/SESLP-debug.log (SESLP debug log)
• /wp-content/debug.log (WP_DEBUG_LOG = true)

Log-Format

[YYYY-MM-DD HH:MM:SS Z] [LEVEL] Message {"key":"value",...}

• Z: UTC oder WordPress-Lokalzeit (z. B. KST) — in den SESLP-Einstellungen auswählbar
• Datenschutz: E-Mails/Tokens/Secrets werden automatisch maskiert (Beispiel: r********@g****.com)

OAuth-Flow-Logs (häufig)

1) OAuth-Start

[DEBUG] State created {"provider":"google","state":"906****23","ttl":"10min"}

Bedeutung: CSRF-Schutz-State-Token erstellt. ttl ist 10 Minuten gültig.

2) Callback ausgelöst

[DEBUG] Auth route triggered {"provider":"google","has_code":1}

Bedeutung: Callback aufgerufen. has_code:1 → OAuth code empfangen.

3) State-Validierung

Erfolg:

[DEBUG] State validated {"provider":"google","state":"906****23"}

Fehlschlag:

[WARNING] State validation failed: not found/expired {"provider":"google","state":"906****23"}

4) Token-Austausch

[DEBUG] Token response (google) {"has_access_token":1}

Bedeutung: Token erhalten.

Fehlschlag:

[ERROR] Token request failed (google) {"error":"..."}

5) Userinfo-Anfrage

[ERROR] Userinfo request failed (google)
[WARNING] Invalid userinfo (google)

6) Benutzerverknüpfung (Linker)

[DEBUG] Linker: signing in user {"user_id":45,"provider":"google","created":0}
[INFO]  Login success (google) {"user_id":45,"email":"r********@g****.com"}

7) Weiterleitung (Redirect)

[DEBUG] Redirect decision {"mode":"profile","user_id":45,"url":"https://example.com/wp-admin/profile.php"}

Kurzreferenz-Tabelle

Log-Nachricht (kurz)	Wahrscheinliche Ursache	Maßnahme
State validation failed	Timeout, Tab-Wechsel, doppelte Anfrage	Schnell erneut versuchen, privaten Modus nutzen
Token request failed	Falsche Client-ID/Secret/Redirect, Request blockiert	Dev-Konsole, Firewall, Serverzeit prüfen
Userinfo invalid	Fehlender Scope oder E-Mail privat	email, profile Scope hinzufügen, Zustimmung
User create failed	Konto-Konflikt oder WordPress-Einschränkung	Bestehende Benutzer, Multisite-Regeln prüfen
Redirect missing	Frühzeitiger Return im Code	Sicherstellen, dass die Redirect-Klasse nach dem Callback läuft

Hilfreiche Infos für Bug-Reports

• Relevante Log-Zeilen (maskiert)
• Verwendeter Provider (Google/Naver/etc.)
• Redirect-Modus / benutzerdefinierte URL
• Debug-Logging-Status
• WordPress-Umgebung (Single-Site, Multisite, Cache-Plugins)

• Empfohlene Scopes: openid email profile
• Redirect-URI-Regel: https://{domain}/?social_login=google

---

1) Vorbereitung (Pflicht-Checkliste)

(1) HTTPS empfohlen / erforderlich (vertrauenswürdiges Zertifikat für lokale Umgebungen).

(2) Die Redirect-URI muss zu 100 % mit dem in der Konsole registrierten Wert übereinstimmen. Beispiel) https://example.com/?social_login=google

(3) Im Testmodus können nur Testbenutzer sich anmelden (max. 100).

(4) Bei Verwendung von Startseite-/Datenschutz-/Nutzungsbedingungs-URLs: Authorized domains registrieren und Domaininhaberschaft prüfen.

2) Projekt- und Einverständnisbildschirm konfigurieren

(1) Öffnen Sie die Google Cloud Console.
https://console.cloud.google.com/apis/credentials

(2) Projekt auswählen oder → neues Projekt erstellen.

(3) Seitenleiste: APIs & Services → OAuth consent screen.

(4) Benutzertyp: meist External.

(5) App-Informationen: eingeben - Name, Support-E-Mail, (optional) Logo.

(6) App-Domain

• Geben Sie die URL der App-Startseite, die URL der Datenschutzerklärung und die URL der Nutzungsbedingungen ein.
• Fügen Sie die Root-Domain (z. B. example.com) zu den Authorized domains hinzu → Speichern
• Falls erforderlich, führen Sie die Domaininhaberschaftsprüfung über die Search Console durch.

(7) Scopes konfigurieren

• Empfohlen: openid, email, profile
• Sensible/eingeschränkte Scopes müssen vor dem Livegang möglicherweise überprüft werden.

(8) Testbenutzer hinzufügen (E-Mail-Adressen, die sich im Testmodus anmelden dürfen).

(9) Speichern.

Hinweis: Wenn nur die grundlegenden Scopes (openid email profile) verwendet werden, ist der Betrieb (Veröffentlichung) häufig ohne Prüfung möglich.

3) OAuth-Client erstellen (Webanwendung)

(1) Seitenleiste: APIs & Services → Zugangsdaten.

(2) Oben: + Zugangsdaten erstellen → OAuth-Client-ID.

(3) Anwendungstyp: Webanwendung.

(4) Geben Sie einen eindeutigen Namen ein (z. B. SESLP – Front).

(5) Authorized redirect URIs hinzufügen

• https://{domain}/?social_login=google

(6) Klicken Sie auf Erstellen und kopieren Sie anschließend die angezeigte Client ID / Client Secret.

(Optional) Authorized JavaScript Origins sind für dieses Plugin, das den Code-Grant nutzt, in der Regel nicht erforderlich.

4) WordPress- (Plugin-) Einrichtung

(1) WP-Admin → Reiter SESLP Settings → Google.

(2) Client ID / Client Secret einfügen → Speichern.

(3) Testen Sie die Anmeldung mit dem Google-Login-Button im Frontend der Website.

5) Vom Testmodus in die Produktion wechseln

(1) Prüfen Sie OAuth consent screen → Publishing status.

(2) Um vom Testmodus in die Produktion zu wechseln:

• Prüfen Sie, ob App-Informationen (Logo/App-Domain/Richtlinien/Nutzungsbedingungen) korrekt sind.
• Entfernen Sie unnötige Scopes und behalten Sie nur die erforderlichen bei.
• Reichen Sie bei Verwendung sensibler Scopes einen Prüfungsantrag ein.

(3) Nach dem Wechsel in die Produktion können sich alle Google-Konten anmelden.

6) Häufige Fehler & Lösungen

(1) redirect_uri_mismatch

→ Tritt auf, wenn die in der Konsole registrierte Redirect-URI und die tatsächliche Anfrage-URI auch nur geringfügig voneinander abweichen (einschließlich Protokoll, Subdomain, Slash und Query-String). Korrigieren Sie die Werte so, dass sie exakt übereinstimmen.

(2) access_denied / disallowed_useragent

→ Einschränkungen der Browser-/In-App-Umgebung. Versuchen Sie es erneut in einem normalen Browser.

(3) invalid_client / unauthorized_client

→ Tippfehler bei Client ID/Secret oder Statusproblem der App (gelöscht/deaktiviert). Zugangsdaten erneut ausstellen bzw. erneut prüfen.

(4) E-Mail ist leer

→ Prüfen Sie, ob der Scope email enthalten ist, ob der Zustimmungsbildschirm korrekt angezeigt wird und welche Sichtbarkeits-/Sicherheitseinstellungen für die E-Mail im Konto gesetzt sind. Erläutern Sie die Verwendung der E-Mail-Berechtigung im Zustimmungsbildschirm eindeutig.

Logs prüfen:

• wp-content/SESLP-debug.log (Plugin-Debug EIN)
• wp-content/debug.log (WP_DEBUG, WP_DEBUG_LOG = true)

7) Zusammenfassende Checkliste

• OAuth-Zustimmungsbildschirm: App-Info/Domain/Richtlinien/Nutzungsbedingungen/Scopes/Testbenutzer festlegen
• Zugangsdaten: Webanwendungs-Client erstellen
• Redirect-URI registrieren: https://{domain}/?social_login=google
• SESLP: Client ID/Secret speichern und Anmeldung testen
• Beim Livegang den Veröffentlichungsstatus ändern (falls nötig Prüfung einreichen)

• Redirect-URI: https://{domain}/?social_login=facebook
• Angeforderte Berechtigungen (empfohlen): public_profile, email
• Facebook verwendet kein openid.

---

1) App erstellen und Produkt hinzufügen

(1) Öffnen Sie Meta for Developers → melden Sie sich an
https://developers.facebook.com/

(2) Klicken Sie auf Create App → wählen Sie einen allgemeinen Typ (z. B. Consumer) → App erstellen

(3) Fügen Sie in der linken Seitenleiste unter Products Facebook Login hinzu

(4) Gehen Sie zu Settings → prüfen Sie die folgenden Punkte:

• Client OAuth Login: ON
• Web OAuth Login: ON
• Valid OAuth Redirect URIs:
• Fügen Sie https://{domain}/?social_login=facebook hinzu
• (Optional) Enforce HTTPS: standardmäßig empfohlen

2) Grundlegende App-Einstellungen (App Settings → Basic)

(1) App Domains: example.com (die Domain der URL für Richtlinien/Nutzungsbedingungen/Startseite der App)

(2) Privacy Policy URL: öffentlich zugängliche Datenschutzseite

(3) Terms of Service URL: öffentlich zugängliche Nutzungsbedingungen-Seite

(4) User Data Deletion: Geben Sie eine Richtlinien-URL oder einen Datenlösch-Endpunkt an

(5) Category / App Icon: passend einstellen und dann Save

3) Scopes (Berechtigungen) und App-Prüfung

(1) Die grundlegenden Berechtigungen für den Standard-Login sind public_profile; die optionale E-Mail-Berechtigung ist email

(2) In den meisten Fällen kann email ohne Prüfung verwendet werden, es kann jedoch je nach Region/Konto Ausnahmen geben

(3) Erweiterte Berechtigungen wie für Seiten/Werbung erfordern App Review und Business Verification

4) Modus wechseln (Development → Live)

Wechseln Sie oben oder im Einstellungsbereich der App den App-Modus: Development → Live

5) Checkliste vor dem Wechsel auf Live

• Privacy Policy / Terms / Data Deletion URL vorbereiten
• Valid OAuth Redirect URIs korrekt eintragen
• Unnötige Berechtigungen entfernen, nur erforderliche anfordern
• (Falls erforderlich) App Review/Business Verification abschließen

6) WordPress-Einstellungen (SESLP)

(1) WP-Admin → SESLP Settings → Facebook

(2) App ID / App Secret eingeben → speichern

(3) Mit dem Facebook-Login-Button im Frontend testen

7) Fehlerbehebung

(1) Can't Load URL / redirect_uri-Fehler

→ Stellen Sie sicher, dass genau dieselbe URI in Valid OAuth Redirect URIs registriert ist (einschließlich Protokoll, Subdomain, Slash und Query-String)

(2) email null

→ Der Benutzer hat bei Facebook keine E-Mail-Adresse hinterlegt oder sie ist privat. Bereiten Sie eine ID-basierte Kontoverknüpfungslogik vor und erläutern Sie die Verwendung der E-Mail-Berechtigung im Zustimmungsbildschirm eindeutig

(3) Berechtigungsbezogene Fehler

→ Wenn der angeforderte Scope über den grundlegenden Bereich hinausgeht, sind App Review/Business Verification erforderlich

(4) Wechsel auf Live nicht möglich

→ Wenn die Richtlinien-/Nutzungsbedingungen-/Datenlösch-URL fehlt oder nicht öffentlich zugänglich ist. Sie müssen eine öffentliche URL angeben

• Redirect-URI: https://{domain}/?social_login=linkedin
• Erforderliche Einstellung: OpenID Connect (OIDC) aktivieren
• Empfohlene Scopes: openid, profile, email
• LinkedIn stellt die alten Scopes (r_liteprofile, r_emailaddress) schrittweise ein.
• Neue Apps müssen die standardisierten OIDC-Scopes verwenden.

---

1) Anwendung erstellen

(1) Öffnen Sie die LinkedIn Developers Console

→ https://www.linkedin.com/developers/apps

(2) Melden Sie sich mit Ihrem LinkedIn-Konto an

(3) Klicken Sie auf Create app

(4) Füllen Sie die erforderlichen Felder aus:

• App name: z. B. MySite LinkedIn Login
• LinkedIn Page: auswählen oder „None“
• App logo: PNG/JPG mit mindestens 100×100
• Privacy Policy URL / Business Email: gültig und öffentlich zugänglich

(5) Klicken Sie auf Create app

Development Mode ist standardmäßig aktiv → sofortiges Testen des Logins mit openid, profile, email ohne Veröffentlichung

2) OpenID Connect (OIDC) aktivieren

(1) Wechseln Sie zum Reiter Products

(2) Suchen Sie Sign In with LinkedIn using OpenID Connect

(3) Klicken Sie auf Add product → wird sofort genehmigt

(4) OIDC-bezogene Einstellungen erscheinen im Reiter Auth

Erforderliche OIDC-Scopes

• openid → ID-Token
• profile → Name, Foto, Überschrift usw.
• email → E-Mail-Adresse

3) OAuth-2.0-Einstellungen (Auth-Reiter)

(1) Navigieren Sie zu Auth → OAuth 2.0 settings

(2) Fügen Sie unter Redirect URLs Folgendes hinzu:

→ https://{domain}/?social_login=linkedin

(3) Exakte Übereinstimmung erforderlich (Protokoll, Subdomain, Slash, Query)

(4) Falls nötig, mehrere Umgebungen registrieren:

• Lokal: https://localhost:3000/?social_login=linkedin
• Staging: https://staging.example.com/?social_login=linkedin
• Produktion: https://example.com/?social_login=linkedin

(5) Klicken Sie auf Save

4) Client ID / Client Secret abrufen

(1) Im Reiter Auth finden Sie:

• Client ID
• Client Secret

(2) WordPress-Admin → SESLP Settings → LinkedIn

(3) Beide Werte einfügen → Save

(4) Mit dem LinkedIn-Login-Button im Frontend testen

Sicherheit:

• Client Secret niemals offenlegen
• Bei Kompromittierung Regenerate secret verwenden

5) Erklärung der Scopes

Scope	Beschreibung	Hinweis
openid	Gibt ein standardisiertes OIDC-ID-Token zurück	Erforderlich
profile	Name, Foto, Überschrift usw.	Erforderlich
email	E-Mail-Adresse	Erforderlich

Alte Scopes (r_liteprofile, r_emailaddress)

• Nach 2024 veraltet
• Für neue Apps nicht verfügbar

6) Fehlerbehebung

(1) redirect_uri_mismatch

→ URIs unterscheiden sich auch nur geringfügig → 100%ige Übereinstimmung sicherstellen

(2) invalid_client

→ Falsche ID/Secret oder App inaktiv → erneut prüfen oder neu generieren

(3) email NULL

→ Benutzer hat abgelehnt oder der Scope email fehlt → Verwendung im Zustimmungsbildschirm erläutern

(4) insufficient_scope

→ Angeforderter Scope ist nicht freigegeben → prüfen, ob OIDC aktiviert ist

(5) OIDC nicht aktiviert

→ Sign In with LinkedIn using OpenID Connect fehlt unter Products

Logs:

• /wp-content/SESLP-debug.log
• /wp-content/debug.log

7) Zusammenfassende Checkliste

• App erstellt
• OpenID Connect-Produkt hinzugefügt
• Redirect-URI exakt registriert
• Client ID/Secret in SESLP gespeichert
• Scopes: openid profile email (keine alten Scopes)
• Im HTTPS-Frontend getestet

---

Hinweis:

• SESLP unterstützt den OIDC-Flow vollständig.
• Der alte OAuth-2.0-Ansatz wird nicht mehr unterstützt.
• Verwenden Sie für neue Integrationen immer OpenID Connect.

• Redirect-URI: https://{domain}/?social_login=naver
• Empfohlene Scopes: Grundprofil (name), E-Mail (email)
• Naver verwendet die API Naver Login (네아로), HTTPS ist erforderlich

---

1) Anwendung registrieren

(1) Öffnen Sie das Naver Developer Center

→ https://developers.naver.com/apps/

(2) Melden Sie sich mit Ihrem Naver-Konto an

(3) Klicken Sie auf Application → Register Application

(4) Füllen Sie die erforderlichen Felder aus:

• Application Name: z. B. MySite Naver Login
• API Usage: Naver Login (네아로) auswählen
• Add Environment → Web
• Service URL: https://example.com
• Callback URL: https://example.com/?social_login=naver

(5) Den Bedingungen zustimmen → Register

Hinweis:

• HTTPS ist zwingend erforderlich → HTTP ist nicht erlaubt
• Subdomains müssen separat registriert werden

2) Client ID / Client Secret abrufen

(1) Gehen Sie zu My Applications

(2) Klicken Sie auf die App → kopieren Sie Client ID und Client Secret

3) WordPress- (Plugin-) Einstellungen

(1) WP-Admin → SESLP Settings → Naver

(2) Client ID / Client Secret einfügen

(3) Stellen Sie sicher, dass die Redirect-URI exakt übereinstimmt: https://{domain}/?social_login=naver

(4) Save → Mit dem Naver-Login-Button im Frontend testen

4) Berechtigungen und Datenfreigabe

Daten	Scope	Hinweis
Name	name	Standard
E-Mail	email	Standard
Geschlecht, Geburtstag	Separat	Prüfung erforderlich

• Benutzer können im Zustimmungsbildschirm zustimmen/ablehnen
• Wenn die E-Mail abgelehnt wird → email = null → ID-basierte Verknüpfung verwenden
• Sensible Daten erfordern eine Naver-App-Prüfung

5) Fehlerbehebung

(1) Redirect-URI-Mismatch

→ Schon kleine Unterschiede führen zum Fehler → 100 % Übereinstimmung sicherstellen

(2) HTTP-Fehler

→ Es muss HTTPS verwendet werden

(3) Subdomain-Fehler

→ Jede Subdomain muss separat registriert werden

(4) email NULL

→ Benutzer hat abgelehnt oder die E-Mail ist privat → ID-basierte Logik vorbereiten

(5) Prüfung erforderlich

→ Basis-Login: keine Prüfung
→ Zusätzliche Daten: Prüfung erforderlich

Logs:

• /wp-content/SESLP-debug.log
• /wp-content/debug.log

6) Zusammenfassende Checkliste

• App im Naver Developer Center registriert
• Callback-URL exakt registriert
• HTTPS verwendet
• Subdomains separat registriert (falls erforderlich)
• Client ID/Secret in SESLP gespeichert
• Verhalten bei E-Mail-Zustimmung/Ablehnung getestet
• Frontend-Login erfolgreich getestet

---

Hinweis:

• SESLP unterstützt Naver Login (네아로) vollständig.
• Der Basis-Login (name, email) ist ohne Prüfung verfügbar.

• Redirect-URI: https://{domain}/?social_login=kakao
• Empfohlene Scopes: profile_nickname, profile_image, account_email
• account_email ist erst nach Identitäts- oder Unternehmensverifizierung verfügbar
• HTTPS erforderlich, Client-Secret-Aktivierung zwingend erforderlich

---

1) Anwendung erstellen

(1) Öffnen Sie Kakao Developers

→ https://developers.kakao.com/

(2) Anmelden → My Applications → Add New App

(3) Eingeben:

• App-Name, Firmenname
• Kategorie
• Den Betriebsrichtlinien zustimmen

(4) Save

2) Kakao Login aktivieren

(1) Product Settings > Kakao Login

(2) Enable Kakao Login auf ON setzen

(3) Redirect-URI registrieren

• https://{domain}/?social_login=kakao
• Save

(4) Die Domain muss mit der Platform site domain übereinstimmen

3) Consent Items (Scopes)

(1) Consent Items

(2) Hinzufügen und konfigurieren:

Scope	Beschreibung	Zustimmungsart	Hinweis
profile_nickname	Spitzname	Erforderlich/Optional	Basis
profile_image	Profilbild	Erforderlich/Optional	Basis
account_email	E-Mail	Optional	Verifizierung erforderlich

(3) Geben Sie den Zweck für jeden Punkt klar an

(4) Save

Hinweis: Sensible Scopes erfordern eine Verifizierung

4) Web-Plattform registrieren

(1) App Settings > Platform

(2) Register Web Platform

(3) Site Domain: https://{domain}

(4) Save → muss mit der Redirect-URI-Domain übereinstimmen

5) Sicherheit – Client Secret generieren & aktivieren

(1) Product Settings > Security

(2) Use Client Secret → ON

(3) Generate Secret → Wert kopieren

(4) Activation Status → Active

(5) Save

Wichtig: Nach der Generierung muss das Secret aktiviert werden

6) REST-API-Key abrufen (Client ID)

(1) App Keys

(2) REST API Key kopieren → als Client ID verwenden

7) WordPress-Einstellungen

(1) WP-Admin → SESLP Settings → Kakao

(2) Client ID = REST API Key
Client Secret = generiertes Secret

(3) Save

(4) Mit dem Kakao-Login-Button testen

8) Fehlerbehebung

(1) redirect_uri_mismatch → 100%ige Übereinstimmung erforderlich

(2) invalid_client → Secret nicht aktiviert oder Tippfehler

(3) email empty → Benutzer hat abgelehnt oder ist nicht verifiziert

(4) Domain mismatch → Platform vs Redirect URI

(5) HTTP forbidden → nur HTTPS

Logs:

• /wp-content/SESLP-debug.log
• /wp-content/debug.log

9) Zusammenfassende Checkliste

• Kakao Login aktiviert
• Redirect-URI registriert
• Web-Plattform-Domain registriert
• Consent Items konfiguriert
• Client Secret generiert + aktiviert
• REST API Key / Secret in SESLP eingetragen
• Im HTTPS-Frontend getestet

• Redirect-URI: https://{domain}/?social_login=line
• Erforderlich: OpenID Connect aktivieren und die Berechtigung für die E-Mail-Adresse beantragen sowie genehmigen lassen
• Empfohlene Scopes: openid, profile, email
• HTTPS ist zwingend erforderlich, für die E-Mail-Erfassung ist eine Genehmigung notwendig

---

1) Provider und Channel erstellen

(1) Öffnen Sie die LINE Developers Console

→ https://developers.line.biz/console/

(2) Melden Sie sich mit einem LINE Business Account an (persönliche Konten sind nicht zulässig)

(3) Klicken Sie auf Create a new provider → geben Sie einen Namen ein → Create

(4) Öffnen Sie unter dem erstellten Provider den Reiter Channels

(5) Wählen Sie Create a LINE Login channel

(6) Konfigurieren Sie Folgendes:

• Channel type: LINE Login
• Provider: Wählen Sie den zuvor erstellten Provider aus
• Region: Zielland (z. B. South Korea, Japan)
• Name / description / icon: Wird im Zustimmungsbildschirm angezeigt

(7) Den Bedingungen zustimmen → Create

2) OpenID Connect aktivieren und E-Mail-Berechtigung beantragen

(1) Öffnen Sie im linken Menü OpenID Connect

(2) Klicken Sie neben Email address permission auf Apply

(3) Füllen Sie den Antrag aus:

• Privacy Policy URL (muss öffentlich zugänglich sein)
• Laden Sie einen Screenshot der Datenschutzerklärung hoch
• Senden Sie den Antrag ab

(4) Der Scope email funktioniert erst nach der Genehmigung
→ Die Genehmigung dauert in der Regel 1–3 Werktage

3) Callback-URL registrieren und Channel veröffentlichen

(1) Öffnen Sie im linken Menü LINE Login

(2) Geben Sie die Callback URL ein:

→ https://{domain}/?social_login=line

(3) Exakte Übereinstimmung ist erforderlich:

• Protokoll: https:// (HTTP ist nicht erlaubt)
• Domain, Pfad und Query-String müssen zu 100 % übereinstimmen

(4) Klicken Sie auf Save

(5) Ändern Sie den Channel-Status auf Published

• Development mode: nur für Tests
• Published: Live-Betrieb

4) Channel ID / Secret abrufen

(1) Oben auf der Channel-Seite oder unter Basic settings

(2) Channel ID → SESLP Client ID
Channel Secret → SESLP Client Secret

5) WordPress-Einstellungen

(1) WP-Admin → SESLP Settings → LINE

(2) Client ID ← Channel ID
Client Secret ← Channel Secret

(3) Save

(4) Testen Sie mit dem LINE-Login-Button im Frontend

6) Fehlerbehebung

(1) redirect_uri_mismatch → Schon kleine Unterschiede verursachen einen Fehler → 100 % Übereinstimmung sicherstellen

(2) invalid_client → Tippfehler im Secret oder der Channel ist nicht veröffentlicht

(3) email NULL → Die E-Mail-Berechtigung wurde nicht genehmigt oder der Benutzer hat abgelehnt

(4) HTTP ist nicht erlaubt → HTTPS ist erforderlich (auch https://localhost für lokale Tests ist möglich)

(5) Einschränkung im Development-Modus → Nur Testkonten können sich anmelden

Logs:

• /wp-content/SESLP-debug.log
• /wp-content/debug.log

7) Zusammenfassende Checkliste

• Provider + LINE Login Channel mit Business Account erstellt
• E-Mail-Berechtigung beantragt und genehmigt
• Callback URL exakt registriert
• HTTPS verwendet, Status auf Published gesetzt
• Channel ID/Secret in SESLP gespeichert
• Frontend-Login erfolgreich getestet

Hinweis: SESLP unterstützt vollständig

• LINE Login v2.1 + OpenID Connect.
• Für die Erfassung von E-Mails ist eine vorherige Genehmigung erforderlich.