Requisição 169 — Controle de Acessos: proteger sem punir o cliente legítimo

O controle antiabuso por IP (acessos) cumpre o papel de barrar flood e força bruta, mas hoje pune com a mesma severidade o cliente que erra a senha ou o preenchimento. Esta…

O controle antiabuso por IP (acessos) cumpre o papel de barrar flood e força bruta, mas hoje pune com a mesma severidade o cliente que erra a senha ou o preenchimento. Esta requisição ajusta o equilíbrio: manter a proteção contra automação e devolver ao usuário legítimo uma segunda chance em minutos, com informação clara de quando poderá tentar de novo.

Origem: operação do [REDACTED] em 17 e 18/09/2026. Um cliente pagante ficou 24 horas sem conseguir entrar após 10 tentativas de senha (req-104, contas 42 e 43 do projeto [REDACTED]), e a homologação do checkout esbarrou duas vezes na cota diária de formulário — inclusive por erros de validação, que consomem cota igual a envios válidos.

1. Diagnóstico

Bloqueio de login de 24 horas. ACESSOS_MAXIMO_FALHAS_LOGINS=10 com ACESSOS_TEMPO_BLOQUEIO_IP=86400. Contra força bruta o que importa é frear a taxa; quem tem botnet troca de IP, e quem paga fica de fora por um dia. O IP ainda é compartilhado por operadora móvel e por rede de clínica inteira.
reCAPTCHA desativado. A escada prevista (livre → antispam com captcha → bloqueio) está sem o degrau do meio, então o bloqueio faz todo o trabalho e precisa ser rígido.
Erro de validação consome cota de formulário. formulario_acesso_falha() é chamada em todos os ramos de validação (campo obrigatório vazio, tamanho mínimo, e-mail inválido, URL inválida). Um cliente atrapalhado — ou com cartão recusado, que refaz o checkout — queima FORMULARIOS_MAXIMO_CADASTROS em minutos e fica 24 horas sem conseguir assinar.
Mensagem sem prazo. As telas dizem "tente novamente mais tarde", sem informar quando libera. Gera suporte e desconfiança.

2. Escopo

2.1 Separar erro de validação de sinal de abuso

formulario_acesso_falha() passa a receber a origem da falha: validacao (erro do usuário) ou abuso (reCAPTCHA reprovado, ausência de token).
Falha de validação continua contando, porém contra um teto próprio e folgado (FORMULARIOS_MAXIMO_VALIDACOES), para que digitação errada não consuma a cota de envios válidos e ainda assim exista limite para robô que dispara lixo.
reCAPTCHA reprovado e ausência de token seguem contando como abuso, no teto atual.

2.2 Informar quando o bloqueio termina

autenticacao_acesso_verificar() passa a devolver também o instante de liberação (tempo_bloqueio).
As telas de bloqueio (login e formulário) exibem a data e a hora exatas de liberação, no fuso do site, com marcador substituível para que projetos com telas próprias adotem o mesmo texto.

2.3 Rever os valores padrão de instalação

ACESSOS_TEMPO_BLOQUEIO_IP: 86400 → 900 (15 minutos). A multiplicação por bloqueios reincidentes, que já existe no código, mantém a escada: 15, 30, 45 minutos.
FORMULARIOS_TEMPO_BLOQUEIO_IP: 86400 → 3600.
ACESSOS_MAXIMO_CADASTROS_SIGNUP: 3 → 6.
FORMULARIOS_MAXIMO_CADASTROS: 10 (mantido) e FORMULARIOS_MAXIMO_VALIDACOES: 40 (novo).
ACESSOS_MAXIMO_FALHAS_LOGINS e ACESSOS_MAXIMO_LOGINS_SIMPLES: mantidos em 10 e 3.

2.4 Propagação

Atualizar o .env de template de instalação.
Registrar no batch os valores a aplicar nos .env de produção (conn2flow.com, [REDACTED].com, [REDACTED].com), aplicados com autorização expressa do operador.

3. Critérios de Aceitação

Erro de digitação não bloqueia a compra: dez reprovações de validação seguidas no mesmo formulário não impedem o envio válido seguinte.
Abuso continua barrado: reCAPTCHA reprovado mantém o comportamento atual de contagem e bloqueio.
Prazo visível: as telas de bloqueio informam data e hora de liberação.
Escada preservada: reincidência aumenta o tempo de bloqueio, como já acontece hoje.
Sintaxe e testes: php -l limpo e a suíte do núcleo sem regressão.

