Emplacement du fichier journal

• /wp-content/SESLP-debug.log (journal de débogage SESLP)
• /wp-content/debug.log (WP_DEBUG_LOG = true)

Format du journal

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

• Z : UTC ou heure locale de WordPress (par ex. KST) — sélectionnable dans les paramètres SESLP
• Confidentialité : les e-mails, jetons et secrets sont automatiquement masqués (exemple : r********@g****.com)

Journaux du flux OAuth (généraux)

1) Démarrage d’OAuth

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

Signification : un jeton state de protection CSRF a été créé. ttl est valide pendant 10 minutes.

2) Callback déclenché

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

Signification : le callback a été atteint. has_code:1 → le code OAuth code a été reçu.

3) Validation du state

Succès :

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

Échec :

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

4) Échange du jeton

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

Signification : le jeton a été obtenu.

Échec :

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

5) Requête d’informations utilisateur

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

6) Lien utilisateur

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

7) Redirection

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

Tableau de référence rapide

Message du journal (résumé)	Cause probable	Action
State validation failed	Délai dépassé, changement d’onglet, requête en double	Réessayez rapidement, utilisez le mode privé
Token request failed	Client ID/Secret/Redirect incorrect, requête bloquée	Vérifiez la console de développement, le pare-feu et l’heure du serveur
Userinfo invalid	Scope manquant ou e-mail privé	Ajoutez les scopes email, profile et demandez le consentement de l’utilisateur
User create failed	Conflit de compte ou restriction WordPress	Vérifiez les utilisateurs existants et les règles multisites
Redirect missing	Retour anticipé dans le code	Assurez-vous que la classe Redirect s’exécute après le callback

Informations utiles à inclure dans les rapports de bug

• Lignes de journal pertinentes (masquées)
• Fournisseur utilisé (Google/Naver/etc.)
• Mode de redirection / URL personnalisée
• État de l’enregistrement des journaux de débogage
• Environnement WordPress (site unique, multisite, plugins de cache)

• Scopes recommandés : openid email profile
• Règle de Redirect URI : https://{domain}/?social_login=google

---

1) Préparation (liste de vérification obligatoire)

(1) HTTPS recommandé / pratiquement indispensable (utilisez des certificats de développement fiables pour les environnements locaux).

(2) La Redirect URI doit correspondre exactement à 100 % à la valeur enregistrée dans la console. Ex. : https://example.com/?social_login=google

(3) En mode test, seuls les utilisateurs de test peuvent se connecter (jusqu’à 100 utilisateurs).

(4) Lorsque vous utilisez des URL de page d’accueil, de politique de confidentialité ou de conditions d’utilisation, l’enregistrement des domaines de l’application (Authorized domains) et la vérification de propriété peuvent être nécessaires.

2) Configuration du projet / écran de consentement

(1) Accédez à Google Cloud Console.
https://console.cloud.google.com/apis/credentials

(2) Sélectionnez le projet en haut → Créer un nouveau projet (si nécessaire).

(3) Dans la barre latérale, allez dans APIs & Services → OAuth consent screen.

(4) Sélectionnez le type d’utilisateur : généralement External.

(5) Saisissez les informations de l’application : nom de l’application, e-mail d’assistance utilisateur, logo (facultatif).

(6) Section App domain

• Saisissez l’URL de la page d’accueil de l’application, l’URL de la politique de confidentialité et l’URL des conditions d’utilisation
• Ajoutez le domaine racine (par ex. example.com) à Authorized domains → Save
• Si nécessaire, effectuez la vérification de propriété du domaine via Search Console.

(7) Configurez les Scopes

• Recommandés : openid, email, profile
• Les scopes sensibles ou restreints peuvent nécessiter une vérification avant la mise en production.

(8) Ajoutez des utilisateurs de test (adresses e-mail autorisées à se connecter en mode test).

(9) Save.

Remarque : L’utilisation des scopes de base uniquement (openid email profile) permet souvent une mise en service (publication) sans examen.

3) Créer un client OAuth (application Web)

(1) Barre latérale : APIs & Services → Credentials.

(2) En haut : + Create Credentials → OAuth client ID.

(3) Type d’application : Web application.

(4) Saisissez un nom facilement identifiable (par ex. SESLP – Front).

(5) Ajoutez les Authorized redirect URIs

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

(6) Cliquez sur Create, puis copiez le Client ID / Client Secret affiché.

