Redesign CORS middleware implementation#39
Merged
cupello merged 2 commits intoamericanas-tech:masterfrom Dec 3, 2020
Merged
Conversation
caiorcferreira
force-pushed
the
master
branch
from
00d5503 to
9aea220
Compare
|
Related: whatwg/fetch#1588 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR extends the CORS middleware to better cover the specification. The implementation presented here is highly inspired by the rs/cors package.
However, some modifications here made for restQL, most notably that the request handling implementation on rs/cors abort the execution when the origin, method, or request headers to be issued by the client are not allowed and we choose to not abort and return the appropriate headers if possible.
This decision is based on the CORS spec about how the
Access-Control-Allow-Methodsresponse header is handled, pointing that if it's not present, then the actual request method will be automatically authorized. Hence, aborting the CORS logic on the server because a method is not allowed cause it to be authorized. This is further reinforced by the lib authors here.We choose to return all possible header, not only the ones related to methods because as pointed in this issue on the CORS spec repository, the enforcement point in on the client and the restQL as a server participating in the CORS protocol defer any blocking to its client by providing the maximum information possible about the authorized operations.