Re: [whatwg/fetch] Authorization-removal change was compatibility-breaking (Issue #1631)

An interesting issue was raised in the Web Extensions Community Group by a developer impacted by this change: https://github.com/w3c/webextensions/issues/502

In their case, they have an [extension](https://requestly.io/) 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 [`declarativeNetRequest`](https://developer.chrome.com/docs/extensions/reference/api/declarativeNetRequest) API, which is fully declarative, they can't run any logic which could access the credentials before redirecting and really need the browser to handle this.

> I could imagine offering an option to preserve the header though, even when there's a cross-origin redirect.

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:

- Could there be a default exception for requests to `localhost`?
- We could add/make changes to an extension API. This is unlikely to be a priority unless this situation comes up more though, so it'd be nice to solve on the web if possible.

Happy to chat more if there's interest. I wanted to pass on the feedback since I found it interesting.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1631#issuecomment-1954043452
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1631/1954043452@github.com>

Received on Tuesday, 20 February 2024 11:45:32 UTC