(Facultatif) Les Authorized JavaScript origins ne sont généralement pas nécessaires pour ce plugin utilisant le code grant.

4) Configuration WordPress (plugin)

(1) Administration WP → onglet SESLP Settings → Google.

(2) Collez le Client ID / Client Secret → Save.

(3) Testez avec le bouton de connexion Google sur le frontend du site.

5) Passer du mode test à la production

(1) Vérifiez OAuth consent screen → Publishing status.

(2) Pour passer du mode test à la production :

• Vérifiez que les informations de l’application (logo, domaine, politiques, conditions) sont exactes.
• Supprimez les scopes inutiles et ne conservez que les nécessaires.
• Soumettez une demande d’examen si vous utilisez des scopes sensibles.

(3) Après le passage en production, tous les comptes Google peuvent se connecter.

6) Erreurs courantes & solutions

(1) redirect_uri_mismatch

→ Se produit si la Redirect URI enregistrée dans la console et l’URI réelle de la requête diffèrent, même légèrement (y compris le protocole, le sous-domaine, le slash ou la requête). Corrigez-les pour qu’elles correspondent exactement.

(2) access_denied / disallowed_useragent

→ Restrictions liées au navigateur ou à l’environnement in-app. Réessayez dans un navigateur classique.

(3) invalid_client / unauthorized_client

→ Faute de frappe dans le Client ID/Secret ou problème d’état de l’application (supprimée/désactivée). Réémettez ou revérifiez les identifiants.

(4) L’e-mail est vide

→ Vérifiez si le scope email est inclus, si l’écran de consentement s’affiche correctement et les paramètres de visibilité/sécurité de l’e-mail du compte. Expliquez clairement l’usage de l’autorisation e-mail dans l’écran de consentement.

Vérifier les journaux :

• wp-content/SESLP-debug.log (débogage du plugin activé)
• wp-content/debug.log (WP_DEBUG, WP_DEBUG_LOG = true)

7) Liste de vérification récapitulative

• Écran de consentement OAuth : configurer les infos de l’application / domaine / politiques / conditions / scopes / utilisateurs de test
• Identifiants : créer un client Web Application
• Enregistrer la Redirect URI : https://{domain}/?social_login=google
• SESLP : enregistrer le Client ID/Secret et tester la connexion
• Modifier le statut de publication lors du passage en production (soumettre un examen si nécessaire)

• URI de redirection : https://{domain}/?social_login=facebook
• Autorisations demandées (recommandées) : public_profile, email
• Facebook n’utilise pas openid.

---

1) Créer une application et ajouter un produit

(1) Accédez à Meta for Developers → Connectez-vous
https://developers.facebook.com/

(2) Cliquez sur Create App → Sélectionnez un type général (par ex. Consumer) → Créez l’application

(3) Dans la barre latérale gauche, ajoutez Facebook Login depuis Products

(4) Allez dans Settings → Vérifiez les éléments suivants :

• Client OAuth Login : ON
• Web OAuth Login : ON
• Valid OAuth Redirect URIs :
• Ajoutez https://{domain}/?social_login=facebook
• (Optionnel) Enforce HTTPS : recommandé par défaut

2) Paramètres de base de l’application (App Settings → Basic)

(1) App Domains : example.com (domaine des URL de politique/conditions/page d’accueil)

(2) URL de politique de confidentialité : page publique accessible

(3) URL des conditions d’utilisation : page publique accessible

(4) Suppression des données utilisateur : fournir une URL de guide ou un endpoint de suppression

(5) Catégorie / Icône de l’application : configurer correctement, puis Save

3) Scopes (autorisations) et examen de l’application

(1) Les autorisations de base requises pour la connexion standard sont public_profile ; l’e-mail optionnel est email

(2) Dans la plupart des cas, email peut être utilisé sans examen, mais des exceptions peuvent exister selon la région/le compte

(3) Les autorisations avancées (pages, publicités, etc.) nécessitent un App Review et une Business Verification

4) Changer de mode (Development → Live)

En haut ou dans les paramètres de l’application, passez App Mode : Development → Live

5) Liste de vérification avant de passer en Live

• Préparer l’URL de politique de confidentialité / conditions / suppression des données
• Saisir correctement les Valid OAuth Redirect URIs
• Supprimer les autorisations inutiles, demander uniquement celles nécessaires
• (Si nécessaire) Compléter l’App Review / Business Verification

