From 7656f2261e1db2eab52e189dac791909ea27b1b2 Mon Sep 17 00:00:00 2001 From: Gustavo Date: Thu, 13 Aug 2026 21:19:09 -0300 Subject: [PATCH] docs: corrige README contraditorio sobre HTTP Basic e SESSION_SECRET MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 1. Frase de abertura ainda dizia 'login HTTP Basic em toda rota', contradizendo a secao 'Login e permissoes' mais abaixo no mesmo arquivo (ja correta, fala de login por sessao). Atualizada para 'login por sessao em toda rota'. 2. A lista de variaveis de ambiente para rodar localmente (secao 'Rodando localmente') nao mencionava SESSION_SECRET, mesmo a secao 'Login e permissoes' ja instruindo a defini-la. Adicionada a lista, com nota de que e opcional em dev (chave aleatoria em memoria a cada start, sessoes caem a cada restart) mas deve ser fixa em producao. 3. A mencao ao ALTER TABLE FUNCIONARIO_PAINEL ADD COLUMN PERFIL estava em tom de fato passado. Ajustada para o mesmo padrao de aviso ja usado para LOG_PAINEL/FUNCIONARIO_PAINEL nesse README ('precisa ser rodado manualmente em producao tambem'), deixando explicito que sem rodar isso todo login falha com 500 (a query de autenticacao seleciona uma coluna PERFIL que nao existe na tabela antiga). Sem teste automatizado - mudanca só de documentacao. Co-Authored-By: Claude Sonnet 5 --- README.md | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/README.md b/README.md index 05077b5..d271dc4 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,7 @@ Painel administrativo (FastAPI + Jinja2) para gestão de `CLIENTE`, `CLIENTE_CONTATO` e geração manual de chave de licenciamento no MySQL do sistema legado. -Proteções: login HTTP Basic em toda rota, CSRF via cookie de duplo envio (`app/csrf.py` — todo formulário que muda estado embute o mesmo token do cookie `csrf_token`, definido pelo middleware em `app/main.py`) e a lista de clientes é paginada (100 por página), com busca e ordenação por código/razão/fantasia/CNPJ. +Proteções: login por sessão em toda rota (cookie assinado — ver seção "Login e permissões" abaixo), CSRF via cookie de duplo envio (`app/csrf.py` — todo formulário que muda estado embute o mesmo token do cookie `csrf_token`, definido pelo middleware em `app/main.py`) e a lista de clientes é paginada (100 por página), com busca e ordenação por código/razão/fantasia/CNPJ. `CODIGO` de cliente não aceita duplicado (bloqueio duro, sem bypass) e o formulário de novo cliente já sugere o próximo código sequencial (editável). Só `CODIGO`, `CNPJ`, `RAZAO` e `FANTASIA` são obrigatórios — os campos de contrato (implantação, mensalidade, juros, datas) podem ficar em branco e recebem default (0,00 / data de hoje). @@ -21,11 +21,15 @@ ser criada manualmente em produção também**, DDL no início de `app/db/funcionarios.py`) tem um perfil: **admin** (gerencia outros funcionários em `/funcionarios`: cadastra, edita, redefine senha, ativa/desativa, promove/rebaixa perfil) ou **padrão** (sem acesso a -`/funcionarios`). Todo funcionário cadastrado antes dessa funcionalidade -existir virou admin automaticamente na migração (`ALTER TABLE -FUNCIONARIO_PAINEL ADD COLUMN PERFIL ...`, mesmo arquivo). O sistema nunca -deixa ficar sem nenhum admin ativo — rebaixar ou desativar o último admin é -bloqueado. +`/funcionarios`). Se `FUNCIONARIO_PAINEL` já existir de uma instalação +anterior sem a coluna `PERFIL`, rode o `ALTER TABLE FUNCIONARIO_PAINEL ADD +COLUMN PERFIL ...` (DDL completo em `app/db/funcionarios.py`) — **precisa +ser rodado manualmente em produção também**; sem essa coluna, todo login +falha com erro 500 (a query de autenticação seleciona `PERFIL`, que não +existe na tabela antiga). O `DEFAULT 'ADMIN'` desse `ALTER TABLE` é +intencional: todo funcionário cadastrado antes da migração vira admin +automaticamente. O sistema nunca deixa ficar sem nenhum admin ativo — +rebaixar ou desativar o último admin é bloqueado. Qualquer usuário logado troca a própria senha em **Minha conta** (`/minha-conta`), pedindo a senha atual antes de trocar. @@ -42,7 +46,7 @@ a tabela ficar vazia. Login checa primeiro o admin do `.env`, depois ``` pip install -r requirements-dev.txt ``` -2. Defina as variáveis de ambiente necessárias (`ADMIN_USER`, `ADMIN_PASSWORD`, `DB_HOST`, `DB_PORT`, `DB_NAME`, `DB_USER`, `DB_PASSWORD` — veja `.env.example`) diretamente no shell antes de subir a aplicação. **Importante:** apesar de `python-dotenv` estar nas dependências, nada no código chama `load_dotenv()` hoje — um arquivo `.env` sozinho NÃO é lido automaticamente fora do Docker. Exporte as variáveis manualmente (ex.: `set -a; source .env; set +a` no bash, ou `$env:...` no PowerShell) ou defina-as por outro meio. +2. Defina as variáveis de ambiente necessárias (`ADMIN_USER`, `ADMIN_PASSWORD`, `DB_HOST`, `DB_PORT`, `DB_NAME`, `DB_USER`, `DB_PASSWORD`, `SESSION_SECRET` — veja `.env.example`) diretamente no shell antes de subir a aplicação. `SESSION_SECRET` é opcional em dev — sem ela, uma chave aleatória é gerada em memória a cada start (sessões caem a cada restart); defina um valor fixo em produção. **Importante:** apesar de `python-dotenv` estar nas dependências, nada no código chama `load_dotenv()` hoje — um arquivo `.env` sozinho NÃO é lido automaticamente fora do Docker. Exporte as variáveis manualmente (ex.: `set -a; source .env; set +a` no bash, ou `$env:...` no PowerShell) ou defina-as por outro meio. 3. Rode a aplicação: ``` uvicorn app.main:app --reload