carlos@cesaints: ~/projects/event-control.md — zsh

EN (Ler esta página em inglês)

Comando: cat projects/event-control.md

projects/event-control.md · 1,7 KB

Revisão e modernização de um sistema de controle de eventos em produção

Um sistema web em PHP opera eventos presenciais: inscritos, check-in com etiqueta, equipe de apoio, venda no estande com recibo e estoque por evento. Ele já existia e estava no ar. Conduzi uma revisão completa: auditorias por módulo, o retrato de todas as telas antes de mexer, correções de segurança e de concorrência e um design system novo, com tudo comparado ao retrato no fim.

abrir demonstraçãosimulação do sistema com dados fictícios · 4 telas

Papel
Responsável pela revisão e pela modernização
Período
set/2026 – set/2026
O que eu fiz

Eu: O método da revisão, as auditorias por módulo, o retrato das telas e a comparação final, as correções de integridade e de segurança, o design system e a publicação com backup e rollback.

Outras pessoas: O sistema já existia e estava em produção antes da revisão.

Projeto privado, descrito sem identificar cliente, produto ou empresa.

Diagrama

Retratar, auditar, corrigir e comparar, com o sistema no ar

O sistema PHP em produção atende administrador e atendente, e o trabalho correu sobre uma cópia anonimizada dele. Antes de qualquer mudança, as regras que não podiam mudar foram escritas e as telas foram retratadas. Auditorias por módulo levantaram os achados, cada um com a sua prova. As correções, dentro daquelas regras, trataram concorrência no banco, CSRF, sessão, login e cabeçalhos, e trouxeram um design system enxuto. No fim, tudo foi comparado com o retrato, cada diferença com um motivo, e a publicação usa backup, troca atômica da pasta e rollback.

Contexto

Uma entidade usa um sistema web para operar eventos presenciais, como feiras e congressos: cadastra ou importa os inscritos, faz o check-in na entrada e imprime a etiqueta, credencia a equipe de apoio, vende produtos no estande com recibo e controla o estoque de cada evento. Há dois perfis, administrador e atendente. O sistema já estava em produção; o meu trabalho foi revisá-lo por inteiro e modernizá-lo sem mudar o que não podia mudar.

O que eu fiz

  • Diagnóstico antes da correção. Quatro auditorias por módulo, um inventário de rotas com método e permissão, e uma lista das regras de negócio que não podiam mudar.
  • Um retrato para comparar. 68 telas capturadas antes da primeira mudança e comparadas no fim; cada diferença de número ganhou um motivo por escrito.
  • Integridade. Numeração de venda sem corrida, check-in idempotente, edição de estoque que não desfaz vendas feitas com a tela aberta e correções de agregação no painel e no relatório.
  • Segurança. Uma base revista nas categorias A01, A03, A05 e A07 do OWASP Top 10: CSRF, sessão, limite de login com tempo de resposta constante, cabeçalhos e exportações sem fórmula.
  • Interface. Um design system enxuto, menu por tarefa (operação, vendas e estoque, relatórios, administração) e um tema escuro pensado para o pavilhão, com alternativa clara.
  • Publicação. Documentada com backup, troca atômica da pasta e rollback preparado.

Limites

Os números vêm do relatório da revisão e não foram reexecutados de forma independente. Receita, contagens de participantes e nomes de eventos são do cliente e ficam fora; a demonstração usa eventos, pessoas e valores inventados.

Restrições

  • Sistema em produção, usado no balcão em dia de evento.
  • Uma lista escrita das regras de negócio que não podiam mudar, feita antes de qualquer correção.
  • Desenvolvimento sobre uma cópia anonimizada da produção.
  • A sessão precisa aguentar um turno de 8 horas no balcão.

Decisões

Retratar todas as telas antes de mexer

Contexto
Sem testes automatizados, uma correção podia mudar um número de relatório ou quebrar uma tela sem que ninguém percebesse.
Escolha
Capturar 53 telas como administrador e 15 como atendente antes da primeira mudança e comparar tudo no fim: código HTTP, avisos do PHP e cada número exibido.
Ganhos
  • Nenhuma diferença passou sem um motivo documentado.
Custos
  • O retrato cobre só o que foi capturado; o resto depende dos testes de fluxo e da leitura do código.

Auditorias por módulo, com a prova de cada achado

Contexto
Achado sem prova vira opinião, e opinião não define prioridade.
Escolha
Quatro auditorias independentes (vendas, estoque e produtos, pessoas e núcleo, interface), cada achado com a etiqueta da sua prova: confirmado por HTTP, por SQL ou só pela leitura do código.
Ganhos
  • A ordem das correções seguiu o que foi provado, e não o que pareceu grave.
Custos
  • Mais tempo de diagnóstico antes da primeira correção.

Concorrência resolvida no banco

Contexto
No balcão, vendas simultâneas disputavam o mesmo número, e editar o estoque com a tela aberta podia desfazer vendas feitas nesse meio tempo.
Escolha
Numeração de venda sem corrida, check-in idempotente e movimentação de estoque gravada de forma relativa, com trava.
Ganhos
  • Vendas simultâneas gravadas sem número repetido.
  • Um toque duplo no check-in não desfaz a presença.
Custos
  • Cada mudança em venda e estoque passou a exigir um teste de concorrência.

Um design system enxuto no lugar de CSS repetido

Contexto
Cada tela carregava a própria cópia de estilos, e as cores não tinham significado.
Escolha
Um design system único, com uma cor de ação, verde e amarelo só como significado, menu por tarefa, cada perfil vendo só o que pode usar e tabelas que viram cartões no celular.
Ganhos
  • Menos código para manter, e um tema escuro pensado para o pavilhão.
Custos
  • Toda tela precisou ser revista e comparada com o retrato.

Stack e por quê

PHP
Sistema existente, revisto e corrigido sem reescrever.
CSS próprio
Design system de cerca de 20 KB, com tema escuro e claro.
Testes de fluxo em PHP
O fluxo de vendas com 51 verificações.
Python
Comparação do retrato das telas antes e depois.

Resultados

  • Doze vendas simultâneas: antes, 11 falhavam; depois, as 12 gravadas, sem número repetido.

    declaradoRelatório da revisão

  • 68 telas comparadas antes e depois, sem nenhum código HTTP alterado e sem nenhum aviso do PHP.

    declaradoRelatório da revisão

  • Recibos em lote de 10,5 MB para 1,5 MB.

    declaradoRelatório da revisão

  • CSS de cerca de 216 KB repetidos para cerca de 20 KB, e HTML das telas 34% menor no total.

    declaradoRelatório da revisão

Ângulo de segurança

Superfície de ataque

  • Login de administradores e atendentes.
  • Venda no estande e baixa de estoque.
  • Importação de inscritos por planilha.
  • Exportação de planilhas CSV e XLS.

Controles implementados

  • Proteção CSRF em toda escrita.
  • Sessão endurecida para um turno de 8 horas.
  • Limite de tentativas de login, com o mesmo tempo de resposta para usuário que existe e que não existe.
  • Cabeçalhos de segurança.
  • Fórmulas neutralizadas nas exportações CSV e XLS.
  • Cada perfil vê e usa só o que pode, e o sistema impede ficar sem nenhum administrador.

O que eu testaria hoje

  • Um atendente chegando às telas de administrador por URL direta.
  • Corrida entre uma venda e uma transferência de estoque.
  • Planilha de importação com fórmula ou codificação inesperada.

Evidências

  • repositório privado auditadoRepositório local auditado(Auditoria do repositório privado, set/2026)