6) Paramètres WordPress (SESLP)

(1) Admin WP → SESLP Settings → Facebook

(2) Saisissez App ID / App Secret → Enregistrer

(3) Testez avec le bouton de connexion Facebook sur le frontend

7) Dépannage

(1) Can't Load URL / erreur redirect_uri

→ Assurez-vous que l’URI est exactement identique dans Valid OAuth Redirect URIs (protocole, sous-domaine, slash, paramètres)

(2) email null

→ L’utilisateur n’a pas d’e-mail enregistré sur Facebook ou celui-ci est privé. Préparez une logique de liaison basée sur l’ID et expliquez clairement l’utilisation de l’e-mail dans l’écran de consentement

(3) Erreurs liées aux autorisations

→ Si les scopes demandés dépassent les autorisations de base, un App Review / Business Verification est requis

(4) Impossible de passer en Live

→ Si l’URL de politique/conditions/suppression des données est manquante ou non publique. Vous devez fournir une URL publique

• URI de redirection : https://{domain}/?social_login=linkedin
• Configuration requise : Activer OpenID Connect (OIDC)
• Scopes recommandés : openid, profile, email
• LinkedIn supprime progressivement les anciens scopes (r_liteprofile, r_emailaddress).
• Les nouvelles applications doivent utiliser les scopes standard OIDC.

---

1) Créer une application

(1) Accédez à LinkedIn Developers Console

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

(2) Connectez-vous avec votre compte LinkedIn

(3) Cliquez sur Create app

(4) Remplissez les champs requis :

• Nom de l’application : par ex. MySite LinkedIn Login
• Page LinkedIn : sélectionner ou « None »
• Logo de l’application : PNG/JPG 100×100+
• URL de la politique de confidentialité / e-mail professionnel : valides et publics

(5) Cliquez sur Create app

Mode développement par défaut → permet de tester immédiatement la connexion avec openid, profile, email sans publication

2) Activer OpenID Connect (OIDC)

(1) Allez dans l’onglet Products

(2) Trouvez Sign In with LinkedIn using OpenID Connect

(3) Cliquez sur Add product → approuvé instantanément

(4) Les paramètres OIDC apparaissent dans l’onglet Auth

Scopes OIDC requis

• openid → jeton ID
• profile → nom, photo, titre
• email → adresse e-mail

3) Paramètres OAuth 2.0 (onglet Auth)

(1) Accédez à Auth → OAuth 2.0 settings

(2) Ajoutez dans Redirect URLs :

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

(3) Correspondance exacte requise (protocole, sous-domaine, slash, requête)

(4) Enregistrez plusieurs URL si nécessaire :

• Local : https://localhost:3000/?social_login=linkedin
• Staging : https://staging.example.com/?social_login=linkedin
• Production : https://example.com/?social_login=linkedin

(5) Cliquez sur Save

4) Obtenir Client ID / Client Secret

(1) Dans l’onglet Auth, trouvez :

• Client ID
• Client Secret

(2) Admin WordPress → SESLP Settings → LinkedIn

(3) Collez les deux → Save

(4) Testez avec le bouton de connexion LinkedIn sur le frontend

Sécurité :

• Ne jamais exposer le Client Secret
• Utilisez Regenerate secret en cas de compromission

5) Explication des scopes

Scope	Description	Remarque
openid	Retourne un jeton ID conforme OIDC	Requis
profile	Nom, photo, titre, etc.	Requis
email	Adresse e-mail	Requis

Anciennes scopes (r_liteprofile, r_emailaddress)

• Obsolètes après 2024
• Non disponibles pour les nouvelles applications

6) Dépannage

(1) redirect_uri_mismatch

→ Les URI diffèrent même légèrement → assurez une correspondance à 100 %

(2) invalid_client

→ ID/Secret incorrect ou application inactive → vérifier ou régénérer

(3) email NULL

→ L’utilisateur a refusé ou le scope email est manquant → expliquer l’utilisation dans l’écran de consentement

(4) insufficient_scope

→ Scope demandé non approuvé → vérifier que OIDC est activé

(5) OIDC non activé

→ Produit Sign In with LinkedIn using OpenID Connect manquant dans Products

Journaux :

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

7) Liste de vérification récapitulative

• Application créée
• Produit OpenID Connect ajouté
• URI de redirection enregistrée exactement
• Client ID/Secret enregistrés dans SESLP
• Scopes : openid profile email (sans anciens scopes)
• Test effectué sur frontend HTTPS

