keepassxc will tell me no exact record match.
keepassxc return many record with this Domain, not only the exact matched.
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.
open https://vhost.test.test/phpmyadmin/)
keepassxc will display many record with https://vhost.test.test/ not only the exact matched.
KeePassXC - 2.5.2
Revision: 8e76c30
Operating system: Manjaro-Stable
CPU architecture: x86_64
Kernel: 5.4
Enabled extensions:
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*.localhostor*.yourcompany-devel.comtype 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.
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
*.localhostor*.yourcompany-devel.comtype services.This issue needs to be pinned.