CORS preflight from app a to app b fails / redirects #22288
|
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. |
Replies: 4 comments 5 replies
|
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) |
|
I ran into this exact issue last year. The problem is that Coder's proxy intercepts OPTIONS requests before they hit your app, and if the request isn't authenticated (no cookies), it redirects to the login page instead of letting it through. This breaks CORS preflight. The fix is to configure Coder to exclude OPTIONS requests from authentication. In your template's proxy:
cors:
allow_credentials: true
allowed_origins:
- https://your-frontend-domain
allowed_methods:
- GET
- POST
- PUT
- DELETE
- OPTIONS
allowed_headers:
- Content-Type
- Authorization
- X-Requested-With
expose_headers:
- Content-Type
auth:
exclude_paths:
- /api/v1/endpoint1
- /api/v1/endpoint2
- /api/v1/endpoint3 |
|
is this config documented anywhere? I cant seem to find anything in documentation about allowed_origins in the yaml file |
|
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 
Original issue for this fix was #15096. |
|
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.. |
|
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! |
Yeah we also set ours to public for now but would prefer to go back to private. |
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.yamlfix existing (anymore?), but we added a template-wide "CORS Behavior" setting (cors_behaviorin the API) that you can set to "Passthrough" to let the app handle its own CORS.Original issue for this fix was #15096.