---

Remarque :

• SESLP prend entièrement en charge le flux OIDC.
• L’ancien OAuth 2.0 n’est plus pris en charge.
• Utilisez toujours OpenID Connect pour les nouvelles intégrations.

• URI de redirection : https://{domain}/?social_login=naver
• Scopes recommandés : Profil de base (name), e-mail (email)
• Naver utilise l’API Naver Login (네아로), HTTPS requis

---

1) Enregistrement de l’application

(1) Accédez au Naver Developer Center

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

(2) Connectez-vous avec votre compte Naver

(3) Cliquez sur Application → Register Application

(4) Remplissez les champs requis :

• Nom de l’application : par ex. MySite Naver Login
• Utilisation de l’API : sélectionnez Naver Login (네아로)
• Ajouter un environnement → Web
• URL du service : https://example.com
• URL de callback : https://example.com/?social_login=naver

(5) Acceptez les conditions → Register

Remarque :

• HTTPS obligatoire → HTTP non autorisé
• Les sous-domaines doivent être enregistrés séparément

2) Obtenir le Client ID / Client Secret

(1) Accédez à My Applications

(2) Cliquez sur l’application → copiez le Client ID et le Client Secret

3) Paramètres WordPress (plugin)

(1) Admin WP → SESLP Settings → Naver

(2) Collez le Client ID / Client Secret

(3) Assurez-vous que l’URI de redirection correspond exactement : https://{domain}/?social_login=naver

(4) Save → testez avec le bouton de connexion Naver sur le frontend

4) Autorisations et fourniture des données

Donnée	Scope	Remarque
Nom	name	Par défaut
E-mail	email	Par défaut
Genre, date de naissance	Séparé	Examen requis

• Les utilisateurs peuvent accepter/refuser sur l’écran de consentement
• Si l’e-mail est refusé → email = null → utiliser une liaison basée sur l’ID
• Les données sensibles nécessitent un examen de l’application Naver

5) Dépannage

(1) Redirect URI mismatch

→ Même une légère différence → assurez une correspondance à 100 %

(2) Erreur HTTP

→ Utiliser HTTPS obligatoirement

(3) Erreur de sous-domaine

→ Enregistrer chaque sous-domaine séparément

(4) email NULL

→ Refus utilisateur ou e-mail privé → prévoir une logique basée sur l’ID

(5) Examen requis

→ Connexion de base : pas d’examen
→ Données supplémentaires : examen requis

Journaux :

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

6) Liste de vérification récapitulative

• Application enregistrée dans Naver Developer Center
• URL de callback enregistrée correctement
• HTTPS utilisé
• Sous-domaines enregistrés séparément (si nécessaire)
• Client ID/Secret enregistrés dans SESLP
• Test du comportement acceptation/refus de l’e-mail
• Test de connexion frontend effectué

---

Remarque :

• SESLP prend entièrement en charge Naver Login (네아로).
• La connexion de base (name, email) est disponible sans examen.

• URI de redirection : https://{domain}/?social_login=kakao
• Scopes recommandés : profile_nickname, profile_image, account_email
• account_email disponible uniquement après vérification d’identité ou d’entreprise
• HTTPS requis, activation du Client Secret obligatoire

---

1) Créer une application

(1) Accédez à Kakao Developers

→ https://developers.kakao.com/

(2) Connectez-vous → My Applications → Add New App

(3) Saisissez :

• Nom de l’application, nom de l’entreprise
• Catégorie
• Accepter la politique d’exploitation

(4) Save

2) Activer Kakao Login

(1) Product Settings > Kakao Login

(2) Activer Enable Kakao Login → ON

(3) Enregistrer l’URI de redirection

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

(4) Le domaine doit correspondre au Platform site domain

3) Éléments de consentement (Scopes)

(1) Consent Items

(2) Ajouter et configurer :

Scope	Description	Type de consentement	Remarque
profile_nickname	Pseudonyme	Obligatoire/Optionnel	Basique
profile_image	Image de profil	Obligatoire/Optionnel	Basique
account_email	Email	Optionnel	Vérification requise

(3) Indiquer clairement l’objectif pour chacun

(4) Save

Remarque : Les scopes sensibles nécessitent une vérification

4) Enregistrer la plateforme Web

(1) App Settings > Platform

