> Este documento explica como configurar cada provedor de login social (Google, Facebook, LinkedIn, Naver, Kakao, LINE) no plugin Simple Easy Social Login (SESLP).

> Todos os logins são baseados em OAuth 2.0 / OpenID Connect (OIDC).
> Você precisa criar um app (cliente) no console de cada provedor e inserir o Client ID / Client Secret no SESLP.

## 🔧 Guia de configuração comum

#### 1) Regra da Redirect URI:

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

Exemplos:

- 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 é obrigatório.

A maioria dos provedores exige HTTPS e rejeitará redirecionamentos com `http://`.

#### 3) Correspondência exata

A Redirect URI no console deve corresponder 100% ao que o SESLP envia (protocolo, subdomínio, caminho, barra final e query string).

#### 4) O e-mail pode não estar disponível

Alguns provedores permitem que os usuários neguem o compartilhamento do e-mail. O SESLP pode usar IDs estáveis do provedor para vincular contas.

#### 5) Onde verificar os logs

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

## 🐞 Log de depuração e solução de problemas

Como ler os logs de depuração do SESLP

#### Localização do arquivo de log

- `/wp-content/SESLP-debug.log` (log de depuração do SESLP)
- `/wp-content/debug.log` (`WP_DEBUG_LOG = true`)

#### Formato do log

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

- `Z`: UTC ou horário local do WordPress (ex.: KST) — selecionável nas configurações do SESLP
- Privacidade: e-mails/tokens/secrets são mascarados automaticamente (exemplo: `r********@g****.com`)

#### Logs do fluxo OAuth (gerais)

1) Início do OAuth

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

Significado: foi criado um token state para proteção CSRF. `ttl` é válido por 10 minutos.

2) Callback acionado

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

Significado: o callback foi acionado. `has_code:1` → o `code` do OAuth foi recebido.

3) Validação do state

Sucesso:

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

Falha:

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

4) Troca de token

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

Significado: token obtido.

Falha:

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

5) Requisição de informações do usuário

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

6) Vinculação do usuário

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

7) Redirecionamento

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

#### Tabela de referência rápida

Mensagem de log (resumo) | Causa provável | Ação
--- | --- | ---
State validation failed | Timeout, troca de aba, requisição duplicada | Tente novamente rapidamente, use modo privado
Token request failed | Client ID/secret/redirect incorreto, requisição bloqueada | Verifique o console do desenvolvedor, firewall e horário do servidor
Userinfo invalid | Scope ausente ou e-mail privado | Adicione os scopes `email, profile` e solicite consentimento do usuário
User create failed | Conflito de conta ou restrição do WordPress | Verifique usuários existentes e regras de multisite
Redirect missing | Retorno antecipado no código | Garanta que a classe Redirect seja executada após o callback

#### Informações úteis para incluir em relatórios de bug

- Linhas de log relevantes (mascaradas)
- Provedor usado (Google/Naver/etc.)
- Modo de redirecionamento / URL personalizada
- Estado do log de depuração
- Ambiente WordPress (site único, multisite, plugins de cache)

## 🌍 Guias de provedores

Expanda cada provedor abaixo e cole o conteúdo do guia em inglês que você preparou para esse provedor.

Google

- Escopos recomendados: `openid email profile`
- Regra da Redirect URI: `https://{domain}/?social_login=google`

#### 1) Preparação (Checklist obrigatório)

(1) HTTPS recomendado/essencial (use certificados de desenvolvimento confiáveis para ambientes locais).

(2) A Redirect URI deve corresponder exatamente 100% ao valor registrado no console. Ex.: `https://example.com/?social_login=google`

(3) No modo de teste, apenas usuários de teste podem fazer login (até 100 usuários).

(4) Ao usar URLs de homepage/política de privacidade/termos do app, pode ser necessário registrar domínios do app (Authorized domains) e fazer verificação de propriedade.

#### 2) Configuração do projeto/tela de consentimento

