[PRE-RELEASE] Basic auth with chrome plugin not working and stall the browser

[brainfoolong]

I don't know if this should be better posted in the chrome related repository, but since it happen only in the pre-release version i better post it here.

I have a website with basic auth. I have multiple entries that matches the websites domain. When visiting this website KPXC ask me to allow those entries for this page, which is correct behaviour and expected. But after i click "allow", the browser is stalling and waiting for the Keepassxc extension. It does nothing until i manually open the extension open at top right via icon and select one entry manually. Than the browser continue to work and passing correct auth to the website.

This must be done everytime because keepass also doesnt remember my choice, even if i clicked "Remember choice".

This problem only is present when having multiple entries for a domain that uses basic auth. This does not happen with the stable version.

Reproducable procedure:

1. Create 2 entries in your database for https://jigsaw.w3.org/HTTP/Basic/ (username and pw = guest). Note: Not visiting this site before you have created both entries.
2. Use chrome
3. Visit https://jigsaw.w3.org/HTTP/Basic/

Debug Info:
KeePassXC - Version 2.4.0-beta2
Build Typ: PreRelease
Revision: 9bc20f0

Bibliotheken:

• Qt 5.12.1
• libgcrypt 1.8.4

Betriebssystem: Windows 10 (10.0)
CPU-Architektur: x86_64
Kernel: winnt 10.0.17134

Aktivierte Erweiterungen:

• Auto-Type
• Browser-Integration
• SSH-Agent
• KeeShare (only unsigned sharing)
• YubiKey

Here are my screens that show the procudure
Simple entries with just that data


Popup that ask for entries to allow (expected)

Stalling browser (left bottom status info)

Options window to manually choose an entry

[varjolintu]

How about adding the URL schemes to your URL's? Or disabling the URL scheme match from Browser Integration settings?

[brainfoolong]

How about adding the URL schemes to your URL's? Or disabling the URL scheme match from Browser Integration settings?

It makes absolutely no difference what so ever. For me it seems that KeepassXC never successfully handle the "allow" button in this case. After the click the window just disappear and than it hangs.

[varjolintu]

This happens because of #2542. We decided that HTTP Auth permissions should be asked every time, unless it is disabled from the settings (a new setting in the Advanced page: Do not ask permission for HTTP Basic Auth). But you are correct, the Remember option is still visible and now it does nothing. That option must be disabled when using HTTP Basic Auth.

This change was made because some pages can have both HTTP Basic Auth and a normal login and there's no way to split the permissions.

[brainfoolong]

Ok, when i enable the option "Do not ask permission for HTTP Basic Auth" things get even worse. Now the browser hang directly without any popup. Result: I cannot open the page anymore. There is no visible indicator what is going wrong. I have to goto the browser extension options an manually select a credential, to make the browser working again.

[varjolintu]

Sadly, that's how it works. If you have multiple credentials for HTTP Basic Auth, you must use the popup to choose one of them or discard and go to the default Auth popup.

There's a notification that pops up when user interaction is required using the popup icon. If you have disabled the notifications, then the situation you describe happens.

The reason the popup is not displayed automatically is that browser extensions doesn't have a standard way to do that. Firefox supports it but Chromium based browsers don't.

[brainfoolong]

I understand all your ideas. But the problem is simple, the browser will hang, doesn't matter if the popup is activated or not. The popup does nothing. It shows the correct entries, you can select an entry, but it does not apply those credentials.

Only the browser extension options icon at the right top will work, when you select an entry.

[brainfoolong]

It don't talk about the "remember" checkbox, i just talk about the popup in general. It doesn't work as soon as you have 2 or more entries for a domain/page with basic auth.

[brainfoolong]

In the current stable KeepassXC it does work, with the same database entries.

[droidmonkey]

I can confirm this is a big issue. When the Allow/Deny box comes up, pressing allow causes the website to be stuck in a wait state while pressing deny shows the HTTP auth dialog. Activating the browser extension shows the login choices, but choosing any of them causes the wait state to end showing the basic auth dialog. However, the credentials are never filled in.

To me, this is entirely a bug on the extension.

[droidmonkey]

Actually, I think the auth dialog keeps reappearing because the test site doesn't actually authenticate. However, the browser extension dialog should open in lieu of showing the auth dialog. Also, at least for my limited test, duplicate credentials are being provided:

[brainfoolong]

the browser extension dialog should open in lieu of showing the auth dialog