(2) Register Web Platform

(3) Domaine du site : https://{domain}

(4) Save → doit correspondre au domaine de l’URI de redirection

5) Sécurité – Générer et activer le Client Secret

(1) Product Settings > Security

(2) Use Client Secret → ON

(3) Generate Secret → copier la valeur

(4) Activation Status → Active

(5) Save

Important : Il faut activer après génération

6) Obtenir la clé REST API (Client ID)

(1) App Keys

(2) Copier la REST API Key → l’utiliser comme Client ID

7) Paramètres WordPress

(1) Admin WP → SESLP Settings → Kakao

(2) Client ID = REST API Key
Client Secret = Secret généré

(3) Save

(4) Tester avec le bouton de connexion Kakao

8) Dépannage

(1) redirect_uri_mismatch → correspondance à 100 % requise

(2) invalid_client → Secret non activé ou erreur de saisie

(3) email vide → utilisateur refusé ou non vérifié

(4) Domain mismatch → plateforme vs URI de redirection

(5) HTTP interdit → HTTPS uniquement

Journaux :

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

9) Liste de vérification récapitulative

• Kakao Login activé
• URI de redirection enregistrée
• Domaine de la plateforme Web enregistré
• Éléments de consentement configurés
• Client Secret généré et activé
• REST API Key / Secret enregistrés dans SESLP
• Test effectué sur frontend HTTPS

• URI de redirection : https://{domain}/?social_login=line
• Requis : Activer OpenID Connect, demander et obtenir l’approbation pour l’autorisation e-mail
• Scopes recommandés : openid, profile, email
• HTTPS obligatoire, l’autorisation e-mail nécessite une approbation

---

1) Créer un provider et un channel

(1) Accédez à la console LINE Developers

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

(2) Connectez-vous avec un compte LINE Business (les comptes personnels ne sont pas autorisés)

(3) Cliquez sur Create a new provider → saisissez le nom → Create

(4) Dans le provider → onglet Channels

(5) Sélectionnez Create a LINE Login channel

(6) Configurez :

• Type de channel : LINE Login
• Provider : sélectionner le provider créé
• Région : pays cible (ex. South Korea, Japan)
• Nom / description / icône : affichés sur l’écran de consentement

(7) Acceptez les conditions → Create

2) Activer OpenID Connect et demander l’autorisation e-mail

(1) Accédez à OpenID Connect dans le menu de gauche

(2) Cliquez sur Apply à côté de Email address permission

(3) Remplissez la demande :

• URL de la politique de confidentialité (doit être accessible publiquement)
• Téléverser une capture d’écran de la politique de confidentialité
• Soumettre

(4) Le scope email fonctionne uniquement après approbation
→ L’approbation prend généralement 1 à 3 jours ouvrables

3) Enregistrer l’URL de callback et publier le channel

(1) Accédez à LINE Login dans le menu de gauche

(2) Saisissez l’URL de callback :

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

(3) Correspondance exacte requise :

• Protocole : https:// (HTTP non autorisé)
• Domaine, chemin, paramètres doivent correspondre à 100 %

(4) Cliquez sur Save

(5) Passez le statut du channel à Published

• Mode développement : test uniquement
• Published : service en production

4) Obtenir le Channel ID / Secret

(1) En haut du channel ou dans Basic settings

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

5) Paramètres WordPress

(1) Admin WP → SESLP Settings → LINE

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

(3) Save

(4) Tester avec le bouton de connexion LINE sur le frontend

6) Dépannage

(1) redirect_uri_mismatch → même une légère différence provoque une erreur → correspondance à 100 %

(2) invalid_client → erreur dans le secret ou channel non publié

(3) email NULL → autorisation e-mail non approuvée ou refus utilisateur

(4) HTTP non autorisé → HTTPS requis (localhost HTTPS possible)

(5) Limitation du mode développement → seuls les comptes de test peuvent se connecter

Journaux :

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

7) Liste de vérification récapitulative

• Création du Provider + channel LINE Login avec un compte Business
• Autorisation e-mail demandée et approuvée
• URL de callback enregistrée exactement
• HTTPS utilisé, statut Published
• Channel ID/Secret enregistrés dans SESLP
• Test de connexion frontend terminé

Remarque : SESLP prend entièrement en charge

• LINE Login v2.1 + OpenID Connect.
• La collecte de l’e-mail nécessite une approbation préalable.