# Execução parcial — `MG-4` Autenticação no Firebase Auth

**Story:** `docs/stories/MG-4-auth-firebase.md` · **Data:** 07/08/2026
**Ambiente:** emuladores de Auth, Firestore e Functions (`demo-bolao`).

**Resultado: ⚠️ parcial.** O lado do servidor está feito e verificado (4 casos, suíte
de 70). As tasks de app (`FE-1` a `FE-3`) **seguem abertas** — trocar o login para o
SDK do Firebase mexe na camada de dados do app, que é o assunto de `MG-7`, e marcar
agora seria dizer que o participante já entra pelo Firebase.

| ID | Resultado | O que verifica |
| -- | --------- | -------------- |
| MG-4-01 | ✅ | conta nova ganha perfil sem o app precisar criar |
| MG-4-02 | ✅ | conta sem nome não vira linha anônima no ranking |
| MG-4-03 | ⚠️ **descoberta** | o Auth aceita senha de 6; o mínimo de 8 é nosso |
| MG-4-04 | ✅ | e-mail duplicado é recusado pelo Auth |

## Três coisas que o backend antigo garantia e o Auth **não** garante sozinho

Sondei o Auth em vez de assumir, e o resultado muda o que precisa ser feito:

**1. Mínimo de senha é 6, não 8.** A política do produto é 8 (`AC-1`), e o app valida
antes de chamar. Mas quem falar direto com a API cria conta com 6. Fechar isso exige
política de senha do **Identity Platform** ou uma *blocking function* — as duas são
upgrade do plano de Auth. Registrado com o número real; a decisão é do dono.

**2. 🔴 O Auth distingue senha errada de e-mail inexistente.** No emulador:

```
senha errada       → auth/wrong-password
e-mail inexistente → auth/user-not-found
```

Isso **quebra `AC-2-02`**, que existe justamente para o login não virar oráculo de
enumeração: com respostas diferentes, dá para descobrir quem tem conta testando
e-mails. O backend antigo devolvia resposta idêntica de propósito, e havia caso e2e
travando.

A correção existe e é configuração, não código: *email enumeration protection* nas
configurações de Auth, que faz os dois virarem `auth/invalid-credential`. **Não dá
para verificar em emulador** — o emulador não implementa essa proteção. Precisa ser
conferido no projeto real, e é a primeira coisa da lista de `MG-8`.

**3. Limite de tentativas não é verificável aqui.** O emulador não aplica rate limit.
`AC-2-03` e `AC-2-04` (bloqueio depois de erros repetidos, valendo até para a senha
correta) passam a depender do comportamento do Auth em produção, com número que
precisa ser **medido e registrado**, não suposto.

## Dois defeitos meus, nos testes

**Teste que dependia de outro teste.** `MG-4-04` usava a conta criada em `MG-4-01` e
só passava com a suíte inteira, na ordem. Rodado isolado, passava por engano — e
execução isolada é justamente como se investiga uma falha. Virou auto-contido.

**Asserção por mensagem em inglês.** Eu esperava `/already exists/` e a mensagem real
é "already in use". Trocado pelo **código** (`auth/email-already-exists`): texto vindo
do fornecedor muda sem avisar, código não.

## Observações

- O perfil é criado por **gatilho do Auth**, não pelo app: se dependesse do app, uma
  falha de rede logo depois do cadastro deixaria a pessoa sem nome no ranking. O
  gatilho é v1 de propósito — o equivalente v2 é *blocking function* e exige
  Identity Platform.
- Conta sem `displayName` cai para o trecho antes do `@`. Gravar vazio deixaria uma
  linha de ranking que ninguém identifica.
