Servico que roda dentro da rede da Comercial Scardua e faz a ponte entre a API publica da FLS (na VPS) e o Oracle privado (10.16.x), inalcancavel pela internet. Fluxo: Holmes -> API na VPS (trata e cifra) -> ESTE conector (abre e valida) -> Oracle. Recebimento: - app/v1/compras.py: POST /v1/compras/dados - app/services/cripto.py: abre o envelope AES-256-GCM + RSA-OAEP-SHA256 com a chave privada. O GCM autentica: corpo adulterado levanta InvalidTag em vez de devolver lixo - app/schemas.py: modulo folha (so pydantic) com a config e o contrato PayloadCompras, que espelha o da API. Fora de sincronia devolve 422 de proposito, pra falhar explicito em vez de gravar dado torto Seguranca: - app/seguranca.py: header X-Token com compare_digest (nao vaza por tempo de resposta) + allowlist de IP da VPS - .gitignore barra configs.json.*, *.bak-*, *.pem e *.key Config: - app/config.py e so o carregamento do configs.json - o bloco "vps" guarda chave privada, token e ips permitidos Estado: ainda NAO persiste. Recebe, valida e descarta (persistido: false). O INSERT no Oracle e a proxima fase, e tem que ser MERGE por id_processo porque o Holmes reentrega webhook. Docs em docs/ — arquitetura, a decisao do conector (opcao A, com as alternativas descartadas), deploy e problemas conhecidos. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2.6 KiB
2.6 KiB
Problemas conhecidos / TODO — Conector Scardua
Bloqueadores da fase 4 (gravar no Oracle)
- Não existe camada de conexão.
app/infra/database.pyé referenciado porapp/security.pymas nunca existiu. Nada abre pool no caminho que roda. - O conector não persiste nada. Hoje ele recebe, decifra, valida e descarta
(responde
persistido: false). O circuito está homologado; oINSERTnão. - Quando o
INSERTentrar, tem que serMERGEporid_processo— o Holmes reentrega webhook e sem isso cada reentrega duplica linha.
Resíduo do papel antigo
Este repo era a API que roda na VPS. Sobrou código que o conector não usa:
app/services/holmes.py— o conector não fala com o Holmesapp/v1/holmes/— pasta vazia; os.pyjá foram apagados, o git ainda registra as remoções como pendentesapp/services/controle_api.py— telemetria no Oracle; só volta a fazer sentido na fase 4app/security.py— JWT + auth via Oracle. Não é usado; a autenticação do conector é oapp/seguranca.py(token + IP). Continua com os defeitos antigos: importadb_instance(inexistente) e usasettings.api.jwt_secret(que não existe noSettingsnovo).
Nada disso é importado no boot, então não quebra — mas é peso morto a limpar.
Segurança
ips_permitidosestá vazio noconfigs.jsonatual (desligado, pra teste local). Preencher com179.197.230.154antes de produção.- O par de chaves é de homologação. Gerar um definitivo e trocar nos dois lados juntos.
- Sem TLS ainda — depende de como o conector for publicado. A VPS manda CNPJ, notas e vencimentos; o envelope protege o conteúdo, mas o token viaja no header.
- Sem rate limiting.
/docs,/redoce/openapi.jsonficam expostos quandoambiente != prod(atrás de basic auth). Fechar comambiente = prodse não precisar.- Se entrar proxy na frente, o IP de origem vira o do proxy — a allowlist para de
funcionar. Aí o uvicorn precisa de
--proxy-headerse oapp/seguranca.pypassa a lerX-Forwarded-For.
Middleware
block_scannersé denylist + heurística, não allowlist estrita: qualquer path fora da blocklist com User-Agent normal passa e vira 404 na app. Não vaza nada, mas é mais permissivo do que parece.
Empacotamento
pyproject.tomlapontareadme = "README.md"— o arquivo existe, mas confira sepip install .funciona; o Docker usarequirements.txtjustamente pra não depender disso.PyJWTestá nas dependências mas só era usado peloapp/security.py, que saiu de circulação.