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)

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

• 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

• 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

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

• 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

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