(1) Acesse o Google Cloud Console.
https://console.cloud.google.com/apis/credentials

(2) Selecione o projeto no topo → Criar novo projeto (se necessário).

(3) Barra lateral: vá para APIs e Serviços → Tela de consentimento OAuth.

(4) Selecione o Tipo de usuário: normalmente Externo.

(5) Insira as Informações do app: nome do app, e-mail de suporte, (opcional) logotipo.

(6) Seção Domínio do app

- Insira URL da homepage, política de privacidade e termos de serviço
- Adicione o domínio raiz (ex.: example.com) em Authorized domains → Salvar
- Se necessário, faça a verificação de propriedade do domínio via Search Console.

(7) Configure os Escopos

- Recomendado: `openid`, `email`, `profile`
- Escopos sensíveis/restritos podem exigir revisão antes da publicação.

(8) Adicione usuários de teste (e-mails autorizados no modo de teste).

(9) Salvar.

Observação: Usando apenas os escopos básicos (`openid email profile`), geralmente é possível operar (publicar) sem revisão.

#### 3) Criar cliente OAuth (Aplicação Web)

(1) Barra lateral: APIs e Serviços → Credenciais.

(2) Topo: + Criar credenciais → ID do cliente OAuth.

(3) Tipo de aplicação: `Aplicação Web`.

(4) Insira um Nome identificável (ex.: `SESLP – Front`).

(5) Adicione URIs de redirecionamento autorizadas

- `https://{domain}/?social_login=google`

(6) Clique em Criar e copie o Client ID / Client Secret exibido.

(Opcional) Origins JavaScript autorizadas geralmente não são necessárias para este plugin (code grant).

#### 4) Configuração no WordPress (plugin)

(1) WP Admin → SESLP Settings → Google.

(2) Cole Client ID / Client Secret → Salvar.

(3) Teste com o botão de login do Google no frontend.

#### 5) Alternar de teste para produção

(1) Verifique Tela de consentimento OAuth → Status de publicação.

(2) Para mudar para produção:

- Confirme que as informações do app (logo/domínio/políticas/termos) estão corretas.
- Remova escopos desnecessários e mantenha apenas os necessários.
- Envie para revisão se usar escopos sensíveis.

(3) Após a publicação, todas as contas Google poderão fazer login.

#### 6) Erros comuns e soluções

(1) redirect_uri_mismatch

→ Ocorre quando a URI registrada e a URI enviada diferem (protocolo, subdomínio, barra, query). Ajuste para corresponder exatamente.

(2) access_denied / disallowed_useragent

→ Restrição de ambiente (browser/app). Tente em um navegador padrão.

(3) invalid_client / unauthorized_client

→ Erro no Client ID/Secret ou status do app. Verifique ou regenere.

(4) Email vazio

→ Verifique o escopo `email`, consentimento e configurações de privacidade da conta.

Verificar logs:

- `wp-content/SESLP-debug.log` (debug do plugin ativado)
- `wp-content/debug.log` (`WP_DEBUG`, `WP_DEBUG_LOG = true`)

#### 7) Checklist resumido

- Tela de consentimento configurada
- Cliente OAuth criado (Web Application)
- Redirect URI registrada corretamente
- Client ID/Secret salvos no SESLP
- Status de publicação ajustado (se necessário)

Facebook

- Redirect URI: `https://{domain}/?social_login=facebook`
- Permissões solicitadas (Recomendado): `public_profile`, `email`
- O Facebook não utiliza `openid`.

#### 1) Criar App e adicionar produto

(1) Acesse Meta for Developers → Faça login
https://developers.facebook.com/

(2) Clique em Create App → Selecione um tipo geral (ex.: Consumer) → Criar app

(3) No menu lateral esquerdo, adicione Facebook Login em Products

(4) Vá em Settings → Verifique os itens:

