Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(withXSRFToken): added withXSRFToken option as a workaround to achieve the old withCredentials behavior; #6046

Merged
merged 36 commits into from
Nov 14, 2023

Conversation

DigitalBrainJS
Copy link
Collaborator

@DigitalBrainJS DigitalBrainJS commented Oct 30, 2023

Since automatic XSRF token sending when the withCredentials option is set has become considered a vulnerability, although it could be disabled, the only practical solution is probably to add a separate option to control the sending of the token.
So now the user must explicitly set withXSRFToken to true to send XSRF token to third-party origins.
By default withXSRFToken is undefined - the token will be sent only to the same origin.
You can set it to false to disable setting the header at all. In practice, this is the same as setting xsrfCookieName or xsrfHeaderName to falsy.
To migrate from the old withCredential behavior (<v1.6.0), you should now use withXSRFToken along with withCredential.
You can emulate the old unsafe behavior with just one line:

axios.defaults.withXSRFToken = (config) => !!config.useCredentials;

See #6028

📢 This PR added 'withXSRFToken' option as a replacement for old withCredentials behaviour. 
You should now use withXSRFToken along with withCredential to get the old behavior.
This functionality is considered as a fix.

� Conflicts:
�	package-lock.json
�	package.json
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
add_to_changelog Add the PR to changelog when releasing v1.6.2
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants