Preflighted CORS on API is broken

[Kubuxu]

API does not return required headers for CORS request,
I think it is regression as I remember working on this issue in the past.

Unfortunately we don't have tests for it right now.

Example OPTION request on the API:

  curl -H "Origin: http://example.com" \
  -H "Access-Control-Request-Method: POST" \
  -H "Access-Control-Request-Headers: X-Requested-With" \
  -X OPTIONS --verbose \
  localhost:5001/api/v0/version
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 5001 (#0)
> OPTIONS /api/v0/version HTTP/1.1
> Host: localhost:5001
> User-Agent: curl/7.50.3
> Accept: */*
> Origin: http://example.com
> Access-Control-Request-Method: POST
> Access-Control-Request-Headers: X-Requested-With
> 
< HTTP/1.1 200 OK
< Vary: Origin
< Vary: Access-Control-Request-Method
< Vary: Access-Control-Request-Headers
< Date: Fri, 04 Nov 2016 10:50:58 GMT
< Content-Length: 0
< Content-Type: text/plain; charset=utf-8
< 
* Curl_http_done: called premature == 0
* Connection #0 to host localhost left intact

You can see that the response does not contain CORS headers, it should include: Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Header (Vary doesn't count).

My config says:

 "API": {
    "HTTPHeaders": {
      "Access-Control-Allow-Headers": [
        "X-Requested-With"
      ],
      "Access-Control-Allow-Methods": [
        "PUT",
        "GET",
        "POST"
      ],
      "Access-Control-Allow-Origin": [
        "*"
      ]
    }
  },

[dignifiedquire]

I got them to work in chrome with the following config

'HTTPHeaders.Access-Control-Allow-Origin': ['*'],
'HTTPHeaders.Access-Control-Allow-Credentials': 'true',
'HTTPHeaders.Access-Control-Allow-Methods': ['PUT', 'POST', 'GET']

[Kubuxu]

Ok, I will test few things out later, and write tests for it.

[whyrusleeping]

@Kubuxu @dignifiedquire is this still an issue?

[michel47]

API CORS seems to be still broken ... as it doesn't return a Access-Control-Request-Headers on the OPTIONS pre-flight

see example : https://gateway.ipfs.io/ipfs/QmZ3wTVb7WeZZAk8g7pczprZcjqswBxhr7GrCNdPna8jac/posting.html

[hacdias]

This issue seems to have been solved. Using the config from the first comment, we get:

$ curl -H "Origin: http://example.com" \
  -H "Access-Control-Request-Method: POST" \
  -H "Access-Control-Request-Headers: X-Requested-With" \
  -X OPTIONS --verbose \
  localhost:5001/api/v0/version
*   Trying 127.0.0.1:5001...
* Connected to localhost (127.0.0.1) port 5001 (#0)
> OPTIONS /api/v0/version HTTP/1.1
> Host: localhost:5001
> User-Agent: curl/7.88.1
> Accept: */*
> Origin: http://example.com
> Access-Control-Request-Method: POST
> Access-Control-Request-Headers: X-Requested-With
>
< HTTP/1.1 200 OK
< Access-Control-Allow-Headers: X-Requested-With
< Access-Control-Allow-Methods: POST
< Access-Control-Allow-Origin: *
< Vary: Origin
< Vary: Access-Control-Request-Method
< Vary: Access-Control-Request-Headers
< Date: Mon, 21 Aug 2023 07:49:27 GMT
< Content-Length: 0
<
* Connection #0 to host localhost left intact

You can also find sharness tests in https://github.com/ipfs/kubo/blob/master/test/sharness/t0401-api-browser-security.sh.