SeConectai_Vendas/Etapas/V2/13-frontend-autenticacao-tema.md

Etapa 13 — Autenticação e Tema Dinâmico (Whitelabel)

Contexto do projeto

Continuação do frontend do SeConectai Vendas. Já existem: projeto configurado (Etapa 11) e a biblioteca de componentes base (Etapa 12). O backend já expõe toda a API de autenticação (login master/tenant, refresh, esqueci senha) e o endpoint público de tema por tenant (definidos nas Etapas 2 e 8 do backend).

Objetivo desta etapa

Implementar as telas públicas de autenticação, o mecanismo de sessão no client (armazenamento de token, renovação automática, proteção de rotas), e a resolução do tema (logo + cor) por tenant antes mesmo do login.

Tarefas

1. Telas públicas (app/(public)/)

   • /login: formulário de e-mail + senha. Deve detectar se o login é de master ou de tenant (definir estratégia: campo oculto/toggle, ou dois formulários, ou detecção automática pelo backend a partir do e-mail — escolher a mais simples de implementar e documentar a decisão). Erros de credencial inválida devem ser claros mas não revelar se o e-mail existe ou não (mensagem genérica "e-mail ou senha inválidos").
   • /esqueci-senha: formulário de e-mail, chama o endpoint de recuperação, sempre mostra mensagem de sucesso genérica (não revelar se o e-mail existe no sistema).
   • /redefinir-senha/[token]: formulário de nova senha (com confirmação), valida força mínima no client espelhando a regra do backend, trata token expirado/inválido com mensagem clara.
   • Todas essas telas devem ser totalmente responsivas: em mobile, formulário ocupa a largura da tela com padding adequado; em desktop, formulário centralizado com largura máxima (ex: 420px) e fundo com identidade visual do tema resolvido (ver item 3).

2. Gerenciamento de sessão (lib/auth/)

   • Access token guardado em memória (ex: em um Context/store, não em localStorage/sessionStorage).
   • Refresh token: o backend deve setar como cookie httpOnly; o client não manipula esse cookie diretamente, apenas confia que ele é enviado automaticamente nas chamadas relevantes.
   • Interceptor no lib/api/client.ts (gancho deixado pronto na Etapa 11): ao receber 401, tenta chamar o endpoint de refresh automaticamente; se conseguir, repete a requisição original com o novo token; se falhar, desloga e redireciona para /login.
   • Função logout() que limpa o estado em memória e chama o endpoint de logout do backend (revoga o refresh token no servidor).

3. Middleware de proteção de rotas

   • Middleware do Next.js protegendo /master/* e /app/*: verifica se existe sessão válida (ex: checando um cookie de sinalização não sensível, já que o access token real fica só em memória no client — definir estratégia de verificação no servidor sem expor o token) e redireciona para /login se não houver.
   • Usuário master tentando acessar /app/* (ou vice-versa) deve ser redirecionado para a área correta, não para login.
   • Após login bem-sucedido, redirecionar automaticamente para /master/dashboard ou /app/dashboard conforme o tipo de usuário retornado pela API.

4. Tema dinâmico por tenant (lib/theme/)

   • Na tela /login, antes de qualquer autenticação, resolver o tema: se a URL/subdomínio/parâmetro identificar um tenant específico, chamar o endpoint público /public/tenants/:slugOuId/tema e aplicar --color-primary e o logo retornados. Se não houver tenant identificável (ex: acesso genérico), mostrar o tema padrão da plataforma.
   • Após o login, na área /app, resolver o tema a partir do perfil do tenant autenticado (não precisa mais do endpoint público).
   • Implementar a validação de contraste descrita na seção 6 do schema: se cor_primaria do tenant não atingir contraste mínimo (WCAG AA) contra branco, escurecer automaticamente antes de aplicar como cor de texto/ícone sobre fundo colorido (manter a cor original para fundos, ajustar só onde teria problema de legibilidade).

5. Feedback de erro e loading

   • Todos os formulários desta etapa usam os componentes FormField, Button (estado loading) e Toast já construídos na Etapa 12 — nenhuma solução de UI paralela aqui.

Critérios de aceite

• Login master e login tenant funcionam ponta a ponta com o backend real
• Sessão expira corretamente e é renovada automaticamente via refresh (testar deixando o access token expirar e fazendo uma ação)
• Logout limpa a sessão e o backend revoga o refresh token
• Middleware bloqueia acesso não autenticado a /master/* e /app/*, redirecionando para /login
• Usuário master não consegue acessar /app/* diretamente pela URL (e vice-versa) sem ser redirecionado
• Fluxo completo de esqueci/redefinir senha funciona, incluindo tratamento de token expirado
• Tela de login aplica a cor/logo do tenant certo quando o tenant é identificável, e cai no tema padrão quando não é
• Cor de tenant com baixo contraste é ajustada automaticamente onde necessário, sem quebrar a legibilidade
• Todas as telas desta etapa testadas em 375px, 768px e 1280px