DNS, IP, firewall, proxy reverso e certificado para o endereço obrigatório apps.siebot.cloud/aplicacao_separada_por_underline — incluindo o ajuste do tenant.
Módulo 04 de 07 · apps.siebot.cloudCitizen Apps / Pesquisa de infraestrutura
Siebot Infrastructure Lab
Um domínio. Múltiplas aplicações.
Entenda o caminho de uma requisição até apps.siebot.cloud/controle_visitas, passando por DNS, TLS, proxy e Docker.
apps.siebot.cloudTLS / 443Proxy reverso
Task 03 • Rede e acesso externo
apps.siebot.cloud/controle_visitas
Para cumprir o padrão requisitado, todos os acessos públicos passam por um mesmo subdomínio e o roteamento distingue as aplicações pelo prefixo de caminho com underscore.
DNSapps.siebot.cloud → IP público
→
Proxy HTTPSTLS + Host + rota do path
→
Docker privadocontrole_visitas:8080
→
Siebot API HubHTTPS + token autorizado
Exemplo de roteamento Nginx
server {
listen 443 ssl;
server_name apps.siebot.cloud;
# Certificado e chaves configurados
# TLS e renovação fora deste exemplo
location = /controle_visitas {
return 308 /controle_visitas/;
}
location /controle_visitas/ {
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Prefix /controle_visitas;
proxy_pass http://controle_visitas:8080/;
}
}
Exemplo parcial para compreensão. O / final em proxy_pass remove o prefixo antes do encaminhamento. Os nomes Docker só resolvem se o proxy estiver conectado à rede adequada. Exigem-se certificados, listener HTTP para desafio/redirect, timeouts, WebSocket e configuração de trusted proxies.
Checklist DNS, certificado e URL
Definir origem: IP público estável (Hostinger/EC2) ou IP estático vinculado (Lightsail).
DNS: publicar registro A de apps.siebot.cloud apontando ao servidor; aguardar propagação.
Firewall: abrir somente TCP 80/443 para público. Restringir SSH a IPs de administração/VPN.
TLS: emitir certificado válido para apps.siebot.cloud e testar renovação automática; desafio HTTP-01 utiliza porta 80.
Base path: validar CSS/JS, cookies, redirects, sessões, upload, WebSocket e geração de URLs sob o prefixo.
Segurança: recusar Host inesperado, ativar HTTPS redirect, limites de requisições e cabeçalhos apropriados.
Bloqueio arquitetural encontrado no ZIP
O tenant não pode ser extraído cegamente do subdomínio
O arquivo src/util/bootstrap.php deriva CITIZEN_APPS_TENANT da primeira parte de HTTP_HOST. Assim, o host siebert.siebot.cloud sugere tenant siebert, enquanto apps.siebot.cloud passaria a sugerir apps. Isso pode alterar consultas filtradas por tenant.
Correção necessária: utilizar tenant validado da sessão autenticada ou um mapeamento explícito confiável; não confiar no Host enviado pelo cliente para decidir acesso a dados corporativos.
Melhor separação de origem web, mas precisa slug DNS com hífen, DNS/certificados adicionais e mudança do padrão solicitado.
Conclusão da task 03: a arquitetura de domínio + HTTPS é tecnicamente viável em Hostinger VPS, Lightsail ou EC2; não foi validada no servidor real. O ajuste de tenant e o teste de compatibilidade do caminho em cada app são condições anteriores à entrada em produção.
Conferência de publicação
Hostname públicoapps.siebot.cloudRegistro DNS A para o IP da VPS
Prefixo da aplicação/controle_visitas/Path com underscore e barra final canônica
TLS / certificadoHTTPS :443ACME e renovação automática
O código original deriva o tenant de HTTP_HOST. A mudança para apps.siebot.cloud requer corrigir essa resolução antes da produção.
