Auth Header in Fetch Redirects (Chrome v119+)

[sachinjain024]

Hey everyone, We're building Requestly - An Open-Source Chrome extension to intercept & modify HTTPs requests. One of the major use cases of Requestly is to redirect the APIs from production to the staging/local dev environment.

Post chrome v11 release in the first week of November, lots of Requestly users have started complaining that their redirects have started failing with 401 error. Here is the github issue in Requestly repo.

Upon further investigation, we found this happening in Chrome v119+ users. We would like to know how to solve this in MV2 and MV3, respectively.

One suggestion for MV2 is to monkey-patch the fetch request and pass the auth header to the background to add the auth header explicitly in the case of cross-origin redirect. This might work, although it seems too hacky of a solution.

We couldn't think of any solution in the MV3 approach. We'd appreciate the help here.

[oliverdunk]

To provide a bit of extra context, this change was made to align with the spec and sounds like it is already the behaviour in Firefox and Safari: https://groups.google.com/a/chromium.org/g/blink-dev/c/3Zt4UHbynYA/m/9CZ3fFdnAQAJ

I think an interesting question to ask is if we should provide something to support this use case in DNR. I'm not immediately sure what that would look like, but this seems like a reasonable use case.

[sachinjain024]

Since the MV3 timeline has also been released, we'd appreciate some solution for MV3.

A separate line of thought is whether browsers should consider redirects to localhost/127.0.0.1 as cross-origin redirects. IMO redirects to localhost(s) should be fine, and auth headers should be passed along.

This will not solve 100% of the problem but should cater to a bit though.

[bershanskiy]

@sachinjain024 Is this still an issue for your extension? Looks like you had a fix which was reverted at some point.

[rustyzone]

I recently found this to also be the case for any custom headers provided (that I had tested) unless the URL was included in host_permissions or permissions.

Downloading & running these will show a not valid json error etc.. as these are dummy api urls, but if you remove the entry from the host permissions it will have a cors due to the custom header.

Examples: MV3: play.web-extensions.dev link

MV2: play.web-extensions.dev link

[sachinjain024]

@bershanskiy For MV2, we have found a fix. We had to revert it because of a regression, but the solution won't work for MV3.

For MV2, we have monkey patched the window.fetch object and checked if there is a cross-origin redirect configured in Requetly on a particular fetch request; then, we copied the auth header to the x-auth header.

In the onBeforeSendHeaders handle, we copied the x-auth to the auth header and removed the x-auth header. We also had to handle the CORS issue due to adding this custom auth header.

We can't take this approach in MV3, as we don't have the necessary controls with MV3 API due to its declarative nature, and that's why it is important for us to have a solution for this when we do the complete MV3 migration. We're almost 80% done with our MV3 migration; this is a blocker for us.

We will really appreciate any help here!

[nafees87n]

Upon investigation, it has come to attention that this change affects not only fetch redirects but also XHR cross-origin redirects. We have observed that the Authorization header is not forwarded in both cases.

[oliverdunk]

I've left a comment in the fetch WG summarising the feedback here: https://github.com/whatwg/fetch/issues/1631

So far, this only seems to impact a small number of unique use cases. I appreciate that in those cases, this is very important of course, but it does make it harder to prioritize any changes to either the web API or extensions.

Please keep the feedback coming especially if there are any new use cases. In the meantime, I'll keep an eye out for updates in the fetch issue.