This sounds like a great idea. Cancel the "allow popup" and show extension dialog instead. This should fix the issues. I have no problem with selecting the correct entry manually everytime. The only thing that is important is that the browser do not hang unexpectedly, as it does currently.

[varjolintu]

I haven't been able to reproduce these issues. I also tried the page https://httpbin.org/basic-auth/user/passwd (user/passwd as credentials). I used the 2.4.0-snapshot, rev ff87207. There hasn't be any major changes in the extension side for this. And it doesn't explain why it works with the stable version for @brainfoolong.

Showing the extension popup manually would work only with Firefox.

[brainfoolong]

I've tested further. My argument "works with stable version" isn't true anymore. I can't get it to run with stable. Sorry for that. But here is another short animation of how to reproduce the bug.

You see at the end that the browser hang until i open the extension dialog and manually select an entry. Maybe you disabled "Automatically fill in HTTP Basic Auth dialogs and submit them." in your browser settings?

[varjolintu]

@brainfoolong That works as expected. The KeePassXC auth dialog is only used for accessing the credentials. (At this point it doesn't matter if you choose one of them, Allow/Deny affects to them all). Only after that you can choose the credentials from the extension popup, and yes, the page waits for that interaction. If you choose Deny from the auth dialog, then the default Basic Auth dialog is shown because no permission for KeePassXC credentials were granted.

The page didn't halt after choosing the credentials from the popup. The behaviour is similar to a normal login access - you need a user interaction for filling the credentials.

If I disable "Automatically fill in HTTP Basic Auth dialogs and submit them" from the settings, then the HTTP Basic Auth is not triggered in the extension at all.

[brainfoolong]

Ok. I can only talk from my point of view. I have those credentials unchanged since a few years on the same page with the same database. Recently, after i switched to PreRelease version, and maybe this overlapped with an browser extension update too, this behaviour has changed and now it didn't work for me as i have expected.

The popup dialog suggest, for me, that i allow a specific entry and that's it. It's not clear that i have to open anything else manually after this step. Maybe it's because of my specific settings in the database or whatever, but for me it was not clear.

Now i know my workaround now, but i suggest to make this progress a little bit "easier". Maybe try to open the extension dialog after i click allow in the popup? Maybe submit the credentials from the entry that i have selected in the allow popup instead of having them select twice? Maybe deactivate the "Remember choice" button as it does nothing in this case?

I don't know the technical possibilities, i just drop ideas.

Thank you for all your time. This can be closed if you want.

[varjolintu]

The new version always popups the KeePassXC's permission dialog with HTTP Basic Auth, unless it's disabled from the settings. This is the main difference from the current stable version. Earlier the setting could've been remembered.

But if the page has multiple HTTP Basic Auth credentials set, the same interaction with the popup has been always needed. With #2143 merged in the future, this behaviour can be changed.

The best workaround is to disable the asking of HTTP Basic Auth permissions, like proposed earlier. Opening the extension dialog does not work with Chromium based browsers, so only Firefox users would be affected.

I will disable the "Remember choice" button when permissions are asked with HTTP Basic Auth dialog.

[brainfoolong]

Ok thx, one side question at last: Is it possible to restrain one database entry to an exact url only, while keeping all others lazy found by domain?

[varjolintu]

You can try enabling the setting `Return only best-matching credentials'.

[brainfoolong]

I'll try. Thank you. Keep up the good work.

[Pandiora]

Hey there o7, I discovered the described problem too and I'm a lil bit lost about what to do.

I've 3 database entries for 1 site and one of these is for HTTP Auth. I would like to have the HTTP Auth being filled in automatically, but I've no idea how "Return only best-matching credentials" could help me here? Am I missing something like i.e. telling the extension which one of my entries is supposed to be used for HTTP Auth?

I'm using Chromium 75.0.3770.100, KeepassXC 2.4.3 and latest KeePassXC-Browser and I also encountered a forever loading page. It took me a while to figure out, that I had to click the extension icon to select the credentials for HTTP-Auth - then I'm getting redirected to a blank page and only after I reload the page, I'm actually getting further. (the redirect seems to stall)

Imo this behaviour can be confusing and I'm the proof on my own, since I expected something else - I thought I banned myself on my own server, for failing to authenticate to many times.

I could change the credentials for HTTP Auth, to make the user for HTTP Auth the first entry by username or title if this helps.

[varjolintu]

Currently there are not way to determine that a certain entry is only for HTTP Basic Auth. Can you give the page URL for testing?

Does these three URL's differ in any way, or has the login page the same URL as the HTTP Basic Auth page?

[Pandiora]

@varjolintu I'm giving you an example, maybe it is better to understand this way. I'm using wordpress and it works like this:

• HTTP-Auth for /wp-admin/*
• HTTP-Auth credentails url: https://domain.123
• Site login calls a file from /wp-admin/*
• Site login credentials url: https://domain.123/wp-login.php

Now I came to the conclusion I could work around this problem by including the login-form in another php-file outside of the admin-folder. Maybe you've got a better idea, since my solution wouldn't solve the problem or at least just for this specific case.

P.S: By reloading the site when not on the login-page the redirect works for me now. (by clicking the http-credentials in extension popup)

[varjolintu]

I suggest you try making two credentials and enable the "Return only best-matching credentials":

• HTTP-Auth credentails with url: https://domain.123
• WP credentials with URL: https://domain.123/wp-login.php

"Return only best-matching credentials" option ignores any URL's that are only partially matched. But if the best matching URL is just a partial match, it will be still returned.

[Pandiora]

@varjolintu thx for your suggestion, this seems to work for me and I don't rly get why. I would expect the auth-login to be filled with the best matching login, which should be the one for the site login (wp-login), when I'm accessing the login-page. (I'm calling "https://domain.123" then changing the url to "https://domain.123/wp-login.php")

Sadly the redirect isn't working again and the page loads forever. I need to stop loading and then reload the page to get to the login-page. This isn't a big problem, but should be fixable, since the extension is able to reload a page if needed.

[varjolintu]

When the page loads, is the popup icon active? Meaning there are credentials you can select. I need to find a test page where I can reproduce this problem.

[Pandiora]

This is really difficult to reproduce, but I think I found out how:

• have my blog open (any page that doesn't needs access to wp-admin directly)
• changing the url to wp-login.php

Page loads forever. The extension doesn't show credentials to be selected. Stop loading and reloading the page then works like before and I can login with site-login. When viewing my network tab I can't spot anything out of order, except for 2 stylesheets which are located inside wp-admin having the "pending" status and thus not getting loaded. I viewed my apache-logs and could confirm that the http-auth user were requesting the stylesheets and this said the http-auth definitely worked. By looking at the background tab of the extension, I found this error:

(2) Error: Nonce compare failed - keepass.js (line 1062)

And now the reason why it is difficult to reproduce:

When I delete my browser-cache and so on to get rid of cached http-auth and then opening any page of my blog and then changing the url to wp-login.php everything works fine out of the box - no forever loading page.

[varjolintu]

Have you tried to debug the extension background script background/httpAuth.js and see if anything odd happens there?

[Pandiora]

I'm still trying to test but I can confirm the script jumps to httpAuth.loginOrShowCredentials and returns the auth-credentials. From what I understand this is part of the chrome extension-api and there could be a bug with webRequest.onAuthRequired and the used async blocking.

Now the auth-login always stalls no matter how I'm calling the login-page.

While debugging I checked the details being used:

 challenger:
host: "sub.domain.123"
port: 443
__proto__: Object
frameId: 0
initiator: "https://sub.domain.123"
isProxy: false
method: "GET"
parentFrameId: -1
proxyUrl: "sub.domain.123"
realm: "YOU GOT ME"
requestId: "44468"
scheme: "basic"
searchUrl: "https://sub.domain.123/wp-admin/css/forms.min.css?ver=5.2.2"
statusCode: 401
statusLine: "HTTP/1.1 401 Unauthorized"
tabId: 870
timeStamp: 1563302754871.429
type: "stylesheet"
url: "https://sub.domain.123/wp-admin/css/forms.min.css?ver=5.2.2"

I don't get why the search-url is the stylesheet. Maybe the request is too fast and this way the content isn't accesable? This would make sense, since the stylesheets are pending. But it wouldn't make sense, since the wp-login.php results in HTTP 200 and is loaded correctly. I'm quite not sure if I'm investigating in the right direction, but if so, I could investigate further and alter the login-file.

[Pandiora]

Alright, after further testing I found out the extension is requesting the http-auth for every single file inside wp-admin and wp-login isn't part of wp-admin. That said, now, for whatever reason, the http-auth works for 2 out of 3 stylesheets. (before there were just one authentication in my logs)