Disambiguate RequestInit object's credentials property where related to the Set-Cookie header
#34798
Conversation
This file contains 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
The first paragraph states that the `credentials` property "determines whether or not the browser sends credentials with the request". This fails to address an obscure and major characteristic of the property, which is allowing the browser to store any cookies present in `Set-Cookie` response headers. See https://fetch.spec.whatwg.org/#cors-protocol-examples last example: "The developer of foo.invalid returns, now fetching some data from bar.invalid while including credentials. [...] This also makes any `Set-Cookie` response headers bar.invalid includes fully functional (they are ignored otherwise)." I believe this change is fundamentally necessary to help developers like myself, who are facing the issue of the user agent not storing a cookie even though it is present in the response headers list and all CORS rules are being followed. Some http clients do this automatically, but for fine control, manually deciding when to set the `credentials` property to 'include' is necessary.
This description states that the `credentials` property "determines whether or not the browser sends credentials with the request". This fails to address an obscure and major characteristic of the property, which is allowing the browser to store any cookies present in `Set-Cookie` response headers. See https://fetch.spec.whatwg.org/#cors-protocol-examples last example: "The developer of foo.invalid returns, now fetching some data from bar.invalid while including credentials. [...] This also makes any `Set-Cookie` response headers bar.invalid includes fully functional (they are ignored otherwise)." I believe this change is fundamentally necessary to help developers like myself, who are facing the issue of the user agent not storing a cookie even though it is present in the response headers list and all CORS rules are being followed. Some http clients do this automatically, but for fine control, manually deciding when to set the `credentials` property to 'include' is necessary.
The second paragraph of this section offers instructions on how to "control whether or not the browser sends credentials". This fails to address an obscure and major characteristic of the property, which is allowing the browser to store any cookies present in `Set-Cookie` response headers. See https://fetch.spec.whatwg.org/#cors-protocol-examples last example: "The developer of foo.invalid returns, now fetching some data from bar.invalid while including credentials. [...] This also makes any `Set-Cookie` response headers bar.invalid includes fully functional (they are ignored otherwise)." I believe this characteristic may be what the doc's author meant with "If the server does set the correct headers, then the response, including credentials, will be delivered to the caller". This is the only instance I could find where credentials are mentioned in the context of the server's response, and not just what can be sent by the user agent.
sideshowbarker
approved these changes
Jul 12, 2024
|
Francisco, thanks much, and congrats on landing your first docs change here — welcome aboard 🎉 |
amaralis
added a commit
to amaralis/mdn-set-cookie
that referenced
this pull request
Jul 13, 2024
Extends the first warning of the article, also related to browser behavior, to alert readers to to a relatively obscure and hard to debug characteristic of the Set-Cookie response header. Ties together the additions in PR 34798 (mdn#34798), offering the most relevant links to better help developers understand and fix issues if they arise.
bsmth
added a commit
that referenced
this pull request
Aug 1, 2024
* Add warning to set-cookie article Extends the first warning of the article, also related to browser behavior, to alert readers to to a relatively obscure and hard to debug characteristic of the Set-Cookie response header. Ties together the additions in PR 34798 (#34798), offering the most relevant links to better help developers understand and fix issues if they arise. * Update files/en-us/web/http/headers/set-cookie/index.md Remove extra whitespace Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> * Clarify that behavior applies to CORS requests * Update files/en-us/web/http/headers/set-cookie/index.md Co-authored-by: Francisco Amaral <[email protected]> * Update files/en-us/web/http/headers/set-cookie/index.md --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Brian Thomas Smith <[email protected]>
This pull request was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description
I have changed 3 files, adding to existing sentences that mention that the
credentialsproperty determine whether the browser sends credentials. These sentences now reflect that thiscredentialsproperty also affects the browser's respect for theSet-Cookieheader.Motivation
I spent the last day or two debugging an issue with authentication and authorization between an SPA and a back end using Laravel and Sanctum: my browsers weren't storing the CSRF token cookies that the back end sent in
Set-Cookieheaders when its/csrf-tokenendpoint was hit. Which resulted in javascript being unable to actually read the token and set it as an X-XSRF-TOKEN request header in subsequent requests, and a complete breakdown of the application.Up to the 5th page of several google searches, the matter of the browser sending credentials is mentioned. Nowhere I looked did I find a single mention - not one - of the
credentials: 'include'request option affecting the browser's respect for theSet-Cookieresponse header (except in the actual specification linked in the docs for using the fetch api, and even there only as an example). I believe this is caused by overuse of http client libraries that setcredentials: 'include'on every fetch request, whether necessary or not. Since I want to avoid that and bloat, I use vanilla javascript as much as possible.Additional details
See https://fetch.spec.whatwg.org/#cors-protocol-examples, last example:
(bold italic mine)
Related issues and pull requests
None to my knowledge