GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — CORS preflight from app a to app b fails / redirects · coder/coder · Discussion #22288

CORS preflight from app a to app b fails / redirects #22288

Answered by phorcys420
herndlm asked this question in General
CORS preflight from app a to app b fails / redirects #22288
@herndlm herndlm
Feb 24, 2026 · 4 comments · 5 replies
Answered by phorcys420 Return to top
Discussion options
  • Uh oh!

    There was an error while loading. Please reload this page.

herndlm
Feb 24, 2026

Hi,

In our company setup we have passtrough already set in the template and our BE app (b) is handling cors properly because it works when the shared port is public. But in any other case I see that the preflight request from our FE app (a) is failing because coder seems to be intercepting it to redirect to a login page. Presumably because no cookies are sent with it, which is expected.

I can't find anything about this, is this a known limitation or are we still doing something wrong? Any help is appreciated.

You must be logged in to vote
All reactions
Answered by phorcys420 Aug 28, 2026

hey @herndlm @jdetmold, apologies for the delay! we have been long inactive on GitHub Discussions and we are aiming to fix this :)

I am not aware of a coder.yaml fix existing (anymore?), but we added a template-wide "CORS Behavior" setting (cors_behavior in the API) that you can set to "Passthrough" to let the app handle its own CORS.

Original issue for this fix was #15096.

View full answer

Replies: 4 comments · 5 replies

Comment options
  • Uh oh!

    There was an error while loading. Please reload this page.

herndlm
Feb 25, 2026
Author

was told via premium support that this is by design. honestly, I still find it somewhat weird, because app a <-> app b CORS support is then not fully there (in contrary to some diagrams in documentation) when ports are not public. but there are workarounds we'll use I guess (localhost port forwarding or making ports public and protecting our internal network in other ways)

You must be logged in to vote
All reactions
0 replies
Comment options
  • Uh oh!

    There was an error while loading. Please reload this page.

phorcys420
Aug 28, 2026
Collaborator

hey @herndlm @jdetmold, apologies for the delay! we have been long inactive on GitHub Discussions and we are aiming to fix this :)

I am not aware of a coder.yaml fix existing (anymore?), but we added a template-wide "CORS Behavior" setting (cors_behavior in the API) that you can set to "Passthrough" to let the app handle its own CORS.

image

Original issue for this fix was #15096.

You must be logged in to vote
All reactions
3 replies
@herndlm
Comment options
  • Uh oh!

    There was an error while loading. Please reload this page.

  • Uh oh!

    There was an error while loading. Please reload this page.

herndlm Aug 28, 2026
Author

hi, this existed already since last year which was way before I asked I think. OPTION requests are still not passed through IIRC, as described in the second comment and was also explained by support like that to me. tbh we kind of gave up on this already and are setting things to public..

All reactions
@phorcys420
Comment options
  • Uh oh!

    There was an error while loading. Please reload this page.

phorcys420 Aug 28, 2026
Collaborator

hey @herndlm, i was convinced it didn't intercept OPTIONS 😓, given this is not well documented i thought it'd be more of a visibility issue. I will try to reproduce on my end!

All reactions
@jdetmold
Comment options
  • Uh oh!

    There was an error while loading. Please reload this page.

jdetmold Aug 28, 2026

hi, this existed already since last year which was way before I asked I think. OPTION requests are still not passed through IIRC, as described in the second comment and was also explained by support like that to me. tbh we kind of gave up on this already and are setting things to public..

Yeah we also set ours to public for now but would prefer to go back to private.

All reactions
Answer selected by phorcys420
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Category
👨‍💻
General
Labels
None yet
3 participants
@herndlm @jdetmold @phorcys420
You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.