- Client OAuth Login: ON
- Web OAuth Login: ON
- Valid OAuth Redirect URIs:
- Adicione `https://{domain}/?social_login=facebook`
- (Opcional) Enforce HTTPS: recomendado por padrão

#### 2) Configurações básicas do app (App Settings → Basic)

(1) App Domains: `example.com`

(2) URL da Política de Privacidade: página pública acessível

(3) URL dos Termos de Serviço: página pública acessível

(4) Exclusão de dados do usuário: fornecer URL ou endpoint

(5) Categoria / Ícone do app: configurar → Salvar

#### 3) Escopos (Permissões) e revisão do app

(1) Permissão básica: `public_profile`; e-mail opcional: `email`

(2) Na maioria dos casos, `email` pode ser usado sem revisão

(3) Permissões avançadas exigem App Review e Business Verification

#### 4) Alterar modo (Development → Live)

Altere App Mode: Development → Live

#### 5) Checklist antes de ir para Live

- Preparar Política de Privacidade / Termos / URL de exclusão de dados
- Registrar corretamente a Redirect URI
- Remover permissões desnecessárias
- (Se necessário) Concluir App Review/Business Verification

#### 6) Configuração no WordPress (SESLP)

(1) WP Admin → SESLP Settings → Facebook

(2) Inserir App ID / App Secret → Salvar

(3) Testar com o botão de login do Facebook

#### 7) Solução de problemas

(1) Can't Load URL / erro de redirect_uri

→ Verifique correspondência exata da URI

(2) email null

→ Usuário não possui e-mail ou é privado → usar lógica baseada em ID

(3) Erros de permissão

→ Pode exigir revisão/verificação

(4) Não é possível ativar Live

→ URLs obrigatórias ausentes ou não públicas

LinkedIn

- Redirect URI: `https://{domain}/?social_login=linkedin`
- Configuração obrigatória: Ativar OpenID Connect (OIDC)
- Escopos recomendados: `openid`, `profile`, `email`
- O LinkedIn está descontinuando escopos antigos
- Novos apps devem usar OIDC

#### 1) Criar aplicação

(1) Acesse LinkedIn Developers Console

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

(2) Faça login

(3) Clique em Create app

(4) Preencha:

- Nome do app
- Página LinkedIn
- Logo
- Política de privacidade / e-mail

(5) Criar app

#### 2) Ativar OpenID Connect

(1) Aba Products

(2) Adicionar Sign In with LinkedIn using OpenID Connect

#### 3) Configurações OAuth

(1) Auth → OAuth 2.0 settings

(2) Adicionar Redirect URI:

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

#### 4) Obter Client ID / Secret

(1) Aba Auth

(2) Copiar credenciais

#### 5) Explicação dos escopos

Scope | Descrição | Nota
--- | --- | ---
`openid` | Token OIDC | Obrigatório
`profile` | Dados do usuário | Obrigatório
`email` | E-mail | Obrigatório

#### 6) Solução de problemas

(1) redirect_uri_mismatch

(2) invalid_client

(3) email NULL

(4) insufficient_scope

(5) OIDC não ativado

#### 7) Checklist

- App criado
- OIDC ativado
- Redirect URI registrada
- Credenciais salvas
- Escopos corretos

Nota:

- SESLP suporta totalmente OIDC
- OAuth antigo não é mais suportado

Naver

- Redirect URI: `https://{domain}/?social_login=naver`
- Escopos recomendados: Perfil básico (`name`), E-mail (`email`)
- O Naver usa a API Naver Login (네아로), e HTTPS é obrigatório

#### 1) Registro da aplicação

(1) Acesse o Naver Developer Center

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

(2) Faça login com sua conta Naver

(3) Clique em Application → Register Application

(4) Preencha os campos obrigatórios:

- Nome da aplicação: ex.: `MySite Naver Login`
- Uso da API: selecione `Naver Login (네아로)`
- Add Environment → Web
- URL do serviço: `https://example.com`
- URL de callback: `https://example.com/?social_login=naver`

