Proxy asks for username and password, despite being already correctly set inside ZeroOmega's configuration

[sn-o-w]

Browser version & OS version

• Chrome Beta 125.0.6422.41 (x64)
• Windows 11 24H2 (26100.268)

Problem description

For some reason, it asks for the username and password despite I already set those.

Steps to reproduce issue

1. Go to ZeroOmega and add a proxy that requires a username and password.
2. Close and open again Chrome.
3. Notice you will get a prompt to enter the username and password for the proxy (see the first screenshot below)

Screenshots

The displayed text in the first screenshot is in Romanian, but you should be able to reproduce this easily. If necessary, I can set Chrome to English and take another screenshot.

Expected behavior

Proxy to work without manually entering username and password every time.

Actual behavior

Every time I (re)open Chrome, it prompts for a username and password for the proxy.

[suziwen]

I cannot reproduce this issue and need more information on the issue. Maybe the password is wrong, or something else?

When I tested it myself, I found that after changing the configuration password, sometimes I had to restart the entire browser for the password to take effect.

[sn-o-w]

Oh, I forgot to mention something: Sometimes, after I restart Chrome, "auto switch" won't work... I have to manually disable and re-enable "auto switch".

Have a look at the following video:

caf8b245-7127-4bfb-8e22-b0d278d89252.mp4

I had to blur the proxy address and authentication credentials because it is private and I am not the owner of it.

[suziwen]

If I set the wrong password, I can reproduce your problem. Therefore, I suggest you first check whether your password is correct on the options page.

Do not try to enter authentication on the pop-up window. This input information zeroomega cannot be saved for next use.

[sn-o-w]

If I set the wrong password, I can reproduce your problem. Therefore, I suggest you first check whether your password is correct on the options page.

Do not try to enter authentication on the pop-up window. This input information zeroomega cannot be saved for next use.

The username and password set inside ZeroOmega are correct, I even checked them inside the backup I exported. So nothing wrong on my side. 🤔

And what I should do if not enter the authentication on the pop-up window? If I press "Cancel" there, nothing happens, livestream won't load on Twitch. If I refresh the page, I get again the authentication pop-up...

A few mins ago I just started my computer and Google Chrome. I didn't even disable and re-enable "auto switch" and I got once again the authentication pop-up...

Something is still wrong with the extension...

If you need my ZeroOmega settings, I exported them: OmegaOptions-snow.txt [MODIFY "TXT" TO "BAK"!!!]

Modify in the exported file these values - snow123456789 + the port with the values of the proxy you are using.

I use mainly ZeroOmega to get rid of Twitch ads, if you can add a Russian proxy with my backup, you should be able to reproduce the issue I'm experiencing.

[suziwen]

I used your config file and then just changed the proxy to my own and everything worked fine.

Because I can't reproduce the problem here, maybe you need to troubleshoot it yourself, or see if other users have similar problems.

You can then check to see if it is caused by a conflict with other extensions , and then look at the proxy server logs to see if you can find any clues.

[sn-o-w]

I used your config file and then just changed the proxy to my own and everything worked fine.

Because I can't reproduce the problem here, maybe you need to troubleshoot it yourself, or see if other users have similar problems.

You can then check to see if it is caused by a conflict with other extensions , and then look at the proxy server logs to see if you can find any clues.

I just tried again, but in a Windows Sandbox.

I installed Google Chrome (not the beta version this time), followed by ZeroOmega, and imported the settings. And I verified that the username and password were correctly inserted in ZeroOmega. They are correctly inserted.

And I can reproduce the problem even on a clean instance of Chrome...

1. Have you actually enabled "auto switch"? The issue won't appear if "auto switch" is disabled.
2. Have you opened twitch.tv in a (new) tab after you verified "auto switch" is enabled in ZeroOmega?
3. Have you tried to restart the browser, then to verify "auto switch" is enabled, and afterwards to access twitch.tv website?

I can't understand how you don't encounter this issue at all. My only guess I can think of is that you did something different than me. 🤔

By the way, I hope you use a proxy that requires authentication via username and password... Maybe you use a proxy that doesn't require authentication and therefore you don't get any popup for authentication. 🤔

[sn-o-w]

Look, I even recorded in Windows Sandbox:

f3620c87-4840-4a9b-b6ad-dab2aed98c6a.mp4

[suziwen]

🤔 🤔

The proxy server was built locally by myself, port 9053, username/password: u1/p1.

When I change the password to the wrong value, after restarting the browser, the authentication window pops up. When I change it to the correct p1 and restart the browser, I can browse https://www.twitch.tv/ normally. This proves that the authentication proxy function is available. It can also be seen that the authentication function of zeroomega is normal.

zero.mp4

[sn-o-w]

🤔 🤔

The proxy server was built locally by myself, port 9053, username/password: u1/p1.

When I change the password to the wrong value, after restarting the browser, the authentication window pops up. When I change it to the correct p1 and restart the browser, I can browse https://www.twitch.tv/ normally. This proves that the authentication proxy function is available. It can also be seen that the authentication function of zeroomega is normal.

zero.mp4

The authentication pop-up you get is a little bit different. Because in my case, I also get the message "Connection to this site is not private" before the "Username" and "Passwords" fields.

Besides, in my case, the browser also loads some bits of the website before getting the authentication pop-up, but in your case the page is completely empty when you are prompted to enter credentials.

Have you imported my profile correctly? Do you actually have the following switch rules?

These are important.

[suziwen]

😄
Great, it can be reproduced.

Due to my own network issues, I cannot directly access twitch.tv, so I added an additional *twitch.tv rule in auto-switch.

After removing this rule, first use a global VPN proxy to ensure that twitch.tv can be accessed directly. Then import your ZeroOmega configuration file, and I can reproduce the authentication pop-up window problem here.

---

emm, very weird bug, some network requests will not trigger this authHandler function. 🤔 🤔

https://github.com/suziwen/ZeroOmega/blob/815e1626402434b154e117690497a51246338cce/omega-target-chromium-extension/src/module/proxy/proxy_auth.coffee#L63-L84

[ayanamist]

我记得这是一个SwitchyOmega就存在的问题，是Chrome的bug……

[suziwen]

Yes, maybe it is a upstream chromium's bug.
Although this issue ( onAuthRequired is not triggered on requests served by a service worker [40870289] - Chromium ) has been fixed, but there is still another issue ( MV3 onAuthRequired is not triggered by requests made by extension pages [40880379] - Chromium ) which about onAuthRequired not triggered.

[Joyfal]

I also have the same issue with twitch, where it will ask me to input username and password again although the configuration has the correct values. It does not happen all the time (only occasionally). This happens with SwitchyOmega as well

[kvalter]

So, any change you will fix this?

[01101sam]

Update: We need to wait until #40880379 is marked as Fixed then push the patches to prod, those blockers are in fixed state and this is the only issue that’s blocking the whole process.

As said (#31 and #32), I think the fix should be available around Q1.

At that time this issue can be finally be closed.