Open richarddmorey opened 1 year ago
On further exploration, this is what I think is happening:
authorization
header in it (because it is a pre-flight request) it sets the status to 401 (when the token is parsed).In order to (temporarily?) work around this, I wrote a middleware to send 200 for specific OPTIONS requests:
handle_preflight_401_mw = Middleware$new(
process_response = function(request, response){
if(
request$method == 'OPTIONS' &&
'authorization' %in% request$headers[['access-control-request-headers']] &&
request$headers[['access-control-request-method']] == 'GET'
)
response$set_status_code(200)
},
id = "handle_preflight_401"
) # Put between CORS and auth middlewares
I think the thing with Firefox was a red herring: a CORS cache issue. At any rate, with the above middleware it seems to work in Chrome. If this is a bad idea, or there is some other solution, I'd love to know.
Thanks for reporting, looks like we need to update authorization middleware to not check authorization header for OPTIONS requests - https://stackoverflow.com/a/52072116/1069256
Describe the issue
Response headers to pre-flight requests from some browsers when using javascript
fetch()
when Bearer authentication is used do not include CORS headers, causing some browsers (Chrome, Safari, Edge) to reject the response. Firefox does not seem to do a pre-flight check so it is not affected.To Reproduce
The example below is adapted from the examples in the docs.
After starting the script, this works in a terminal:
Chrome, Safari, Edge
Under
this does not work. The
fetch
to the secure page fails, and I seeIn the developers' console in Chrome, I see
Under "Headers" for the pre-flight, I see:
So indeed, the headers don't seem to include
Access-Control-Allow-Origin: *
as I would expect, and as the request to/hello2
does.Looking at the RestRserve logs confirms this:
Expected behavior
Under Firefox 112.0.2 (64-bit) this works as expected.
When I load
http://localhost:8081
in a browser, I expect to seeThe two fetch calls to the server at
localhost:8080
should replaceHELLO1
andHELLO2
with the secure content and the insecure content, respectively.When I look at the RestRserve logs, it seems like Firefox does not make a pre-flight check; instead, it just sends over the request in a GET request with the token, and RestRserve obliges with a proper response with CORS headers:
Environment information