Proxy moz-proxy://192.168.0.1:3128 is requesting a username and password

[andZer31]

Hello all,

I’m using Firefox 57.0 (64-bit) and KeePass 2.37 with KeePassRPC 1.7.3 on Windows 10.

Before updating, when launching my browser, KeeFox was able to autofill my proxy (Squid) authentication. There is an entry for this in KeePass.

Now, I’m forced to manually fill the auth form.

Is there a solution?

[bumbumquietsch]

Can confirm this problem with the Proxy-Addon Windscribe.
Everytime I open a page that goes through the Proxy, a Popup opens asking for credentials (with a list of credentials to choose from that belong to the site I want to open). If I close the Popup simply nothing happens and I have an empty tab with empty url-bar.

[luckyrat]

I'll investigate what it would take to enable this feature soon and update this issue when I know more.

[luckyrat]

I'm assuming that you have entries in your KeePass database with a URL that matches the URL of the proxy you are connecting to. Let me know if I've misunderstood.

I've not got a proxy available for testing but think that the changes I've made in #153 will enable the support that you want. Is anyone willing and able to checkout that version of Kee and test it using the build guidelines in the README?

https://github.com/kee-org/browser-addon/blob/master/README.md

[andZer31]

Hi!
Yes, you are right. I've got an entry for my proxy in KeePass (2.3.8) matching the URL.

With FireFox 56.0.2 and Kee 1.7.2 it looks like this

With FireFox 56.0.2 or 58.0.1 and Kee 2.1.26 it looks like this

Kee is not offering the Auth Data and after entering it, it is also not offering to save them as a new entry e.g.

For now I went back to FireFox 56.0.2 and Kee 1.7.2

I will try Version 2.2.1 with FireFox Developer Edition later (or tomorrow) and let you know if it works.

[andZer31]

Did it know. FireFox Developer Edition 59.0.b5 and Kee 2.2.1, same problem, proxy auth is not filled in

[luckyrat]

Thanks for the info.

2.2.1 is not expected to work. The potential change that will make it work is on an experimental branch (see #153) so you'd need to download the source code and build it yourself to test. I'd like to know it functions correctly before accepting it onto the master branch and committing to a 2.2.x release containing the change.

[andZer31]

Downloaded source code and build it myself, added to FF Dev Edition, but problem is not solved with it, no auto fill

[bumbumquietsch]

My problem is a bit different.

If I want to open a site, that uses the proxy (e.g. pandora.com) and Kee is activated (2.1.26), I get the following popup:

In English:

A proxy needs you for authentication before you can access https://pandora.com
Choose a loginform from the list below or close this windows to manually enter the login-information.

The login in the list belongs to the site directly, not the proxy. If I hide this entry from Kee (Via Keepass - Hide from KeeFox) and then try to access the site, simply nothing happens. I am greeted with an empty tab.

[luckyrat]

I think that @andZer31 is seeing this popup as soon as the browser starts? That might explain the different behaviours and the fact that the feature I added in #153 has no effect. I was a little confused when I developed that feature because the code indicated that the current behaviour would be as @bumbumquietsch has experienced and it was not clear to me why a "moz-proxy" native dialog is being displayed for @andZer31. On reflection, I suspect it is because the requests for authentication are triggered by a system event (e.g. checking for browser updates) - this is the feature that Firefox claim to have implemented support for in 57 or 58 (their release notes are inconsistent... which does raise the question whether they implemented it as documented at all).

@bumbumquietsch I think that if you build and run the test version on the feature/92/proxy-authentication branch, it will probably work for you. It would be good to see if that's the case.

[andZer31]

Yes, got the popup at startup. After debugging web proxy, I saw that Firefox tries to connect to http://detectportal.firefox.com/success.txt at startup what causes the auth request. Added detectportal.firefox.com to a whitelist with no auth required (and created a packet filter rule allowing http to that dns domain group). Now there is no popup after startup anymore. When surfing to a website, auth popup appears but without auth filled in, see pictures above.

[luckyrat]

I won't have time to work on this issue further for at least a couple of weeks. Anyone else can feel free to investigate further and submit a PR against the feature/92/proxy-authentication branch if you find a way to make it work.

[andZer31]

OK, that's the way it is.
What changed between Kee 1.7.2 and 2.x.x is the question.
It is working with Firefox 56.0.2 and Kee 1.7.2, but not with Firefox 56.0.2 and Kee 2.x.x
So I would say it is not a Firefox issue, some modification in Kee 2.x.x is the reason.
I do not have developing skills, so I'll have to wait and will stay at Firefox 56.0.2 and Kee 1.7.2 for so lang.
Thanks for all your great work!

[roadkell]

Seems like my situation is similar to @bumbumquietsch - I also use Windscribe VPN extension, and at Firefox startup I get a random number (usually 1 to 5) of similar popups in my face, which are related to the currently opened (auto-restored) tabs or to recently closed ones (from a previous session). Sometimes, they reopen immediately after I try to close them. Once, the number of popups has skyrocketed to about a hundred, and trying to close them as fast as they were popping up was somewhat like fighting a hydra.
Upd: Firefox 57.0 (64 bit), Kee 2.1.26

[luckyrat]

Mozilla have recently been discussing changes to the proxy support for the current (apparently broken) APIs, potentially moving some of the features we need into a new proxy API that's specific for that purpose rather than utilising parts of the HTTP Auth API. It's not clear to me what (if anything) has changed yet but I suggest we stay well clear of attempting any proxy support for a couple of months until they sort things out at their end and we see a stable API in at least a beta version of Firefox.

[roadkell]

Sorry for bumping it again, but this was hilarious (if not scary). FF 57.0 (64 bit), Kee 2.3.19.1.

[andZer31]

I'm now using Firefox ESR 52.7.3 with Kee 1.7.2 and everything works fine. ESR 52 and Kee 2.x.x and it is not working, so like said before, it is not a Firefox proxy api etc issue, it is a Kee 2.x thing

[luckyrat]

Mozilla have just added another proxy bug fix into Nightly: https://bugzilla.mozilla.org/show_bug.cgi?id=1457213 (focussed on enabling a way for extensions to work with proxies when the browser first starts).

I'm not sure how this behaviour compares to Chrome but even if it allows us to enable support for proxies in some web browsers, that will be an improvement.

It's a shame it's not made it into the ESR v60 release although I suspect it won't require incompatible code so when we include this feature into a new version of Kee we can probably safely set v60 as the minimum required version and those on the ESR build will just have to wait for a year for all the bugs to be ironed out by the next ESR release.

It's still going to be a month or two at least before I will be able to take a fresh look at whether all the recent fixes to Firefox will make adding this feature feasible now.

[Zciwobukaj]

Hello,
any news on this issue ? I have this problem today.

Thanks :)

