nicolasff / webdis

A Redis HTTP interface with JSON output
https://webd.is
BSD 2-Clause "Simplified" License
2.82k stars 307 forks source link

Access-Control-Allow-Origin not being sent in OPTIONS response #216

Closed ewired closed 2 years ago

ewired commented 2 years ago

Firefox sends a "pre-flight" OPTIONS request to check for CORS headers without sending authorization. I currently can't send authorization to a Webdis server from a userscript on a page because no-cors requests omit the Authorization header. CORS-enabled requests in fetch are failing because the OPTIONS response is not supplying any Access-Control-Allow-Origin header, so Firefox does not allow the subsequent GET request.

nicolasff commented 2 years ago

Hello @ewired,

the OPTIONS response is not supplying any Access-Control-Allow-Origin header

Webdis does send Access-Control-Allow-Origin in its response to an OPTIONS request. The code for it is here, and this is easy to verify with curl:

$ curl -v -X OPTIONS http://127.0.0.1:7379/
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 7379 (#0)
> OPTIONS / HTTP/1.1
> Host: 127.0.0.1:7379
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: Webdis
< Allow: GET,POST,PUT,OPTIONS
< Access-Control-Allow-Methods: GET,POST,PUT,OPTIONS
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Headers: X-Requested-With, Content-Type, Authorization
< Connection: Keep-Alive
< Content-Type: text/html
< Content-Length: 0
<
* Connection #0 to host 127.0.0.1 left intact
* Closing connection 0
ewired commented 2 years ago

OK, it looks like fly.io HTTP handler is messing with OPTIONS request. I found where Firefox can generate a cURL command replicating the request and found that it is working when I run the container locally, but not on the Fly deployment. Thanks for checking it out.