You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While adding Origin validation for CORS requests, we found out that our OPTIONS implementation does not actually handle pre-flight requests, at least not completely #2986 (comment).
The actual response is given by the wai-cors library. We can notice because our implementation does not return pre-flight headers, only Access-Control-Allow-Origin. In summary, our OPTIONS does nothing here, the library does the response.
Only when it fails, our OPTIONS implementation goes through and returns this info. This happens because we set the library to not respond with an error and let the request continue:
This still fails the pre-flight (in Firefox and Chrome at least) because Access-Control-Allow-Methods is not set (different from Allow which has no meaning in CORS pre-flight).
Solution
We have two options here:
Let the library return the error which is a 400 with a predefined message indicating the problem.
Implement our own, which would mean to verify if the OPTIONS CORS request is pre-flight (with the required headers) and respond with a custom error indicating the problem.
Any of these would liberate the simple OPTIONS CORS request (not preflight) to work as we want. For instance, it could bring back the schema definition mentioned in #790.
The text was updated successfully, but these errors were encountered:
laurenceisla
changed the title
OPTIONS does not actually handle CORS pre-flight requests completely
OPTIONS does not actually handle CORS pre-flight requests
Oct 27, 2023
The con is that it does not follow our "code, message, details, hint" structure for errors with application/json. An exception could be made since this is relevant mostly (only?) for browsers... or, if possible, we could intercept the library response and adapt it to our structure.
Found a problem with the library: it expects that any OPTIONS request that has an Origin header should be considered a pre-flight request and it complains when it doesn't have an Access-Control-Request-Method header (IMO, it shouldn't be that way: that's a valid CORS request not a pre-flight).
Solution is to add an Origin validation just for that case. I'll continue in PR #3052.
Problem
While adding Origin validation for CORS requests, we found out that our
OPTIONS
implementation does not actually handle pre-flight requests, at least not completely #2986 (comment).This is how it works right now:
Successful request
The actual response is given by the
wai-cors
library. We can notice because our implementation does not return pre-flight headers, onlyAccess-Control-Allow-Origin
. In summary, ourOPTIONS
does nothing here, the library does the response.Failing request
Only when it fails, our
OPTIONS
implementation goes through and returns this info. This happens because we set the library to not respond with an error and let the request continue:postgrest/src/PostgREST/Cors.hs
Line 37 in 5c9c7f4
This still fails the pre-flight (in Firefox and Chrome at least) because
Access-Control-Allow-Methods
is not set (different fromAllow
which has no meaning in CORS pre-flight).Solution
We have two options here:
400
with a predefined message indicating the problem.OPTIONS
CORS request is pre-flight (with the required headers) and respond with a custom error indicating the problem.Any of these would liberate the simple
OPTIONS
CORS request (not preflight) to work as we want. For instance, it could bring back the schema definition mentioned in #790.The text was updated successfully, but these errors were encountered: