Keepassxc: 2.6.1: browser does not find entry

[matthiasschroder]

Overview

When using KeePassXC 2.6.1 the browser module in Firefox 79 claims it can not find an entry. 2.6.0 works fine on the same site.

Steps to Reproduce

1. Install 2.6.1
2. Visit website
3. Click on Browser modul

Expected Behavior

Browser module recognizes website and pre-fills username and password field

Actual Behavior

I get a notification saying "Error! No login found" (text might be slightly different...)

Context

KeePassXC - 2.6.1
Revision: Not sure, I just went back to 2.6.0

Operating System: macOS

[varjolintu]

Check your entry URL and if you have Best-matching credentials setting enabled. There's a small fix for handling subdomains and paths correctly.

[matthiasschroder]

Thanks for your reply. Best matching credentials was enabled. I noticed I had 'https://fqdn' in the db, but the actual URL was 'https://fqdn/index.html'. Putting the full URL made KeePassXC find the entry.

But this is a bit annoying, due to credential expiration I would need this to match any URL that starts with 'https://fqdn', how can I achieve that?

[varjolintu]

If you use https://example.com it will work as a wildcard for https://*.example.com/* unless you have the _Best-matching credentials_ enabled. Then those wildcards won't work.

[matthiasschroder]

I see. That is a strange side-effect of the Best-matching setting, and this is a change of behaviour with 2.6.1, isn't it?

[varjolintu]

Yes. Actually the setting finally works as it should. Your best bet is to disable the _Best-matching_ setting and use URL's without paths.

[MaxXor]

Same here, after update to 2.6.1 all my browser autofill logins aren't working anymore, I tested several sites... this is the 2nd time now this year. Can we finally add unit tests to the autofill/retrieval feature for the browser plugin so it doesn't break every X releases? (I don't use URLs with paths)

[varjolintu]

@MaxXor I guess the main reason why this happens is the _Best-matching credentials_ used with URL's with paths. Previously the option didn't actually handle subdomains and paths correctly. Now it does, and the bad part is that a lot of people have used the same URL's quite a long time and used the "wrong" handling without any problems. Considering that, I'm pretty certain this is actually not a bug.

[varjolintu]

More details about the change here: https://github.com/keepassxreboot/keepassxc/pull/4832

[MaxXor]

My URL is set to "https://discord.com/" and it doesn't find any logins for discord web (I don't use URLs with paths).

[varjolintu]

@MaxXor Are you using the _Best-matching credentials_ setting?

[MaxXor]

Yes

[varjolintu]

@MaxXor Well, then you should use https://discord.com/login instead.

[jmichler]

But this does not make sense. Then the name would need to be "exact matching URL only" instead of "best matching". It is quite widespread to have dynamic or at least frequently changing parts in the URL

[varjolintu]

@jmichler Yeah it doesn't. It should still return the first credentials.

[hrez]

So, how to make it work with https://discord.com in db now? - It doesn't work regardless of "best match" option.

[varjolintu]

@hrez Using https://discord.com/login as said in my previous message.

[MaxXor]

But what if I only want to use the domains and not full paths? As @jmichler said, these full paths can change often. Previously KeePassXC has worked great in that regard, so why is it necessary to use full paths now?

[matthiasschroder]

I have no problem using domains only once I disabled the Best-match option.

[gpant]

With the old behaviour we could get the specific result for the correct hostname on a domain, now this is not working any more.

For example with the old way the best-matching option would allow this to work perfectly fine:
https://host1.domain.tld/ UserA/PassA
https://host2.domain.tld/ UserB/PassB
https://host3.domain.tld/ UserC/PassB
This will not work anymore, since with best-mathing you don't get any user/pass pair and without it you get ALL pairs on that domain.

[hrez]

@hrez Using https://discord.com/login as said in my previous message.

Sites often internally restructure by changing the URL. Or they have multiple autherntication URL's inside.
I want only the domain to be used for a credential match.

[hrez]

I have no problem using domains only once I disabled the Best-match option.

It didn't work for me. It was basically no longer usable so I had to revert to 2.6.0.

[varjolintu]

@gpant This is strange because the update should've fixed that kind of URL's. I really need to double check this.

[MaxXor]

It's such a critical feature that should not break every now and then (unit tests?).

[varjolintu]

@MaxXor We did unit tests for this, and I tested it also manually several times along with another user. This is why I find this very strange. Might have totally missed something.

EDIT: I'm already debugging this.

[MaxXor]

Thank you very much @varjolintu. :rocket:

[varjolintu]

@gpant Does your entry URL's have a / char at the end if it's just a subdomain URL? Seems the Best-matching tries to match that too. Site URL's always have a default path / but it's not needed in entries. So as a workaround you can add the / at the end of your entry URL's.

[gpant]

@varjolintu It seems the opposite is happening, I do not have the / in the end of the URL, the moment I updated an entry and added it it worked.

