Skip to content

Fix: set CORS_ORIGINS so the web frontend can log in - #24

Merged
zsmithnyc merged 1 commit into
mainfrom
fix-cors-origins
Oct 22, 2026
Merged

zsmithnyc merged 1 commit into
mainfrom
fix-cors-origins

Conversation

@zsmithnyc

Copy link
Copy Markdown
Collaborator

Summary

  • `Settings.cors_origins` defaults to `http://localhost:3000\` (the local dev value) and nothing in production ever overrode it.
  • Every cross-origin request from the actual deployed frontend (`https://demo.altsmanager.org\`, a different origin than `https://api.altsmanager.org\`) was being rejected by the browser at the CORS preflight stage.
  • This is why the admin panel (same-origin, server-rendered form) could log in fine while the frontend's login page (a cross-origin JS `fetch`) could not, using the same credentials.
  • Adds `--env=CORS_ORIGINS=...` covering both the custom domain and the generated `*.datumproxy.net` hostname for the web frontend.

Test plan

🤖 Generated with Claude Code

app.core.config.Settings.cors_origins defaults to http://localhost:3000
(the local dev value) and nothing in production ever overrode it, so
every cross-origin request from the actual deployed frontend --
https://demo.altsmanager.org, a different origin than
https://api.altsmanager.org -- was rejected by the browser at the CORS
preflight stage. This is why the admin panel (same-origin, server-
rendered form) could log in fine while the frontend's login page (a
cross-origin JS fetch) could not, with the same credentials.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@zsmithnyc
zsmithnyc merged commit fe91992 into main Oct 22, 2026
3 checks passed
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.

1 participant