[luckyrat]

Kee v3.0 will bump the minimum required version to Firefox 60 (ESR) and I think enough time has passed for it to be worth investigating what proxy support is now available in more modern Firefox versions so I'm removing the blocking label and hope to at least investigate our options before Kee 3.1 is released.

[luckyrat]

I think this issue needs to be considered as two independent enhancements but I won't split them to different issues until some further progress has been made.

Supplying credentials to a proxy during browser startup

There are many technical challenges with this issue but possibly the biggest is not really technical:

How long does the user want to wait at startup for credentials to be made available from the password manager?

The best I can come up with is: until the user clicks a button to say "Stop waiting".

We could show a window with messaging and a button a bit like this:

Kee is waiting for you to open your password database.

Your browser will not work correctly until you do this or click the button below.

[Stop Waiting]

Assuming we go for that answer or find a better one some day, the technical challenges can then begin.

There is no documentation about how to actually implement this technically but after a few hours searching I've dug out one clue from last year: https://bugzilla.mozilla.org/show_bug.cgi?id=1501159#c12. I have no idea if that will work the same in other browsers.

Rough notes on what would be required to implement this follow:

• A new onAuthRequired listener at top level in KF.ts, added before the current first-step for loading the extension (async load of our config)
• Create a promise that gets resolved when NetworkAuth.startListening() has been run.
• Resolve the promise with the function that currently gets invoked by existing event handlers (possibly need 2 different versions of all this code to handle Chrome and Firefox differences)
• Assign the resolved function to a local var so that all pending network auth requests can be handled and all future auth requests can flow straight through to execute that function without the need for the promise
• Create a separate promise that gets resolved by the user action of clicking on the "stop waiting" button
• Create a new dialog window (store some sort of global reference so we only create one even if there are multiple auth requests at startup)
• Launch that dialog window the first time the onAuthRequired listener is invoked (unless NetworkAuth.startListening() has already run - need to be able to track that somehow)
• All above must be implemented in a way that easily allows a config setting to influence the waiting period - either by disabling the feature (no waiting), waiting indefinitely (per the plan above) or waiting for up to a certain number of seconds. It's not necessary to actually implement those config options though - it can be slotted in retrospectively if we find a real-world benefit from them.

Regrettably I'm leaning towards saying that this enhancement is too high cost and risk for me to attempt in the foreseeable future but if someone manages to find the considerable amount time required to implement and test all of the above on multiple browsers I'm happy to accept a pull request.

Supplying credentials to a proxy when the browser is already fully active and KeePass/Kee Vault is open and unlocked

I've updated the old pull request so if you download and build that version of Kee I think this might work.

I still can't find any practical way to test this myself so as before, I need people who are actually using a proxy to build and test this custom version of Kee before I can take this issue any further.

Please let me know how you get on with this test version.

[erwanJarno]

#153 not working for me under Firefox 70.0.1 and KeePass 2.43