[varjolintu]

Made a fix for it. Needs to be properly tested. We don't want this to happen again.

https://github.com/keepassxreboot/keepassxc/pull/5316

[Tremolo4]

I have domains only without a slash at the end and it started working again after turning off "Return only best-matching credentials" (2.6.1).

Also thanks for the quick fix! Here's hoping it'll fully work next release.

[Renegade-Master]

Same thing was happening to me with the new 2.6.1 release. I thought I had broken something.

For example, my ProtonMail entry URL reads https://protonmail.com/ as I am trying to make all of my entries aware only of the domain rather than the whole path. I originally had "Best Matching Credentials" enabled, and in previous versions the browser extension would pick up my credentials, even when visiting https://beta.protonmail.com/login.
With the 2.6.1 update I was only being presented the "No Matching Credentials" popup. I had to disable "Best Matching Credentials" in order to return to the functionality I was used to.

Works fine now that the option is disabled though 👍

[bennoonan92]

I have attempted the above and nothing has worked. I am on a macbook pro using firefox browser integration.
Changing https://fqdn -> https://fqdn/php/login.php didn't work and even tried adding a slash on the end of both configurations
Tried removing the "Return only best-matching credential" for all URL configurations no luck.
Looks like i'll have to roll back to 2.6.0 until this is fixed

[varjolintu]

@bennoonan92 You should roll back to 2.6.0 while waiting if nothing helps.

[veehexx]

same issue. started happening with 2.6.1 x64 (win10). 2.6.0 worked fine:

'return only best-matching credentials' is ticked with the above result. unticking this option allows the browser to find the correct creds.

keepass-xc browser is 1.6.6, browser firefox.

I havent updating my linux machines yet to see if it's OS specific.

[nniesen]

@varjolintu Disabling the "best-matching" also fixed my problem with the Entries "Browser Integration> Additional URL's" not working. With best-matching enabled, it prompts if you want to allow access for the additional sites but then never shows the entry for the site. So currently, best-matching must be disabled in order to use "Browser Integration> Additional URL's". It would be nice if there was a warning about that at a minimum but it would be better if best-match took the Additional URL's into account.

[varjolintu]

@nniesen Best-Matching with Additional URL's is also already fixed for the next release.

[BullShark]

This bug also affects me with Ungoogled Chromium and Icecat.

[bennoonan92]

@bennoonan92 You should roll back to 2.6.0 while waiting if nothing helps.
I did rollback but still having intermittent issues with it

[masi]

I'm also in the the camp that has been affected by the "fix".
Oddly enough I have the disable best match even when the URL does match exactly. Looking forward to the new version.

[timodenissen]

Regardless of setting the "best matching" option or using KeePassXC 2.6.0 or 2.6.1, Firefox fails to detect any credentials. When closing the database, the browser plugin detects this and gives me the correct message. When opening the database again I get no credentials, no "No credentials found" message... nothing.

Funnily, KeePassXC-Browser asks me to save new credentials (which are saved correctly!) and then fails to retrieve them but asks me again to save them, thus duplicating the exact entry. KeePassXC-Browser is set to save the whole URL, not just the domain.

KeePassXC - 2.6.1 (installed using the PPA)
KeePassXC-Browser - 1.7.0
Operating system: Linux x86_64 (Ubuntu 20.04)
Browser: Mozilla Firefox 80.0

Is there a simple way of testing a future version with the fix applied?

[varjolintu]

@timodenissen The fix is not yet merged, so no. If even 2.6.0 doesn't work, then I would like to see an example of an entry with a URL that doesn't work, plus your Browser Integration settings.

[timodenissen]

@varjolintu Annoyingly, the problem I had with github.com does not come up again :angry:...

I had the problem with https://github.com/login as URL entry. I'm currently using KeePassXC 2.6.1. Only problem(s) I now have are entries containing multiple URLs, but those are neglectable at the moment.

Because you asked for them, please find my browser settings attached.

keepassxc-browser_settings.json.txt

[timodenissen]

I found my culprit: I enabled "Match URL scheme" in the general browser integration settings, now everything works like a charm again, even the multi-URL entries (I just cross-checked the settings from my Ubuntu installation with my Arch installation).

[synergiator]

For me, URL wildcard is not working so that this bug applies (sometimes), too.

https://github.com/keepassxreboot/keepassxc/issues/5459

[Winter84]

I have also been having this problem (Firefox 80.0.1 on macOS 10.13.6 with KXC 2.6.1), though I guiltily confess I have not made a record of examples for you, but they include several sites that I use regularly. I do not have best-matching set, but I do have Match URL scheme set, if that is relevant.

One behaviour that I have noticed is that matching does not work when reopening KXC from the browser when already on the page where I want to fill in the credentials. If I hit login with no credentials, KXC will then recognize and fill the credentials properly.

[droidmonkey]

This has been fixed for 2.6.2