> Dieses Dokument erklärt, wie Sie jeden Social-Login-Anbieter (Google, Facebook, LinkedIn, Naver, Kakao, LINE) im Plugin Simple Easy Social Login (SESLP) konfigurieren.

> Alle Anmeldungen basieren auf OAuth 2.0 / OpenID Connect (OIDC).
> In der Konsole jedes Anbieters erstellen Sie eine App (Client) und tragen Client ID / Client Secret in SESLP ein.

## 🔧 Allgemeine Einrichtung

#### 1) Regel für die Redirect-URI:

`https://{your-domain}/?social_login={provider}`

Beispiele:

- Google → `https://example.com/?social_login=google`
- Facebook → `https://example.com/?social_login=facebook`
- LinkedIn → `https://example.com/?social_login=linkedin`
- Naver → `https://example.com/?social_login=naver`
- Kakao → `https://example.com/?social_login=kakao`
- LINE → `https://example.com/?social_login=line`

#### 2) HTTPS ist erforderlich.

Die meisten Anbieter verlangen HTTPS und lehnen `http://` -Weiterleitungen ab.

#### 3) Exakte Übereinstimmung

Die in der Konsole eingetragene Redirect-URI muss zu 100% mit der von SESLP gesendeten URI übereinstimmen (protocol, subdomain, path, trailing slash, and query string).

#### 4) E-Mail kann fehlen

Einige Anbieter erlauben es Nutzern, die Weitergabe der E-Mail zu verweigern. SESLP kann dann stabile Anbieter-IDs zur Kontoverknüpfung verwenden.

#### 5) Log-Dateien

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

## 🐞 Debug Log & Fehlerbehebung

So lesen Sie SESLP-Debug-Logs

#### 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)

## 🌍 Anbieter-Leitfäden

Klappen Sie unten den jeweiligen Anbieter auf und fügen Sie den vorbereiteten Leitfaden für diesen Anbieter ein.

Google

- 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)

Facebook

- 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

LinkedIn

- 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.

Naver

- 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.

Kakao

- 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

LINE

- 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.