CORS config does not seem to be working #643

New Issue

royally · 2020-08-24T21:16:51Z

royally commented

2020-08-24 21:16:51 +00:00

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?

by default 2020-08-25 at 5.14.03 AM.png

42 KiB

konrad commented

2020-08-25 06:34:16 +00:00

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

2020-08-25 11:52:29 +00:00

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.

by default 2020-08-25 at 7.49.48 PM.png

47 KiB

konrad commented

2020-08-31 07:52:23 +00:00

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

2020-08-31 09:23:38 +00:00

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

2020-09-01 20:59:54 +00:00

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.

konrad commented

2020-12-16 12:22:24 +00:00

I did some digging and think it is working as intended. You need to provide the full url, including protocol and port. If you then visit the api from the same origin, you get a "good" access-control-allow-origin header back, if not you'll get an empty one. You can see this with curl:

This configuration

cors:
  enable: true
  origins:
    - testhost.com

gets me this: (emtpy Access-Control-Allow-Origin header)

$ curl localhost:3456/api/v1/info -I -X GET -H 'Origin: http://testhost.com' 
HTTP/1.1 200 OK
Access-Control-Allow-Origin: 
Content-Type: application/json; charset=UTF-8
Vary: Origin
Date: Wed, 16 Dec 2020 12:18:49 GMT
Content-Length: 561

Whereas this

cors:
  enable: true
  origins:
    - http://testhost.com

gives me a correct header back:

$ curl localhost:3456/api/v1/info -I -X GET -H 'Origin: http://testhost.com'
HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://testhost.com
Content-Type: application/json; charset=UTF-8
Vary: Origin
Date: Wed, 16 Dec 2020 12:20:28 GMT
Content-Length: 561

I've updated the docs to clarify this.

Closing as resolved, feel free to reopen if you have any issues.

I did some digging and think it is working as intended. You need to provide the full url, including protocol and port. If you then visit the api from the same origin, you get a "good" `access-control-allow-origin` header back, if not you'll get an empty one. You can see this with curl: This configuration ```yaml cors: enable: true origins: - testhost.com ``` gets me this: (emtpy `Access-Control-Allow-Origin` header) ``` $ curl localhost:3456/api/v1/info -I -X GET -H 'Origin: http://testhost.com' HTTP/1.1 200 OK Access-Control-Allow-Origin: Content-Type: application/json; charset=UTF-8 Vary: Origin Date: Wed, 16 Dec 2020 12:18:49 GMT Content-Length: 561 ``` Whereas this ```yaml cors: enable: true origins: - http://testhost.com ``` gives me a correct header back: ``` $ curl localhost:3456/api/v1/info -I -X GET -H 'Origin: http://testhost.com' HTTP/1.1 200 OK Access-Control-Allow-Origin: http://testhost.com Content-Type: application/json; charset=UTF-8 Vary: Origin Date: Wed, 16 Dec 2020 12:20:28 GMT Content-Length: 561 ``` I've updated the docs to clarify this. Closing as resolved, feel free to reopen if you have any issues.

konrad closed this issue

2020-12-16 12:22:24 +00:00

konrad referenced this issue from a commit

2024-02-07 14:00:26 +00:00

Update dependency esbuild to v0.12.19 (#643)

Sign in to join this conversation.