-
Notifications
You must be signed in to change notification settings - Fork 328
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
Authorization-removal change was compatibility-breaking #1631
Comments
In non-server environments you could not rely on this behavior so there it is not considered a breaking change. I could imagine offering an option to preserve the header though, even when there's a cross-origin redirect. Thought (Though presumably on servers there is a workaround here by using redirect mode " |
As far as I can tell #763 still applies and so redirect mode |
Why does it apply to servers? Reportedly server implementations of fetch can read cookies as well, so why would they hide redirects? |
I don't know why nodejs hides the destination URL from redirects, but I tested 18.15.0 and empirically it does. My guess is that they implemented parts of the spec that were intended for browsers, and didn't consider it carefully enough to notice the functionality-hole this created. |
An interesting issue was raised in the Web Extensions Community Group by a developer impacted by this change: w3c/webextensions#502 In their case, they have an extension which redirects an API endpoint to a local server, to make development easier. They don't want users to have to configure API credentials in their extension if the request already has them but need credentials from a request to be passed along to the local server. Since extensions are moving towards the
If this was an option I imagine it would be sufficient, since the extension could wrap any fetch requests and make sure they set the parameter (extensions are already in a privileged space and can run scripts on the page). A few other options that come to mind:
Happy to chat more if there's interest. I wanted to pass on the feedback since I found it interesting. |
Removal of the
Authorization
header when a request is redirected was proposed in #944, merged into the spec in #1544, and implemented in nodejs in18.4.0
. This broke my program; see nodejs/node#46287.I have worked around the problem by switching from nodejs's builtin implementation of
fetch
to thenode-fetch
library, which has not implemented this spec change. However, I'm worried thatnode-fetch
is going to make the same change, in which case I'll be forced to pin an obsolete version and accept whatever security issues that creates. As far as I can tell, there is no documented way to handle the case where you have an API key and an endpoint that's going to redirect you. The spec change proposal alludes to an analogouscurl
behavior, which curl disables with--location-trusted
, but there is nothing analogous to--location-trusted
in thefetch
specification or the documentation of any of its implementations.The text was updated successfully, but these errors were encountered: