CORS preflight requests to RPC API with custom headers

[achingbrain]

Version information:

go-ipfs 0.6.x

Description:

While implementing ipfs/js-ipfs#3275 I checked go-ipfs behaviour around preflight requests and I'm not sure it's implemented correctly.

Preflight requests are not issued for every fetch, one way to cause one to occur is to specify a non-default header value.

I've put a quick demo app together here: https://github.com/achingbrain/ipfs-cors-preflight-test

It tries to send an X-Stream-Output: * header along with every request which should be allowed as it's returned in the Access-Control-Allow-Headers list along with successful responses.

Running the test in the repo above against go-ipfs prints this error in the console:

127.0.0.1/:1 Access to fetch at 'http://127.0.0.1:5001/api/v0/id' from origin
'http://127.0.0.1:8080' has been blocked by CORS policy: Response to preflight
request doesn't pass access control check: No 'Access-Control-Allow-Origin'
header is present on the requested resource. If an opaque response serves your
needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

See the readme of the linked repo above for the correct headers that should be returned in order for the preflight request to succeed.

cc @lidel

[mar1n3r0]

This seems to be still an issue more than a year later. It works fine with http://localhost:5001/api/v0/pubsub/sub?arg=udGVzdA but not with http://localhost:5001/api/v0/pubsub/pub?arg=udGVzdA

It works through cURL though.

ipfs config --json API.HTTPHeaders.Access-Control-Allow-Origin  '["*"]'
ipfs config --json API.HTTPHeaders.Access-Control-Allow-Methods '["PUT", "POST", "GET"]'

Access to fetch at 'http://localhost:5001/api/v0/pubsub/pub?arg=udGVzdA' from origin 'http://localhost:3000' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

[lidel]

You should never expose your RPC API to the entire internet.
If you really need to, only safelist specific origins that are under your control.

That being said, CORS support in go-ipfs is the bare minimum to have it work on Gateways (I think we still use what was added in 2016 as a temporary fix), RPC API was never a priority because it is not intended for direct consumption in browser anyway.

I think this issue is a good opportunity to take a loot at CORS in general: make sure we have all behaviors covered with tests, and then fix bugs like the one described here.

On the issue at hand

Confirmed the behavior.

Can be reproduced with:

ipfs config --json API.HTTPHeaders.Access-Control-Allow-Origin  '["https://webui.ipfs.io"]'
ipfs config --json API.HTTPHeaders.Access-Control-Allow-Methods '["PUT", "POST"]'

Preflight without Access-Control-Request-Headers:

$ curl -v -X OPTIONS -H "access-control-request-method: POST" -H "origin: https://webui.ipfs.io" http://127.0.0.1:5001/api/v0/id
> OPTIONS /api/v0/id HTTP/1.1
> Host: 127.0.0.1:5001
> User-Agent: curl/7.79.1
> Accept: */*
> access-control-request-method: POST
> origin: https://webui.ipfs.io

< HTTP/1.1 200 OK
< Access-Control-Allow-Methods: POST
< Access-Control-Allow-Origin: https://webui.ipfs.io
< Vary: Origin
< Vary: Access-Control-Request-Method
< Vary: Access-Control-Request-Headers
< Date: Fri, 04 Feb 2022 14:01:45 GMT
< Content-Length: 0

Preflight with Access-Control-Request-Headers:

curl -v -X OPTIONS -H "access-control-request-method: POST" -H "access-control-request-headers: x-stream-output" -H "origin: https://webui.ipfs.io" http://127.0.0.1:5001/api/v0/id
> OPTIONS /api/v0/id HTTP/1.1
> Host: 127.0.0.1:5001
> User-Agent: curl/7.79.1
> Accept: */*
> access-control-request-method: POST
> access-control-request-headers: x-stream-output
> origin: https://webui.ipfs.io

< HTTP/1.1 200 OK
< Vary: Origin
< Vary: Access-Control-Request-Method
< Vary: Access-Control-Request-Headers
< Date: Fri, 04 Feb 2022 13:58:28 GMT
< Content-Length: 0

[mar1n3r0]

Should be resolved with next release of go-ipfs-cmds. AddAllowedHeaders functionality had just been merged:

ipfs/go-ipfs-cmds#222

[BigLep]

@lidel : is there any more work that needs to be done here now that ipfs/go-ipfs-cmds#222 has been merged?

[lidel]

At the very least, someone needs to add sharness tests to see what is the current behavior.

There is some prior art in comments at #8718 (review), but these tests are for /api/v0 exposed on Gateway port, we need tests for both Gateway (t0112-gateway-cors.sh) and API port (t0401-api-browser-security.sh), as the behavior may be different: these are separate HTTP servers with separate configs, which may clash.

Given our effort to:

• deprecate /api/v0 on Gateways,
• and the fact people should not expose RPC API port directly, but if they really need to, put it behind nginx with some auth,

..this is fairly low priority, should stay in "best effort" track
(but I'm happy to review PR if someone cares to look into this)