7bc4b2e819cc243f3c6f3b698f9638a2d3b9622b
Achado real: ACCESS_TOKEN_TTL = 15min e apiFetch nunca tentava nenhum refresh — qualquer reload (ou até só navegar) depois de 15min logado batia 401 em toda Server Component que chamasse a API, e o erro (ApiError cru, JSON da API) subia sem tratamento nenhum até virar a tela de erro genérica do Next.js. Reportado pelo usuário: "Ctrl+F5" depois de um tempo deu "Token de acesso inválido ou expirado". apps/frontend/src/middleware.ts (novo) decodifica o exp do access token guardado no cookie (só leitura, sem verificar assinatura — isso continua sendo a API) e, se faltar menos de 60s pra vencer, chama POST /auth/refresh antes da Server Component rodar, gravando o cookie novo tanto na resposta quanto na própria requisição (padrão documentado do Next.js — sem isso a MESMA requisição que disparou o refresh ainda leria o cookie velho). Rede de segurança pro caso do refresh token também ter vencido/sido revogado: apps/frontend/src/app/error.tsx detecta uma mensagem de sessão expirada, desloga e manda pro /login sozinho, em vez de mostrar a tela crua de erro. Tem que ficar na raiz de app/, não dentro de app/app/ ou app/platform/ — error.tsx nunca pega erro do próprio layout do mesmo segmento (achado testando o primeiro corte). Testado ponta a ponta com refresh token de verdade: token forjado pra vencer em 20s + refresh token real → renovação automática confirmada, página protegida carrega normal. Com refresh token inválido de propósito → confirmado o fallback: error boundary detecta, desloga e redireciona pro login sozinho. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BFaBaBSQGhyXGEgtTYZGV8
Description
Languages
TypeScript
98.3%
Dockerfile
1.3%
CSS
0.3%
Shell
0.1%