#643 CORS config does not seem to be working

Open
opened 3 months ago by royally · 5 comments
royally commented 3 months ago

Below is configured in config.yml:

cors:
  # Whether to enable or disable cors headers.
  # Note: If you want to put the frontend and the api on seperate domains or ports, you will need to enable this.
  #       Otherwise the frontend won't be able to make requests to the api through the browser.
  enable: true
  # A list of origins which may access the api.
  origins:
    - testhost.com
  # How long (in seconds) the results of a preflight request can be cached.
  maxage: 0

access-control-allow-origin header is empty when the origins are added, regardless of the number of origins entered.

Attached is a screenshot of the header, the /api/v1/info endpoint has been attempted to produce this screenshot.

Is the CORS config working properly?

Below is configured in `config.yml`: ```yaml cors: # Whether to enable or disable cors headers. # Note: If you want to put the frontend and the api on seperate domains or ports, you will need to enable this. # Otherwise the frontend won't be able to make requests to the api through the browser. enable: true # A list of origins which may access the api. origins: - testhost.com # How long (in seconds) the results of a preflight request can be cached. maxage: 0 ``` `access-control-allow-origin` header is empty when the origins are added, regardless of the number of origins entered. Attached is a screenshot of the header, the `/api/v1/info` endpoint has been attempted to produce this screenshot. Is the CORS config working properly?
konrad commented 3 months ago
Owner

It should definitely be working. It appears to work on try.

Does anything change if you change the maxage parameter to something other than 0?
Does it work if you comment out the origins bit? (Should return a default of *)

The openresty header in your screenshot is weird since I'm not using openresty. Is that a proxy you're using?

It should definitely be working. It appears to work on try. Does anything change if you change the `maxage` parameter to something other than 0? Does it work if you comment out the origins bit? (Should return a default of `*`) The openresty header in your screenshot is weird since I'm not using openresty. Is that a proxy you're using?
royally commented 3 months ago
Poster

I have changed the maxage to something more than 0:

cors:
  # Whether to enable or disable cors headers.
  # Note: If you want to put the frontend and the api on seperate domains or ports, you will need to enable this.
  #       Otherwise the frontend won't be able to make requests to the api through the browser.
  enable: true
  # A list of origins which may access the api.
  origins:
    - testhost.com
  # How long (in seconds) the results of a preflight request can be cached.
  maxage: 1000

Attached are the headers - request is now made against the API endpoint, no reverse proxies involved this time.

I'm using v0.14.1 of the backend, which seems to be the latest available currently.

Yes, the openresty header field was on my end -- I'm using openresty on my reverse proxy server.

I have changed the maxage to something more than 0: ``` cors: # Whether to enable or disable cors headers. # Note: If you want to put the frontend and the api on seperate domains or ports, you will need to enable this. # Otherwise the frontend won't be able to make requests to the api through the browser. enable: true # A list of origins which may access the api. origins: - testhost.com # How long (in seconds) the results of a preflight request can be cached. maxage: 1000 ``` Attached are the headers - request is now made against the API endpoint, no reverse proxies involved this time. I'm using v0.14.1 of the backend, which seems to be the latest available currently. Yes, the openresty header field was on my end -- I'm using openresty on my reverse proxy server.
konrad commented 3 months ago
Owner

Does it work with the * origin, as default? This is what I get for try which only has the default configured:

$ curl -I https://try.vikunja.io/api/v1/info -X GET
HTTP/2 200 
access-control-allow-origin: *
content-type: application/json; charset=UTF-8
date: Mon, 31 Aug 2020 07:50:51 GMT
vary: Origin
content-length: 413
Does it work with the `*` origin, as default? This is what I get for try which only has the default configured: ``` $ curl -I https://try.vikunja.io/api/v1/info -X GET HTTP/2 200 access-control-allow-origin: * content-type: application/json; charset=UTF-8 date: Mon, 31 Aug 2020 07:50:51 GMT vary: Origin content-length: 413
royally commented 3 months ago
Poster

Hi, yes it does work with * origin -- but for a non-default configuration, this seems to fail. I'm current mitigating this by adding the headers manually on my reverse proxy.

Hi, yes it does work with ```*``` origin -- but for a non-default configuration, this seems to fail. I'm current mitigating this by adding the headers manually on my reverse proxy.
konrad commented 3 months ago
Owner

Okay that definitely seems broken. I'll try to figure out why, but maybe it's a bug in the middleware I'm using for this.

Okay that definitely seems broken. I'll try to figure out why, but maybe it's a bug in the middleware I'm using for this.
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.