Auth Header in Fetch Redirects (Chrome v119+)

[Sachin Jain]

Hi everyone,

This is Sachin - Founder & CEO, Requestly - An Open-Source Chrome extension to intercept and modify HTTPs requests.

One of the major use cases in Requestly is to redirect API endpoints from production to staging/local dev endpoints. Requestly (right now on MV2) uses webRequest API to do the redirects defined by the users.

In Chrome v119 (notes here), the Authorization header is not passed when the fetch request is redirected to a different origin when developers want to redirect API calls from production to staging/local dev endpoints.

Here are more details on the Github Issue - https://github.com/requestly/requestly/issues/1208

Could you please suggest how to fix the issue in MV2 & MV3 respectively?

Best,

SJ - Founder & CEO, Requestly!

Download | LinkedIn | Github

[Oliver Dunk]

Hi Sachin,

Thanks for bringing this up. It's a really interesting use case.

In MV2, I suspect this may be possible by recording the value of the Authorization header when you first see the request, and then re-applying that after the redirect? That may be worth experimenting with.

In MV3, I think this would be trickier. If there's any way of knowing the value (by looking at a cookie, having the developer enter it etc.) you could of course set the header using another DNR rule. If that isn't possible, which sounds like it might be the case, this might be something we need to add support for in DNR. I'll ask the team to see if they have any ideas I don't. Otherwise, you could consider opening an issue at https://github.com/w3c/webextensions and we can discuss this in the community group.

Thanks,

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/9e97bef8-5658-46c8-b63b-94da5ef45bbdn%40chromium.org.

[Sachin Jain]

Hey Oliver,

In MV2, chrome.webRequest API doesn't allow you to read the value of the Authorization header. You can check the following screenshot taken from https://developer.chrome.com/docs/extensions/reference/webRequest/#life-cycle-of-requests 

So the only option we can think of is overriding the fetch object on the page and passing the value to the background to add the auth header in case of redirect setup, but it feels too hacky of a solution. Right now, lots of users are getting impacted by this and uninstalling because of this.

Of course, one way is to add a header rule manually, but it is very inconvenient, and the Auth value changes over time, so the manual setup creates issues over time, too. I will open an issue on https://github.com/w3c/webextensions with the relevant details.

Best,

SJ - Founder & CEO, Requestly!

Download | LinkedIn | Github

On Mon, Dec 4, 2023 at 4:52 PM Oliver Dunk <olive...@google.com> wrote:

Hi Sachin,

Thanks for bringing this up. It's a really interesting use case.

In MV2, I suspect this may be possible by recording the value of the Authorization header when you first see the request, and then re-applying that after the redirect? That may be worth experimenting with.

In MV3, I think this would be trickier. If there's any way of knowing the value (by looking at a cookie, having the developer enter it etc.) you could of course set the header using another DNR rule. If that isn't possible, which sounds like it might be the case, this might be something we need to add support for in DNR. I'll ask the team to see if they have any ideas I don't. Otherwise, you could consider opening an issue at https://github.com/w3c/webextensions and we can discuss this in the community group.

Thanks,

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

On Thu, Nov 30, 2023 at 1:01 PM 'Sachin Jain' via Chromium Extensions <chromium-extensions@chromium.org> wrote:

Hi everyone,

This is Sachin - Founder & CEO, Requestly - An Open-Source Chrome extension to intercept and modify HTTPs requests.

One of the major use cases in Requestly is to redirect API endpoints from production to staging/local dev endpoints. Requestly (right now on MV2) uses webRequest API to do the redirects defined by the users.

In Chrome v119 (notes here), the Authorization header is not passed when the fetch request is redirected to a different origin when developers want to redirect API calls from production to staging/local dev endpoints.

Here are more details on the Github Issue - https://github.com/requestly/requestly/issues/1208

Could you please suggest how to fix the issue in MV2 & MV3 respectively?

Best,

SJ - Founder & CEO, Requestly!

Download | LinkedIn | Github

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsub...@chromium.org.