(5) Concorde com os termos → Register

Observação:

- HTTPS é obrigatório → HTTP não é permitido
- Subdomínios devem ser registrados separadamente

#### 2) Obter Client ID / Client Secret

(1) Vá em My Applications

(2) Clique no app → copie o Client ID e o Client Secret

#### 3) Configurações do WordPress (plugin)

(1) WP Admin → SESLP Settings → Naver

(2) Cole o Client ID / Client Secret

(3) Certifique-se de que a Redirect URI corresponde exatamente a: `https://{domain}/?social_login=naver`

(4) Salvar → teste com o botão de login do Naver no frontend

#### 4) Permissões e fornecimento de dados

Dado | Scope | Observação
--- | --- | ---
Nome | `name` | Padrão
E-mail | `email` | Padrão
Gênero, aniversário | Separado | Requer revisão

- Os usuários podem aceitar/recusar na tela de consentimento
- Se o e-mail for recusado → `email = null` → use vinculação baseada em ID
- Dados sensíveis exigem revisão do app pelo Naver

#### 5) Solução de problemas

(1) Redirect URI mismatch

→ Mesmo uma pequena diferença causa erro → garanta 100% de correspondência

(2) Erro de HTTP

→ É obrigatório usar HTTPS

(3) Erro de subdomínio

→ Registre cada subdomínio separadamente

(4) email NULL

→ O usuário recusou ou o e-mail é privado → prepare lógica baseada em ID

(5) Revisão necessária

→ Login básico: sem revisão
→ Dados adicionais: requerem revisão

Logs:

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

#### 6) Checklist resumido

- App registrado no Naver Developer Center
- URL de callback registrada corretamente
- HTTPS em uso
- Subdomínios registrados separadamente (se necessário)
- Client ID/Secret salvos no SESLP
- Testado o comportamento de aceitar/recusar e-mail
- Teste de login no frontend concluído

Observação:

- O SESLP oferece suporte completo ao Naver Login (네아로).
- O login básico (`name`, `email`) está disponível sem revisão.

Kakao

- Redirect URI: `https://{domain}/?social_login=kakao`
- Escopos recomendados: `profile_nickname`, `profile_image`, `account_email`
- `account_email` disponível somente após verificação de identidade ou empresarial
- HTTPS obrigatório, ativação do Client Secret é obrigatória

#### 1) Criar aplicação

(1) Acesse Kakao Developers

→ https://developers.kakao.com/

(2) Faça login → My Applications → Add New App

(3) Insira:

- Nome do app, nome da empresa
- Categoria
- Concordar com a política de operação

(4) Salvar

#### 2) Ativar Kakao Login

(1) Product Settings > Kakao Login

(2) Ative Enable Kakao Login → ON

(3) Registrar Redirect URI

- `https://{domain}/?social_login=kakao`
- Salvar

(4) O domínio deve corresponder ao domínio da plataforma

#### 3) Itens de consentimento (Escopos)

(1) Consent Items

(2) Adicione e configure:

Scope | Descrição | Tipo de consentimento | Observação
--- | --- | --- | ---
`profile_nickname` | Apelido | Obrigatório/Opcional | Básico
`profile_image` | Imagem de perfil | Obrigatório/Opcional | Básico
`account_email` | E-mail | Opcional | Requer verificação

(3) Descreva claramente a finalidade de cada item

(4) Salvar

Observação: Escopos sensíveis exigem verificação

#### 4) Registrar plataforma Web

(1) App Settings > Platform

(2) Register Web Platform

(3) Domínio do site: `https://{domain}`

(4) Salvar → deve corresponder ao domínio da Redirect URI

#### 5) Segurança – Gerar e ativar Client Secret

(1) Product Settings > Security

(2) Use Client Secret → ON

(3) Generate Secret → copie o valor

(4) Activation Status → Active

(5) Salvar

Importante: é preciso ativar após gerar

