Proxy uses visited website's username/password for authentication

I have the following setup:

  • Web server: (Login by HTML page, username1/password1)
  • Web server: (Login by HTML page, username2/password2)
  • HTTP Proxy: (Login by HTTP basic auth, username1/password1)
  • KeePass 2.52 with KeePassRPC Plugin 1.14.0 and latest Firefox/Chrome plugins
  • 3 KeePass entries with URLs set to,,
  • A pac.js proxy auto configuration file used by Firefox and Chrome:
var FindProxyForURL = function(url, host) {
    "use strict";
    if (shExpMatch(host,'')) {
        return 'HTTPS; DIRECT;';

    if (shExpMatch(host,'')) {
        return 'HTTPS; DIRECT;';
    return 'DIRECT';

Now the bug/problem:

  • When I visit first, a HTTP basic auth dialog pops up, I select the only existing entry (username1) and the proxy allows me access to the otherwise unreachable web server, where I can login by entering the login data on a HTML page. If I visit next, the page also loads fine since the proxy authentication is cached in my browser
  • When I visit first, a HTTP basic auth dialog pops up, but I am only presented with the username2 login option. username2 is the account for, but currently is asking me for login details, so the login details for should be offered, not the ones for When I click to login with username2, the dialog pops up again and again since the proxy authentication is done with the wrong credentials.

I expected a combination of updates to Firefox/Chrome and Auto-fill HTTP Proxies by luckyrat · Pull Request #153 · kee-org/browser-addon · GitHub to fix this problem several years ago but I have no way of testing it myself and the only feedback I received on it via an old GitHub issue ( Proxy moz-proxy:// is requesting a username and password · Issue #92 · kee-org/browser-addon · GitHub ) was that it is “not working” so no further progress has been made on integrating the fix to the released extension.

If you are comfortable building the extension yourself, I have just rebased the PR so it would be worth a try to see if that code change resolves the issue for you.

Failing that, I expect I will incorporate that change into a new beta version of the extension later next year as part of the work to rewrite the extension for “MV3”, but only if Chrome and Firefox continue to support extensions enhancing proxied connections (something that Chrome at least seemed unwilling to allow when I last looked into it). For that reason, I won’t be able to spend much time focussed on this at the moment but if you find that the PR solves the issue for you, you should be able to keep using that self-built version for a while.

Sorry for the delay. I tried building the extensions, but I was unsuccessful.

When I try Firefox, I only get a warning Reading manifest: Warning processing version_name: An unexpected property was found in the WebExtension manifest., but no obvious error messages and nothing happens. If I click on the Kee icon next to the address bar, a completely black window opens, but nothing else happens either.

When using Chrome, Kee asks me to connect to Keepass, which works fine as far as I can tell. When clicking on the Kee icon, a completely white window opens.

Chrome shows me two warnings:

  • Unrecognized manifest key 'applications'.
  • Manifest version 2 is deprecated, and support will be removed in 2023

and one repeating error:

  • AsyncBlockingCallback promise failed: TypeError: Failed to construct 'URL': Invalid URL

triggered by background/background.js:1959.

When I visit a website where login information is stored, Kee fills out the login details, but a click on the icon next to the username/password field also just opens a white window with no content.

When I visit or (from above), I get a normal Chrome HTTP basic auth login dialog for which is not caught or filled out by Kee.

After manually filling out the proxy login details, the destination website loads and the correct login information is filled out by Kee.

I don’t know anything about JavaScript debugging, but it appears that Kee (with the changes from branch feature/92/proxy-authentication) will no longer detect the Proxy connection at all.

The login details on a different website with HTTP basic auth, which does not require the proxy, are filled out correctly.

I assume the “white window” problem is just a UI bug and does not affect the proxy detection.

You can ignore the two Chrome warnings but the error might be a problem. The AsyncBlockingCallback is probably the method that should be handling the interception of the proxy request so it throwing an unexpected error would probably explain why Chrome just falls back to the standard proxy dialog. I would guess that whatever string I was expecting Chrome to supply is not in the expected format. Perhaps it just needs manipulating into a valid URL format or perhaps it is missing entirely.

Can you put a breakpoint on background/background.js:1959 and investigate what value is being passed down to that URL constructor? Hopefully the sourcemaps are working in some reasonable way but if that is just an insanely long line of compressed javascript you might want to give up before spending lots of time trying to inspect the relevant part of the line. Firefox and Chrome often work in different ways with sourcemaps so if it’s useless in one, trying the other often helps. Actually, it’s been a couple of years since I’ve done a lot of Javascript/TypeScript debugging myself so I hope that it is a less buggy experience by now.

Have you tried building and running the master branch in Firefox? Just in case it narrows down whether the problem is specific to the changes on that PR branch. If it doesn’t work with either, maybe see if removing that version_name line from the manifest is the solution. We have to produce different manifest files for each browser so it’s possible that the debug version you’ve built no longer works happily with both browsers. You are loading it as a temporary extension in firefox I guess? (from the “debug addons” page). I think that most Firefox builds would complain about the addon being unsigned unless you load it that way so that’s probably not the issue but I figured I’d mention it just in case.

I suspect that a similar error is happening in Firefox but you’re just not seeing it because of the different contexts in which things like the popup panel, background process and webpage scripts execute. You might have to enable background process debugging or something similar (again, I’m not certain what they call it in the current Firefox version but hopefully that’s a useful hint). I recall that in the debug inspector window, the “Disable popup auto-hide” feature is very useful when trying to debug anything happening inside the popup. Chrome didn’t used to have anything equivalent.

I’ll try to check the exact behaviour with the current browser versions in the new year but thought if you get a chance before that, the above hints might help us make progress in the mean time.

No success with the current master.

In Firefox, the Kee symbol appears next to the address bar, but it is not even clickable any more. Besides than, nothing else happens.

In Chrome loading the extension fails instantly on load because of some missing file common/common.js, which does not exist when building master, but exists when using feature/92/proxy-authentication.

Like I wrote, I know nothing about JavaScript debugging, so I’m not sure how to get the contents of the argument passed to background.js.

After reading the contents of background.js, the line directly before the failing function says:

        // Firefox fails to register the event listener so this function
        // only executes in other browsers

So I guess that function is only responsible for the Chrome fails, not for the Firefox problems.

Just to be sure I also tried loading the GitHub version tagged “3.9.5” as Firefox temporary extension. It will insert a clickable icon in the address bar, but clicking on it shows the same black window. (3.9.5 installed from the Firefox web store works fine).

Chrome with the GitHub 3.9.5 version also complains about missing common/common.js and does not load, while the version from the Chrome web store works fine.

So I guess that function is only responsible for the Chrome fails, not for the Firefox problems.

Well that depends on what is on the line below. It is possible that you’re looking at a minified version of the source such that the start of the line is the function referenced by that comment, but the rest of the line might contain many other functions (up until the next comment or other reason for the minifier to break onto a new line).

I followed the build instructions in the repo’s readme but I found that the browser-specific directories (chrome and firefox) didn’t exist after running npm start (perhaps something changed with npm or gulp in recent years). Instead, I ran web-ext run inside the all directory. I would expect that to behave the same as if you loaded it into the browser as per the instructions in the readme but since I don’t have access to a development browser profile at the moment, I installed and used web-ext to create me a temporary one for the purpose of testing this.

After doing this for both master and the PR branch, I was able to successfully see the expected popup structure (menus, buttons, etc.) in the Kee popup, for both branches.

If you’re not testing this with a fresh/temporary profile, maybe that might explain the completely black/white popup problem you’ve seen. I also tried running web-ext run --devtools to look at the console for the popup script and background script and couldn’t see any error messages or warnings there.

This was using Firefox 108 on Linux. I’m not sure why web-ext is using Firefox rather than the Developer Edition I have installed as my default but I guess that program handles any necessary configuration changes or signature bypass - it’s the first time I’ve ever run it because it was not usable when I last updated the extension’s build process and infrastructure.