feat(devops): configure custom domain for optional deployment

[c4rlosfb]

O que muda?

Configuração de domínio próprio com HTTPS para acesso público ao Simples Editor:

• Domínio: simples.163.176.220.47.nip.io (nip.io gratuito — resolve automaticamente)
• HTTPS: Let's Encrypt via certbot (standalone)
• Nginx: HTTP→HTTPS redirect + SSL proxy para frontend/backend
• OCI Security List: regras TCP/80 e TCP/443 configuradas

URLs de acesso

URL	Descrição
https://simples.163.176.220.47.nip.io	IDE completa
https://simples.163.176.220.47.nip.io/api/health	Health check

Por quê?

Closes #49

Como testar?

# HTTP → HTTPS redirect
curl -I http://simples.163.176.220.47.nip.io/
# → 301 Moved Permanently → https://...

# HTTPS health
curl https://simples.163.176.220.47.nip.io/api/health
# → {"status":"healthy","version":"1.0.0"}

# Certificado válido
echo | openssl s_client -connect simples.163.176.220.47.nip.io:443 2>/dev/null | openssl x509 -noout -dates
# → notAfter=Sep 16 00:20:22 2026 GMT

Checklist

• Domínio apontando para o IP da OCI
• Domínio resolvendo via HTTPS
• Certificado Let's Encrypt válido
• Renovação automática configurada

[KauaN-png]

🔍 Revisão — PR #102

PR: feat(devops): configure custom domain for optional deployment
Autor: @c4rlosfb
Branch: feat/issue-49 → dev
Arquivos alterados: 3 (DOMAIN.md, App.tsx, nginx/default.conf)
Closes: #49

---

✅ Acertos

Item	Detalhe
DOMAIN.md transformado de template em documentação real	Saiu de um guia genérico ('substitua pelo seu domínio') para documentação concreta do que foi configurado: domínio, IP, certificado, renovação. Muito mais útil.
nip.io como DNS gratuito	Escolha inteligente — zero configuração de DNS, resolução automática. Perfeito para deploy opcional/educacional.
Nginx: HTTP → HTTPS redirect (301)	Correto e bem implementado. Let's Encrypt challenge location também configurado para renovação automática.
SSL ciphers e protocolos	TLSv1.2 TLSv1.3 + HIGH:!aNULL:!MD5 — config seguro e moderno.
X-Forwarded-Proto adicionado	Essencial para o backend saber se a requisição original era HTTPS.
Auth gate + logout no App.tsx	Necessário para deploy público — sem auth, qualquer um usaria a IDE. Demo mode continua bypassando via VITE_DEMO_MODE=true.
Testes	✅ 45 passed, 3 skipped — sem regressões.

---

🚨 Erros

Nenhum erro crítico identificado.

---

⚠️ Warnings

1. 🟠 getSession() sem tratamento de erro (App.tsx:152)

supabase.auth.getSession().then(({ data }) => {
  setIsAuthenticated(!!data.session);
  setAuthChecked(true);
});

Se supabase.auth.getSession() lançar exceção (rede indisponível, Supabase fora do ar), a Promise rejeita silenciosamente. authChecked nunca vira true e o usuário fica preso no spinner infinito Carregando....

Sugestão: Adicionar .catch():

supabase.auth.getSession()
  .then(({ data }) => {
    setIsAuthenticated(!!data.session);
    setAuthChecked(true);
  })
  .catch(() => {
    setIsAuthenticated(false);
    setAuthChecked(true);
  });

2. 🟠 Dupla verificação de auth (App.tsx + routes/index.tsx)

O beforeLoad em routes/index.tsx já verifica autenticação com Supabase. Agora o App.tsx também verifica. Isso resulta em 2 chamadas à API do Supabase no mesmo carregamento de página. Não quebra nada, mas é redundante — uma das verificações poderia ser removida ou unificada.

---

💡 Sugestões

3. Strict-Transport-Security (HSTS) no nginx

Após o redirect HTTP→HTTPS, o navegador ainda pode fazer a primeira requisição via HTTP (vulnerável a SSL stripping). Adicionar no server block HTTPS:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

4. server_name real no nginx

Ambos os server blocks usam server_name localhost. Para clareza, o block HTTPS deveria usar o domínio real:

server_name simples.163.176.220.47.nip.io;

(Não quebra funcionalmente — nginx roteia por porta — mas é documentação viva.)

---

📊 Resultado dos testes

45 passed, 3 skipped in 1.47s

🏷️ Veredito

✅ APPROVED — PR limpo, bem documentado, sem bugs críticos. As sugestões são não-bloqueantes. Pronto para merge pelo owner.