Add Origin to Vary header on credentialed CORS response#1111
Merged
JayH5 merged 4 commits intoKludex:masterfrom Apr 6, 2021
Merged
Add Origin to Vary header on credentialed CORS response#1111JayH5 merged 4 commits intoKludex:masterfrom
JayH5 merged 4 commits intoKludex:masterfrom
Conversation
added 2 commits
November 26, 2020 02:09
According to the [MDN CORS docs] (https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Access-Control-Allow-Origin), the `Origin` item should be added to the `Vary` header when the `Access-Control-Allow-Origin` is set to an explicit origin value, as opposed to the `*` wildcard. >If the server specifies a single origin (that may dynamically change based on the requesting origin as part of a white-list) rather than the "*" wildcard, then the server should also include Origin in the Vary response header — to indicate to clients that server responses will differ based on the value of the Origin request header. The existing code fails to update the `Vary` list when the server is configured to allow all origins (`*`) and the request has a `Cookie` header (ie. credentialed). In that situation, the `Access-Control-Allow-Origin` header will be set to the request's `Origin` value. It appears this may have just been a simple oversight in the original implementation. This updates the code to add `Origin` to the `Vary` header under these circumstancesIf it was intentionally omitted, I'd be delighted to learn why.
euri10
reviewed
Dec 16, 2020
|
|
||
|
|
||
| def test_cors_vary_header_is_properly_set(): | ||
| def test_cors_vary_header_is_properly_set_for_credentialed_request(): |
Contributor
There was a problem hiding this comment.
should we add another test_cors_vary_header_is_properly_set_for_not_credentialed_request ? and have the same setup as here without the Cookie sent ?
jcwilson
force-pushed
the
vary-origin-credentialed-cors
branch
3 times, most recently
from
5df76ea to
1673983
Compare
…quest is non-credentialed
This comment has been minimized.
This comment has been minimized.
Contributor
Author
euri10
approved these changes
Apr 6, 2021
Contributor
|
These PRs all look good, thank you. Let's get them merged. I'll need a bit more time to fully understand #1113, though. |
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.
According to the MDN CORS docs, the
Originitem should be added to theVaryheader list whenthe
Access-Control-Allow-Originis set to an explicit origin value when it could change due tosomething like
allow_originsbeing the*wildcard, a multi-item whitelist orallow_origin_regexbeing in use.
The existing code fails to update the
Varylist when the server is configured to allow allorigins (
*) and the request has aCookieheader (ie. credentialed). In that situation, theAccess-Control-Allow-Originheader will be set to the request'sOriginvalue. It shouldbe noted that the code does currently update the
Varylist when the allowed origins aredefined by an explicit whitelist (even if it only has one value and doesn't actually vary) or
a regex pattern.
It appears this may have just been a simple oversight in the original implementation. This updates
the code to add
Originto theVaryheader under these circumstances. If it was intentionallyomitted, I'd be delighted to learn why.