Keepassxc: URL-Exact-Match didnt work in 2.5.2

Created on 20 Dec 2019  路  14Comments  路  Source: keepassxreboot/keepassxc

Expected Behavior

keepassxc will tell me no exact record match.

Current Behavior

keepassxc return many record with this Domain, not only the exact matched.

Possible Solution

Keepassxc 2.5.0 don't have this bug, but 2.5.2 and 2.5.1 have.
I think its url match algorithm have some problem.
I hope keepassxc can match the entire url including port, subdomain and path.

Steps to Reproduce

open https://vhost.test.test/phpmyadmin/)
keepassxc will display many record with https://vhost.test.test/ not only the exact matched.

Debug Info

KeePassXC - 2.5.2
Revision: 8e76c30

Operating system: Manjaro-Stable
CPU architecture: x86_64
Kernel: 5.4

Enabled extensions:

  • Browser Integration
bug Browser integration

Most helpful comment

This also bloats the DB by populating a bunch of unnecessary sites into "deny" field of browser settings every time "deny & remember" is clicked. No easy way to undo that either.
This is also quite a trouble-maker for anyone's workflow when dealing with many *.localhost or *.yourcompany-devel.com type services.
This issue needs to be pinned.

All 14 comments

Have you enabled the "Return only best-matched credentials" from KeePassXC's Browser Integration settings?

(for Version 2.5.1 on Fedora) Yes, i tried this setting, with no succes. Also with URL scheme setting and with sorting. Add: I can use browser integration only with proxy connection.

Have you enabled the "Return only best-matched credentials" from KeePassXC's Browser Integration settings?

Of course. Its enabled. Ok, hm... weird... I use 2 databases simultaneously with "search in all opened database" enabled. Maybe this?

@Anagastes That might be it. Now it returns best-matching from both.

@RobTranquillo This is broken with 2.5.1.

No, the problem (on V2.5.1) is not connected with multiple databases. But with multiple entrys. If a url is multiple times in the DB it returns all DB entrys (or a huge number of).

But, I use now 2.5.2 snapshot and I still have that bug. :S

I took another look. I have the following entry in the 1st database.

https://vhost.test.test/phpmyadmin/
https://vhost.test.test

In the 2nd one this
https://test.test

Does that lead to this, perhaps? But the second entry is not loaded anymore (exact match works here)

@RobTranquillo 2.5.1 is broken. Still.

@Anagastes That should return the 1st and 3rd entry (from the 2nd db).

This also bloats the DB by populating a bunch of unnecessary sites into "deny" field of browser settings every time "deny & remember" is clicked. No easy way to undo that either.
This is also quite a trouble-maker for anyone's workflow when dealing with many *.localhost or *.yourcompany-devel.com type services.
This issue needs to be pinned.

This also bloats the DB by populating a bunch of unnecessary sites into "deny" field of browser settings every time "deny & remember" is clicked. No easy way to undo that either.
This is also quite a trouble-maker for anyone's workflow when dealing with many *.localhost or *.yourcompany-devel.com type services.
This issue needs to be pinned.

Yeah, finally someone who understands that. In a productive environment with many such domains, this is especially bad!

I would gladly change the Allow/Deny permission to include subdomains instead of the main domain.

I would gladly change the Allow/Deny permission to include subdomains instead of the main domain.

@varjolintu That would be very nice to have a setting like that, e.g. similar to existing Match URL scheme (e.g., https://...) to have another Match subdomains (e.g., mail.yourcompany.com)
Currently, Return only best-matching credentials does that, but due to complexity of "best-matching" definition, it causes confusion (and possibly lead to this bug as well?)

The interface for confirming/denying/always denying credentials was revamped in 2.6.0 to address these problems.

The interface for confirming/denying/always denying credentials was revamped in 2.6.0 to address these problems.

Unfortunately this is not yet a complete solution.

If you select "disable for this page" in the new field. Sub-URLs no longer work.

One entry serves this domain

https://sub.domain.de/phpmyadmin

If you selected "deactivate for this page". Both no longer work.

https://sub.domain.de
https://sub.domain.de/phpmyadmin/

However, the last URL should be served.

Totally unrelated to the dialog. If you disable access to the DOMAIN no path under that domain will match. That is by design.

Was this page helpful?
0 / 5 - 0 ratings