# Requisição 169 — Controle de Acessos: proteger sem punir o cliente legítimo
O controle antiabuso por IP (`acessos`) cumpre o papel de barrar flood e força bruta, mas hoje pune com a mesma severidade o cliente que erra a senha ou o preenchimento. Esta requisição ajusta o equilíbrio: manter a proteção contra automação e devolver ao usuário legítimo uma segunda chance em minutos, com informação clara de quando poderá tentar de novo.
Origem: operação do [REDACTED] em 17 e 18/09/2026. Um cliente pagante ficou 24 horas sem conseguir entrar após 10 tentativas de senha (req-104, contas 42 e 43 do projeto [REDACTED]), e a homologação do checkout esbarrou duas vezes na cota diária de formulário — inclusive por erros de validação, que consomem cota igual a envios válidos.
---
## 1. Diagnóstico
* **Bloqueio de login de 24 horas.** `ACESSOS_MAXIMO_FALHAS_LOGINS=10` com `ACESSOS_TEMPO_BLOQUEIO_IP=86400`. Contra força bruta o que importa é frear a taxa; quem tem botnet troca de IP, e quem paga fica de fora por um dia. O IP ainda é compartilhado por operadora móvel e por rede de clínica inteira.
* **reCAPTCHA desativado.** A escada prevista (livre → antispam com captcha → bloqueio) está sem o degrau do meio, então o bloqueio faz todo o trabalho e precisa ser rígido.
* **Erro de validação consome cota de formulário.** `formulario_acesso_falha()` é chamada em todos os ramos de validação (campo obrigatório vazio, tamanho mínimo, e-mail inválido, URL inválida). Um cliente atrapalhado — ou com cartão recusado, que refaz o checkout — queima `FORMULARIOS_MAXIMO_CADASTROS` em minutos e fica 24 horas sem conseguir assinar.
* **Mensagem sem prazo.** As telas dizem "tente novamente mais tarde", sem informar quando libera. Gera suporte e desconfiança.
---
## 2. Escopo
### 2.1 Separar erro de validação de sinal de abuso
* `formulario_acesso_falha()` passa a receber a origem da falha: `validacao` (erro do usuário) ou `abuso` (reCAPTCHA reprovado, ausência de token).
* Falha de validação continua contando, porém contra um teto próprio e folgado (`FORMULARIOS_MAXIMO_VALIDACOES`), para que digitação errada não consuma a cota de envios válidos e ainda assim exista limite para robô que dispara lixo.
* reCAPTCHA reprovado e ausência de token seguem contando como abuso, no teto atual.
### 2.2 Informar quando o bloqueio termina
* `autenticacao_acesso_verificar()` passa a devolver também o instante de liberação (`tempo_bloqueio`).
* As telas de bloqueio (login e formulário) exibem a data e a hora exatas de liberação, no fuso do site, com marcador substituível para que projetos com telas próprias adotem o mesmo texto.
### 2.3 Rever os valores padrão de instalação
* `ACESSOS_TEMPO_BLOQUEIO_IP`: 86400 → 900 (15 minutos). A multiplicação por bloqueios reincidentes, que já existe no código, mantém a escada: 15, 30, 45 minutos.
* `FORMULARIOS_TEMPO_BLOQUEIO_IP`: 86400 → 3600.
* `ACESSOS_MAXIMO_CADASTROS_SIGNUP`: 3 → 6.
* `FORMULARIOS_MAXIMO_CADASTROS`: 10 (mantido) e `FORMULARIOS_MAXIMO_VALIDACOES`: 40 (novo).
* `ACESSOS_MAXIMO_FALHAS_LOGINS` e `ACESSOS_MAXIMO_LOGINS_SIMPLES`: mantidos em 10 e 3.
### 2.4 Propagação
* Atualizar o `.env` de template de instalação.
* Registrar no batch os valores a aplicar nos `.env` de produção (`conn2flow.com`, `[REDACTED].com`, `[REDACTED].com`), aplicados com autorização expressa do operador.
---
## 3. Critérios de Aceitação
1. **Erro de digitação não bloqueia a compra:** dez reprovações de validação seguidas no mesmo formulário não impedem o envio válido seguinte.
2. **Abuso continua barrado:** reCAPTCHA reprovado mantém o comportamento atual de contagem e bloqueio.
3. **Prazo visível:** as telas de bloqueio informam data e hora de liberação.
4. **Escada preservada:** reincidência aumenta o tempo de bloqueio, como já acontece hoje.
5. **Sintaxe e testes:** `php -l` limpo e a suíte do núcleo sem regressão.