0003 — Login Firebase (Google) nas views server-rendered¶
Status: Aprovado · Responsável: Gustavo Madruga · Atualizado em: 2026-07-06 · Decidido em: 2026-05-21
Contexto¶
As telas server-rendered (/processamentos/**, /admin/**) são operadas por
gente da X-Adm — incluindo o botão de nuke da replicação PowerSync, uma operação
destrutiva. Diferente do /api/** (Bearer, máquina — ver
0002), essas views precisam de identidade humana e
allowlist. Não faz sentido a equipe gerir mais um cadastro de senhas.
Decisão¶
Login Google via Firebase (projeto xadm-6ab81, compartilhado entre os apps
X-Adm), restrito a e-mails @xadm.com.br. Após o login, o app emite um cookie
de sessão xadm_session (JWT HS256, TTL 8h). O gate das views é aplicado no
servidor; os forms POST das views carregam token CSRF (_csrf). O allowlist por
domínio é aplicado no login (spec 006).
Correção 2026-07-16: o texto original dizia que o gate estava num
security/AuthFilter. Isso era como o gate foi implementado na época, não a decisão — e mudou: hoje o gate roda dentro domicronaut-security(autenticador de sessão + regra de segurança), sem filtro paralelo. A decisão (login Google/Firebase restrito ao domínio, com cookie de sessão) segue válida e inalterada; o desenho vivo está na etapa 06.
Consequências¶
- Zero senhas próprias: SSO Google reaproveitado do projeto Firebase da casa.
- Comportamento por ambiente: sem as envs
AUTH_*, emdev/testas views ficam públicas (bypass para desenvolvimento); em produção o acesso é fail-closed (503) — nunca abre por engano. - Allowlist é por domínio (
@xadm.com.br), não enumeração por e-mail; endurecer para lista explícita é ajuste pontual emAuthSettings, não reescrita.
Alternativas consideradas¶
- Basic Auth / usuário-senha local: mais um cadastro para manter e rotacionar. Descartado em favor do SSO Google.
- Bearer estático também nas views: inadequado para acesso humano de browser (sem sessão, sem CSRF, sem identidade). Descartado.