#### 6) Obter REST API Key (Client ID)

(1) App Keys

(2) Copie a REST API Key → use como Client ID

#### 7) Configurações no WordPress

(1) WP Admin → SESLP Settings → Kakao

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

(3) Salvar

(4) Teste com o botão de login do Kakao

#### 8) Solução de problemas

(1) redirect_uri_mismatch → é necessária correspondência de 100%

(2) invalid_client → Secret não ativado ou erro de digitação

(3) email vazio → usuário recusou ou não foi verificado

(4) Domain mismatch → diferença entre plataforma e Redirect URI

(5) HTTP proibido → somente HTTPS

Logs:

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

#### 9) Checklist resumido

- Kakao Login ativado
- Redirect URI registrada
- Domínio da plataforma Web registrado
- Itens de consentimento configurados
- Client Secret gerado e ativado
- REST API Key / Secret salvos no SESLP
- Testado no frontend com HTTPS

LINE

- Redirect URI: `https://{domain}/?social_login=line`
- Obrigatório: Ativar OpenID Connect e solicitar e obter aprovação para a permissão de e-mail
- Escopos recomendados: `openid`, `profile`, `email`
- HTTPS obrigatório, a permissão de e-mail exige aprovação

#### 1) Criar Provider e Channel

(1) Acesse o LINE Developers Console

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

(2) Faça login com uma conta LINE Business (conta pessoal não é permitida)

(3) Clique em Create a new provider → Digite o nome → Create

(4) Dentro do provider → aba Channels

(5) Selecione Create a LINE Login channel

(6) Configure:

- Channel type: `LINE Login`
- Provider: selecione o provider criado
- Region: país-alvo (ex.: `South Korea`, `Japan`)
- Name / description / icon: exibidos na tela de consentimento

(7) Concorde com os termos → Create

#### 2) Ativar OpenID Connect e solicitar permissão de e-mail

(1) Vá para OpenID Connect no menu à esquerda

(2) Clique em Apply ao lado de Email address permission

(3) Preencha a solicitação:

- URL da Política de Privacidade (deve ser acessível publicamente)
- Envie uma captura de tela da Política de Privacidade
- Enviar

(4) O escopo `email` só funciona após aprovação
→ A aprovação normalmente leva de 1 a 3 dias úteis

#### 3) Registrar Callback URL e publicar o Channel

(1) Vá para LINE Login no menu à esquerda

(2) Insira a Callback URL:

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

(3) É necessária correspondência exata:

- Protocolo: `https://` (HTTP não permitido)
- Domínio, caminho e query string devem corresponder em 100%

(4) Clique em Save

(5) Altere o status do channel para Published

- Development mode: apenas teste
- Published: serviço em produção

#### 4) Obter Channel ID / Secret

(1) No topo do channel ou em Basic settings

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

#### 5) Configurações do WordPress

(1) WP Admin → SESLP Settings → LINE

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

(3) Salvar

(4) Teste com o botão de login do LINE no frontend

#### 6) Solução de problemas

(1) redirect_uri_mismatch → Mesmo uma pequena diferença gera erro → garanta 100% de correspondência

(2) invalid_client → Erro de digitação no Secret ou channel não publicado

(3) email NULL → Permissão de e-mail não aprovada ou usuário recusou

(4) HTTP não permitido → HTTPS obrigatório (localhost com HTTPS é aceito)

(5) Limite do modo de desenvolvimento → Apenas contas de teste podem fazer login

Logs:

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

#### 7) Checklist resumido

- Provider + channel LINE Login criados com conta Business
- Permissão de e-mail solicitada e aprovada
- Callback URL registrada corretamente
- HTTPS em uso, status Published
- Channel ID/Secret salvos no SESLP
- Teste de login no frontend concluído

Observação: O SESLP oferece suporte completo a:

- LINE Login v2.1 + OpenID Connect.
- A coleta de e-mail exige aprovação prévia.