Replies: 2 comments 1 reply
|
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 |
Uh oh!
There was an error while loading. Please reload this page.
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.
All reactions