Skip to content

fix: fall back to OSC_HOSTNAME when CORS_ORIGIN is not set - #385

Merged
birme merged 1 commit into
mainfrom
bug-fixer/fix-383-cors-osc-hostname-fallback
Sep 30, 2026
Merged

birme merged 1 commit into
mainfrom
bug-fixer/fix-383-cors-osc-hostname-fallback

Conversation

@birme

@birme birme commented Sep 30, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Instances on Eyevinn Open Source Cloud could not boot after fix(security): validate required env vars (SMB_ADDRESS, CORS_ORIGIN) at startup #346 made CORS_ORIGIN a hard-required env var (OSC has no way to set arbitrary per-instance env vars).
  • Added a shared resolver (src/config/cors-origin.ts) that resolves the allowed CORS origin from CORS_ORIGIN first, then falls back to the OSC-injected OSC_HOSTNAME (bare hostname → prefixed https://; full URL → trailing slash stripped; empty/whitespace treated as unset).
  • src/api.ts CORS registration and validateRequiredEnv() in src/server.ts both use the shared resolver, so they stay in agreement. Startup still fails fast (exit 1) only when neither is set. Explicit CORS_ORIGIN still wins over OSC_HOSTNAME. The WHIP/WHEP permissive CORS branch is unchanged.
  • Documented the fallback in the readme.md CORS_ORIGIN row.

Test plan

  • Tests pass (npm test — 392 passed / 20 suites)
  • TypeScript compiles (npm run typecheck)
  • Lint clean (npm run lint — only pre-existing warnings)
  • Server starts with CORS_ORIGIN unset and OSC_HOSTNAME set
  • Explicit CORS_ORIGIN wins over OSC_HOSTNAME
  • Empty CORS_ORIGIN treated as unset
  • Still exits 1 when neither is set
  • Resolver: bare hostname gets https://; full URL trailing slash stripped

Closes #383

🤖 Generated with Claude Code

Co-Authored-By: Claude Sonnet 4.6 noreply@anthropic.com

PR #346 made CORS_ORIGIN a required env var, so instances on Eyevinn
Open Source Cloud (where arbitrary per-instance env vars can't be set)
failed to boot. Resolve the allowed origin from CORS_ORIGIN first, then
fall back to the OSC-injected OSC_HOSTNAME, and only fail fast when
neither is set.

Closes #383
@birme

birme commented Sep 30, 2026

Copy link
Copy Markdown
Contributor Author

Independent code-reviewer verdict: LGTM. Correctly and safely meets every acceptance criterion (server boots with CORS_ORIGIN unset + OSC_HOSTNAME set; explicit CORS_ORIGIN wins; empty treated as unset; still exits 1 when neither set), with strong unit-test coverage (22 tests) and no CORS security regression. Non-blocking follow-ups noted: duplication with the existing docker-entrypoint.sh fallback (defense-in-depth, fine) and trimming comma-split CORS_ORIGIN entries (pre-existing latent edge case).

Self-authored PR (author == automation account birme), so GitHub blocks a state-bearing self-approval; recording the verdict as this marker and merging via --admin per the daily-backlog-pr skill. CI: lint/pretty/ts/unittests all green.

@birme
birme merged commit 2b6eccb into main Sep 30, 2026
4 checks passed
@birme
birme deleted the bug-fixer/fix-383-cors-osc-hostname-fallback branch September 30, 2026 09:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Fall back to OSC_HOSTNAME when CORS_ORIGIN is not set

1 participant