Open Bug 1768465 Opened 2 years ago Updated 1 year ago

Proxy session control via credentials change is not possible

Categories

(WebExtensions :: Request Handling, enhancement, P3)

enhancement

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: jakob.classic, Unassigned, NeedInfo)

Details

(Whiteboard: [design-decision-needed])

Steps to reproduce:

The proxies that I am referencing here are all HTTP proxies.

It is common practice for proxy companies to use session IDs inside the proxy user credential string to provide session control and keep the same IP for multiple requests or change it.

Quick example using an Oxylabs proxy:
Full Proxy String: “pr.oxylabs.io:7777:customer-USERNAME-sessid-randomString123:PASSWORD”

Host and port are static: “pr.oxylabs.io:7777”
The proxy user credentials are dynamic: “customer-USERNAME-sessid-randomString123:PASSWORD”

Switching the “randomString123” in front of the “sessid” changes your session and with that also your IP.

More about it here: https://developers.oxylabs.io/residential-proxies/#quick-start
You can find the same thing for other big proxy providers such as Smartproxy.

Now here comes the problem with trying to use these proxy sessions inside a Firefox addon:

Once you set your proxy and submit your user credentials, Firefox will save your user credentials for that proxy host (and with that your session ID & IP) and keeps using them.

But I want to change my session for that host. This would only be possible if the "webRequest.onAuthRequired" listener gets called again so I could submit new credentials. However, the "webRequest.onAuthRequired" listener won't get called again because Firefox already saved my credentials for that host and reuses them.

The current behavior is not bad. You don't want to re-authenticate your proxy all the time. But we should get a method to clear our saved proxy user credentials so we can submit new ones and make use of the session control that these proxy companies provide. Another solution could be a way to submit new credentials directly from the "proxy.onRequest" listener that works with HTTP proxies.

If you know of any solutions for this, please let me know. The only "solution" I found is setting your proxy again with a slightly modified host: “pr.oxylabs.io" -> “pr.oxylabs.io." (Putting a dot at the very end). I don't think many modifications here are possible though and Firefox will save your credentials for each one of them again.

Actual results:

You can't make use of the session control that most proxy companies provide because only the proxy username changes but not the host. Because the host is static, Firefox will never ask for a new proxy username so you can't change your proxy session.

Expected results:

We should have a method to force a re-authentication of the proxy so we can submit new user credentials and make use of our proxies' session control.

Severity: -- → N/A
Priority: -- → P3
Whiteboard: [design-decision-needed]

The report mentions webRequest.onAuthRequired and proxy.onRequest, but it is not obvious what your test case looks like.

Could you provide the reproduction steps so that it is more obvious what this report is about?
Ideally a minimal extension that produces the issue, along with (manual) steps to trigger the authentication, and the steps where you expect (but don't get) the ability to re-authenticate.

When I read between the lines, it looks like you are mainly looking for the ability to re-authenticate with the proxy if the credentials have somehow become invalid. What is the current approach + behavior? What is the desired behavior? (in the context of extension APIs)

For the record, there have been prior discussions on proxy authorization at https://github.com/w3c/webextensions/issues/264

Flags: needinfo?(jakob.classic)

Redirect a needinfo that is pending on an inactive user to the triage owner.
:rpl, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jakob.classic) → needinfo?(lgreco)

Hey Rob,
are the details we got so far based on comment 0 still enough to consider this bug actionable even without an answer to your needinfo request from comment 2? (so that we could still triage it)

Flags: needinfo?(lgreco) → needinfo?(rob)
You need to log in before you can comment on or make changes to this bug.