fix: handle CORS pre-flight requests correctly #3052
Conversation
laurenceisla
force-pushed
the
options-preflight
branch
from
c128dfc
to
d781204
Compare
src/PostgREST/Cors.hs
Outdated
| @@ -44,3 +44,7 @@ corsPolicy corsAllowedOrigins req = case lookup "origin" headers of | |||
| -- Impossible case, Middleware.Cors will not evaluate this when | |||
| -- the Access-Control-Request-Headers header is not set. | |||
| Nothing -> [] | |||
| -- The library makes "OPTIONS" requests fail when the "Origin" header is present | |||
There was a problem hiding this comment.
Ah, I failed to mention the wai-cors library. In summary, it treats an OPTION request with Origin as a pre-flight when it shouldn't IMO. Relevant code.
I added more info here: #3027 (comment). The solution is as I mentioned there or patch the library to remove that validation.
There was a problem hiding this comment.
Just confirmed that there's no way to bypass the OPTIONS requests without re-implementing the CORS functionality for that method only. So, I opened an issue upstream larskuhtz/wai-cors#37 to see what they think about it.
laurenceisla
force-pushed
the
options-preflight
branch
from
d781204
to
574ba9b
Compare
| source-repository-package | ||
| type: git | ||
| location: https://github.com/laurenceisla/wai-cors.git | ||
| tag: e2da0d7a3e56592a5f4b35fd3aa6ccd3175525cc |
There was a problem hiding this comment.
Using a temporary fork, ideally this would be merged upstream and it should fix allowing using OPTIONS with the Origin header without returning errors.
Closes #3027
Lets the library handle errors when a pre-flight request fails.