Feature/vps secure integration#66
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this comment.
Pull request overview
This PR introduces a more “production-ready” frontend↔backend integration for a VPS deployment, including configurable base URLs and tighter backend HTTP security/CORS behavior.
Changes:
- Frontend now builds API URLs using an optional
VITE_API_BASE_URL(plus a host-based fallback) and updates tests accordingly. - Backend adds an allowlist-based CORS policy, security headers, and a dedicated 403 response for disallowed origins.
- Updates example env files and Vite proxy target resolution to support the new deployment configuration.
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
| frontend/vite.config.js | Allows proxy target to fall back to VITE_API_BASE_URL when explicit proxy target isn’t set. |
| frontend/tests/unit/utils/jobsService.test.ts | Adds env cleanup and a new test to assert absolute URL usage when base URL is configured. |
| frontend/src/services/jobsService.ts | Introduces base URL normalization + API URL builder used by all service calls. |
| frontend/.env.example | Documents VITE_API_BASE_URL and optional proxy override. |
| backend/tests/integration/jobsApi.test.js | Adds integration coverage for allowed vs blocked CORS origins. |
| backend/src/server.js | Enables trust proxy on the Express app. |
| backend/src/jobsApiApp.js | Implements CORS allowlist + security headers + CORS error mapping to a 403 JSON response. |
| backend/.env.example | Documents PORT and CORS_ALLOWED_ORIGINS. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| next(); | ||
| }); | ||
| app.use(cors(corsOptions)); | ||
| app.use(express.json()); |
There was a problem hiding this comment.
express.json() está sendo registrado duas vezes: primeiro com limit: "16kb" e depois novamente sem opções. Isso é redundante e pode causar comportamento/confusão (p.ex., limites diferentes) e overhead. Sugestão: manter apenas uma chamada (provavelmente a com limite) e remover a segunda.
| app.use(express.json()); |
| const app = createJobsApiApp({ outputDir }); | ||
| app.set("trust proxy", 1); |
There was a problem hiding this comment.
app.set("trust proxy", 1) está habilitado incondicionalmente. Isso faz o Express confiar em headers X-Forwarded-* mesmo quando o app estiver exposto diretamente, o que pode permitir spoofing de IP/protocolo e afetar lógica baseada em req.secure/req.ip. Sugestão: controlar via env/config (ex.: TRUST_PROXY=1) ou habilitar apenas no ambiente/proxy esperado.
| if (configuredBaseUrl) { | ||
| return configuredBaseUrl; | ||
| } | ||
|
|
||
| if (typeof window !== "undefined" && window.location.hostname === "painel-vagas-lake.vercel.app") { | ||
| return "https://jobsglobalscraper.ddns.net"; | ||
| } | ||
|
|
||
| return ""; |
There was a problem hiding this comment.
getApiBaseUrl() embute regras/infra específicas (hostname painel-vagas-lake.vercel.app e URL https://jobsglobalscraper.ddns.net) diretamente no código. Isso reduz portabilidade (preview deploys, novos domínios) e acopla o build a um endpoint. Sugestão: depender apenas de configuração (ex.: VITE_API_BASE_URL) e documentar no .env.example, evitando fallback hard-coded.
| if (configuredBaseUrl) { | |
| return configuredBaseUrl; | |
| } | |
| if (typeof window !== "undefined" && window.location.hostname === "painel-vagas-lake.vercel.app") { | |
| return "https://jobsglobalscraper.ddns.net"; | |
| } | |
| return ""; | |
| return configuredBaseUrl || ""; |
| afterEach(() => { | ||
| vi.restoreAllMocks(); | ||
| vi.unstubAllEnvs(); | ||
| }); |
There was a problem hiding this comment.
Os testes abaixo assumem que a base URL é relativa (ex.: esperam chamadas para /api/...). Como o service agora usa import.meta.env.VITE_API_BASE_URL quando definido, um VITE_API_BASE_URL presente no ambiente de execução pode quebrar os asserts. Sugestão: em beforeEach (ou no próprio afterEach) forçar VITE_API_BASE_URL a vazio via vi.stubEnv (ou limpar explicitamente) para tornar os testes determinísticos.
| it("permite CORS para o frontend oficial", async () => { | ||
| tmpDir = mkdtempSync(join(tmpdir(), "jobs-api-")); | ||
| const app = createJobsApiApp({ outputDir: tmpDir }); | ||
| const res = await request(app) |
There was a problem hiding this comment.
Esses testes dependem implicitamente do valor de process.env.CORS_ALLOWED_ORIGINS (via createJobsApiApp). Se a variável estiver definida no ambiente de execução (CI/dev), o allowlist pode mudar e tornar o teste não determinístico (p.ex., falhar o caso de 403/200). Sugestão: stub/limpar CORS_ALLOWED_ORIGINS no beforeEach (ex.: vi.stubEnv(...) ou delete process.env...) para garantir que o teste valida o comportamento padrão.
No description provided.