- Navios
- 23 de setembro de 2026 às 02:28 UTC
- Autor
- Kamo
- Enviar
- 4820f44
POST /convert-vector e WS /ws/pipeline não tomam nenhuma autorização (ver relatório companheiro deste commit para o porquê que não é corrigido aqui) e, até agora, ler todo o upload de um chamador na memória antes de olhar para seu tamanho em tudo — max image size mb foi definido em configurações e nunca referenciado em nenhum lugar. Nenhum dos dois. endpoint também executou remoção de fundo e vectorização (rembg, vtracer — ambos ligados à CPU, via asyncio.to thread) sem nenhum limite sobre quantos poderiam correr ao mesmo tempo. Juntos isso é uma porta aberta para executar este pod fora da memória ou CPU com um punhado de pedidos simultâneos, de qualquer pessoa que possa alcance-o – e por **************** que é qualquer navegador na internet: Traefik routes /vector-ws/* diretamente para este serviço, ignorando completamente o gateway do apiservice. - /convert-vector agora lê o upload em blocos limitados e se recusa (413) assim que a execução total cruzes max image size mb, em vez de depois de buffering a coisa toda. - O oleoduto WebSocket não tem equivalente a uma leitura em bloco — receive text() já detém a quadro completo decodificado pelo tempo em que é visto - então o mesmo limite é verificado imediatamente após base64-decodificação de uma imagem/máscara recebida, antes de ser entregue à remoção ou vetorização de bg. - Um novo conversion semaphore (max concurrent conversions, padrão 4, em configurações/configmap como max image size mb já foi) envolve cada chamada de remoção de bg e vetorização em ambos os terminais. As chamadas excessivas aguardam; não são recusadas. Testes: test resource limits.py (apenas pytest + httpx — os pesados deps ML/CV nos requisitos. txt são todos os corpos de função importados de forma preguiçosa dentro dos serviços/*.py, nunca na carga do módulo, então os dois pontos de entrada de conversão são ridicularizados em vez de instalados). Não executado pelo CI hoje; esta compilação não tem nenhum (build-and-deploy.yml vai direto do checkout ao docker build/push/deploy). Cada guarda era verificado em vermelho primeiro: a tampa de tamanho removida (um upload sobredimensionado atinge o conversor simulado de ser recusado) e a verificação de tamanho WebSocket desabilitado, em uma worktree local, restaurado depois.