Kee shows a lot of wrong matches

Hi, I have two installations of Firefox 62.0 (at home on Windows 8 and at work on Windows 10) and Kee plugin. Both connected to the same Keepass DB which is synched via GoogleDrive and sharing settings using Mozilla’s account.
In one installation, at work, everything works well - kee shows only mathing items from keepass, but in another one, at home. recently is started showing 40+ “mathing” items only one of which is actually matching, the rest is completely irrelevant. This doesn’t happen for all sites, but does happen for some.
What could that be? Thanks.

image

P.S. Kee is a great plugin, thanks!

Do you definitely have only the one KeePass database open at home? Kee will by default look for matches in all databases - you can change this in the Kee settings if needed.

Are the URLs for the sites this affects exactly the same from both locations? E.g. there could be different ways to access the same work websites from inside the work network, the public internet or via a VPN.

Hi, yes, I use only one Keepass DB, it is password protected and always asking for a password, I provide only one password. The “matched” items except one, detected at home have nothing to do with the url.

Yes, the URL is the same. At work I receive one matching record from Kee for that URL.

What can I check in order to troubleshoot the problem?

Thanks.

1 Like

Note that Kee settings can’t be shared across machines so check if there are any differences in your settings that could explain this behaviour.

If that doesn’t help then enabling debug logging and inspecting the information in the browser console might provide some more clues.

Thanks, I’ll try to figure out what is wrong :slight_smile:

Unfortunately I didn’t find anything what could help me in the console log with debugging logging. It just shows a bunch if IDs which have different weights.
It feels like that at home, kee suggests all items for which the top level domain matches top level domain of the current page.
For example, if I’m trying to login at accounts.google.com and in Keepass I have items with domain names like console_developers_google_com (I couldn’t paste more than 2 links, so dots replaced with undescores) or console_cloud_google_com or just google_com - then Kee will show them all at my home laptop (I have 17 items which contain “google_com”), but not at the office.
Settings of Kee looks identical in both locations, I can’t find anything what would activate such behavior.

For example here is the debug log for the
accounts.google.com:

Finding matches in a document. readyState: interactive common.js:206:17
findMatches processing 2 forms common.js:197:17
about to get form fields common.js:197:17
domtype: email common.js:197:17
proccessing... common.js:197:17
domtype: hidden common.js:197:17
domtype: password common.js:197:17
proccessing... common.js:197:17
domtype: text common.js:197:17
proccessing... common.js:197:17
domtype: hidden common.js:197:17
usernameIndex: 0 common.js:197:17
actualUsernameIndex: 0 common.js:197:17
otherFields.length:2 common.js:197:17
about to get form fields common.js:197:17
domtype: hidden
common.js:197:17
usernameIndex: -1 common.js:197:17
actualUsernameIndex: 0 common.js:197:17
otherFields.length:0 common.js:197:17
no password field found in this form common.js:197:17
Submit handlers attached asynchronously to form 0 in 2ms common.js:206:17
Logging system initialised at Mon Sep 24 2018 23:41:58 GMT+0200 (W. Europe Daylight Time) common.js:206:17
scanForOrphanedFields took: 0 common.js:197:17
No forms found on this page. common.js:206:17
In browser content page script, received message from background script common.js:197:17
match found! common.js:206:17
formVisible: true common.js:197:17
Suitability of putting other field 0 into form field 0 (id: hiddenEmail) is 1 common.js:197:17
Suitability of putting other field 0 into form field 1 (id: ca) is 1 common.js:197:17
Suitability of putting password field 0 into form field 0 (id: ) is 36 common.js:197:17
formFieldCount: 3, loginFieldCount: 2, formMatchedFieldCount: 2, fieldMatchRatio: 0.6666666666666666 common.js:197:17
Relevance for F87B762B96BE0649A15E1C9E6DAE0305 is: 36.333333333333336 common.js:206:17
Higher relevance score found for login 0 with formIndex 0 () common.js:197:17
Suitability of putting other field 0 into form field 0 (id: hiddenEmail) is 1 common.js:197:17
Suitability of putting other field 0 into form field 1 (id: ca) is 1 common.js:197:17
Suitability of putting password field 0 into form field 0 (id: ) is 36 common.js:197:17
formFieldCount: 3, loginFieldCount: 2, formMatchedFieldCount: 2, fieldMatchRatio: 0.6666666666666666 common.js:197:17
Relevance for B6CDBAFDC0CC28419D4E2E9E0AB6D0C6 is: 16.333333333333332 common.js:206:17
Higher relevance score found for login 1 with formIndex 0 () common.js:197:17
Suitability of putting other field 0 into form field 0 (id: hiddenEmail) is 1 common.js:197:17
Suitability of putting other field 0 into form field 1 (id: ca) is 1 common.js:197:17
Suitability of putting password field 0 into form field 0 (id: ) is 36 common.js:197:17
formFieldCount: 3, loginFieldCount: 2, formMatchedFieldCount: 2, fieldMatchRatio: 0.6666666666666666 common.js:197:17
Relevance for A2E1A769BA8FB146A74135356ADB4AE9 is: 16.333333333333332 common.js:206:17
Higher relevance score found for login 2 with formIndex 0 () common.js:197:17
Suitability of putting other field 0 into form field 0 (id: hiddenEmail) is 1 common.js:197:17
Suitability of putting other field 0 into form field 1 (id: ca) is 1 common.js:197:17
Suitability of putting password field 0 into form field 0 (id: ) is 36 common.js:197:17
formFieldCount: 3, loginFieldCount: 2, formMatchedFieldCount: 2, fieldMatchRatio: 0.6666666666666666 common.js:197:17
Relevance for D65C256C87130D4AAAAAEA54ED305CA0 is: 36.333333333333336 common.js:206:17
Higher relevance score found for login 3 with formIndex 0 () common.js:197:17
Suitability of putting other field 0 into form field 0 (id: hiddenEmail) is 1 common.js:197:17
Suitability of putting other field 0 into form field 1 (id: ca) is 1 common.js:197:17
Suitability of putting password field 0 into form field 0 (id: ) is 36 common.js:197:17
formFieldCount: 3, loginFieldCount: 2, formMatchedFieldCount: 2, fieldMatchRatio: 0.6666666666666666 common.js:197:17
Relevance for 26DCD22371109546B91735E992FAB3E3 is: 36.333333333333336 common.js:206:17
Higher relevance score found for login 4 with formIndex 0 () common.js:197:17
Suitability of putting other field 0 into form field 0 (id: hiddenEmail) is 1 common.js:197:17
Suitability of putting other field 0 into form field 1 (id: ca) is 1 common.js:197:17
Suitability of putting password field 0 into form field 0 (id: ) is 36 common.js:197:17
formFieldCount: 3, loginFieldCount: 2, formMatchedFieldCount: 2, fieldMatchRatio: 0.6666666666666666 common.js:197:17
Relevance for 4EFF8B13F6B4774ABA0FCD83DE64AB1F is: 16.333333333333332 common.js:206:17
Higher relevance score found for login 5 with formIndex 0 () common.js:197:17
Suitability of putting other field 0 into form field 0 (id: hiddenEmail) is 1 common.js:197:17
Suitability of putting other field 0 into form field 1 (id: ca) is 1 common.js:197:17
Suitability of putting password field 0 into form field 0 (id: ) is 36 common.js:197:17
formFieldCount: 3, loginFieldCount: 2, formMatchedFieldCount: 2, fieldMatchRatio: 0.6666666666666666 common.js:197:17
Relevance for 0931F41A8B03824FBA672C9E5AFC29CC is: 16.333333333333332 common.js:206:17
Higher relevance score found for login 6 with formIndex 0 () common.js:197:17
Suitability of putting other field 0 into form field 0 (id: hiddenEmail) is 1 common.js:197:17
Suitability of putting other field 0 into form field 1 (id: ca) is 1 common.js:197:17
Suitability of putting password field 0 into form field 0 (id: ) is 36 common.js:197:17
formFieldCount: 3, loginFieldCount: 2, formMatchedFieldCount: 2, fieldMatchRatio: 0.6666666666666666 common.js:197:17
Relevance for 175860EFF266AB48864E286877F7AD89 is: 36.333333333333336 common.js:206:17
Higher relevance score found for login 7 with formIndex 0 () common.js:197:17
Suitability of putting other field 0 into form field 0 (id: hiddenEmail) is 1 common.js:197:17
Suitability of putting other field 0 into form field 1 (id: ca) is 1 common.js:197:17
Suitability of putting password field 0 into form field 0 (id: ) is 36 common.js:197:17
formFieldCount: 3, loginFieldCount: 2, formMatchedFieldCount: 2, fieldMatchRatio: 0.6666666666666666 common.js:197:17
Relevance for C9A4B1D651D6A648A0EA5AE210EA9541 is: 36.333333333333336 common.js:206:17
Higher relevance score found for login 8 with formIndex 0 () common.js:197:17
Suitability of putting other field 0 into form field 0 (id: hiddenEmail) is 1 common.js:197:17
Suitability of putting other field 0 into form field 1 (id: ca) is 1 common.js:197:17
Suitability of putting password field 0 into form field 0 (id: ) is 36 common.js:197:17
formFieldCount: 3, loginFieldCount: 2, formMatchedFieldCount: 2, fieldMatchRatio: 0.6666666666666666 common.js:197:17
Relevance for D3D051D4C8E0284AB3E955414019065C is: 16.333333333333332 common.js:206:17
Higher relevance score found for login 9 with formIndex 0 () common.js:197:17
Suitability of putting other field 0 into form field 0 (id: hiddenEmail) is 1 common.js:197:17
Suitability of putting other field 0 into form field 1 (id: ca) is 1 common.js:197:17
Suitability of putting password field 0 into form field 0 (id: ) is 36 common.js:197:17
formFieldCount: 3, loginFieldCount: 2, formMatchedFieldCount: 2, fieldMatchRatio: 0.6666666666666666 common.js:197:17
Relevance for 8B372531CC61274BBA1772210F9FAD07 is: 16.333333333333332 common.js:206:17
Higher relevance score found for login 10 with formIndex 0 () common.js:197:17
Suitability of putting other field 0 into form field 0 (id: hiddenEmail) is 1 common.js:197:17
Suitability of putting other field 0 into form field 1 (id: ca) is 1 common.js:197:17
Suitability of putting password field 0 into form field 0 (id: ) is 36 common.js:197:17
formFieldCount: 3, loginFieldCount: 2, formMatchedFieldCount: 2, fieldMatchRatio: 0.6666666666666666 common.js:197:17
Relevance for 7B4299516708C54781A5110BB2F789AE is: 16.333333333333332 common.js:206:17
Higher relevance score found for login 11 with formIndex 0 () common.js:197:17
Suitability of putting other field 0 into form field 0 (id: hiddenEmail) is 1 common.js:197:17
Suitability of putting other field 0 into form field 1 (id: ca) is 1 common.js:197:17
Suitability of putting password field 0 into form field 0 (id: ) is 36 common.js:197:17
formFieldCount: 3, loginFieldCount: 2, formMatchedFieldCount: 2, fieldMatchRatio: 0.6666666666666666 common.js:197:17
Relevance for 3C3F673C23CCBA42AD111E94FA13C519 is: 16.333333333333332 common.js:206:17
Higher relevance score found for login 12 with formIndex 0 () common.js:197:17
Suitability of putting other field 0 into form field 0 (id: hiddenEmail) is 1 common.js:197:17
Suitability of putting other field 0 into form field 1 (id: ca) is 1 common.js:197:17
Suitability of putting password field 0 into form field 0 (id: ) is 36 common.js:197:17
formFieldCount: 3, loginFieldCount: 2, formMatchedFieldCount: 2, fieldMatchRatio: 0.6666666666666666 common.js:197:17
Relevance for 390FD2463A09904F91AB2FAB16EB3652 is: 16.333333333333332 common.js:206:17
Higher relevance score found for login 13 with formIndex 0 () common.js:197:17
Suitability of putting other field 0 into form field 0 (id: hiddenEmail) is 1 common.js:197:17
Suitability of putting other field 0 into form field 1 (id: ca) is 1 common.js:197:17
Suitability of putting password field 0 into form field 0 (id: ) is 36 common.js:197:17
formFieldCount: 3, loginFieldCount: 2, formMatchedFieldCount: 2, fieldMatchRatio: 0.6666666666666666 common.js:197:17
Relevance for 0EA2B2AB45A90A4ABCB5AFF057D15418 is: 16.333333333333332 common.js:206:17
Higher relevance score found for login 14 with formIndex 0 () common.js:197:17
Suitability of putting other field 0 into form field 0 (id: hiddenEmail) is 1 common.js:197:17
Suitability of putting other field 0 into form field 1 (id: ca) is 1 common.js:197:17
Suitability of putting password field 0 into form field 0 (id: ) is 36 common.js:197:17
formFieldCount: 3, loginFieldCount: 2, formMatchedFieldCount: 2, fieldMatchRatio: 0.6666666666666666 common.js:197:17
Relevance for 5C5986D4488E2343A4347567579F5F92 is: 16.333333333333332 common.js:206:17
Higher relevance score found for login 15 with formIndex 0 () common.js:197:17
Suitability of putting other field 0 into form field 0 (id: hiddenEmail) is 1 common.js:197:17
Suitability of putting other field 0 into form field 1 (id: ca) is 1 common.js:197:17
Suitability of putting password field 0 into form field 0 (id: ) is 36 common.js:197:17
formFieldCount: 3, loginFieldCount: 2, formMatchedFieldCount: 2, fieldMatchRatio: 0.6666666666666666 common.js:197:17
Relevance for EF99BC9948161A438FC40FA231AE392F is: 16.333333333333332 common.js:206:17
Higher relevance score found for login 16 with formIndex 0 () common.js:197:17
Relevance of form 0 () is 36.333333333333336 common.js:197:17
fillAndSubmit started. automated: true, formIndex: undefined, loginIndex: undefined common.js:197:17
Relevance of form is 36.333333333333336 common.js:197:17
Relevance of form is 0 common.js:197:17
The most relevant form is #0 common.js:197:17
We are allowed to auto-fill this form. common.js:197:17
Multiple logins for form, so estimating most relevant. common.js:197:17
We think login 0 is most relevant. common.js:197:17
Automatic form fill complete.

I presume that the corresponding log at work lists a smaller number of relevance calculations? That just rules out a bug in the part of Kee that is rendering the matched results (though I find it hard to believe this wouldn’t have been noticed more widely).

The Kee setting to control domain-level or hostname-level matching (and options to override for specific domain names) is stored within each database (kdbx file) so your use of an identical kdbx file rules out any difference there… in theory, although I have a couple of long-shot ideas:

Has your Google Drive stopped syncing or begun using a different file name / location? E.g. DropBox sync will sometimes create duplicate files suffixed with “.conflicted” and Google did change their sync service substantially around the start of this year, requiring new software installation in some cases.

Do changes from one location result in KeePass performing its own Sync from time to time? kdbx files that have yet to be upgraded to the latest format (v4) can suffer from non-deterministic overwriting of all plugin custom data (such as the Kee Database Settings) so it is possible that if you’re not loading exactly the same bytes from disk and relying on the KeePass Sync feature, Kee Settings that you think you’ve changed in one place could fail to make it to the other location and/or get reverted to an older configuration.

I hope something here helps because I’m struggling to conceive of any way that Kee could be behaving differently in this way when the database file is always identical.

Hi, yeah at work I’m getting only 5 matches (all valid, I have multiple Google accounts), here is the corresponding log:

 Content Security Policy: Ignoring “'unsafe-inline'” within script-src or style-src: nonce-source or hash-source specified
Logging system initialised at Thu Sep 27 2018 23:21:48 GMT+0200 (W. Europe Daylight Time) common.js:206:17
scanForOrphanedFields took: 0 common.js:197:17
Finding matches in a document. readyState: interactive common.js:206:17
findMatches processing 2 forms common.js:197:17
about to get form fields common.js:197:17
domtype: email common.js:197:17
proccessing... common.js:197:17
domtype: hidden common.js:197:17
domtype: password common.js:197:17
proccessing... common.js:197:17
domtype: text common.js:197:17
proccessing... common.js:197:17
domtype: hidden common.js:197:17
usernameIndex: 0 common.js:197:17
actualUsernameIndex: 0 common.js:197:17
otherFields.length:2 common.js:197:17
about to get form fields common.js:197:17
domtype: hidden
common.js:197:17
usernameIndex: -1 common.js:197:17
actualUsernameIndex: 0 common.js:197:17
otherFields.length:0 common.js:197:17
no password field found in this form common.js:197:17
Submit handlers attached asynchronously to form 0 in 7ms common.js:206:17
Content Security Policy: Ignoring ‘x-frame-options’ because of ‘frame-ancestors’ directive.
Content Security Policy: Ignoring “'unsafe-inline'” within script-src or style-src: nonce-source or hash-source specified
Logging system initialised at Thu Sep 27 2018 23:21:48 GMT+0200 (W. Europe Daylight Time) common.js:206:17
scanForOrphanedFields took: 0 common.js:197:17
No forms found on this page. common.js:206:17
In browser content page script, received message from background script common.js:197:17
match found! common.js:206:17
formVisible: true common.js:197:17
Suitability of putting other field 0 into form field 0 (id: hiddenEmail) is 1 common.js:197:17
Suitability of putting other field 0 into form field 1 (id: ca) is 1 common.js:197:17
Suitability of putting password field 0 into form field 0 (id: ) is 76 common.js:197:17
formFieldCount: 3, loginFieldCount: 2, formMatchedFieldCount: 2, fieldMatchRatio: 0.6666666666666666 common.js:197:17
Relevance for F87B762B96BE0649A15E1C9E6DAE0305 is: 43 common.js:206:17
Higher relevance score found for login 0 with formIndex 0 () common.js:197:17
Suitability of putting other field 0 into form field 0 (id: hiddenEmail) is 1 common.js:197:17
Suitability of putting other field 0 into form field 1 (id: ca) is 1 common.js:197:17
Suitability of putting password field 0 into form field 0 (id: ) is 76 common.js:197:17
formFieldCount: 3, loginFieldCount: 2, formMatchedFieldCount: 2, fieldMatchRatio: 0.6666666666666666 common.js:197:17
Relevance for D65C256C87130D4AAAAAEA54ED305CA0 is: 43 common.js:206:17
Higher relevance score found for login 1 with formIndex 0 () common.js:197:17
Suitability of putting other field 0 into form field 0 (id: hiddenEmail) is 1 common.js:197:17
Suitability of putting other field 0 into form field 1 (id: ca) is 1 common.js:197:17
Suitability of putting password field 0 into form field 0 (id: ) is 76 common.js:197:17
formFieldCount: 3, loginFieldCount: 2, formMatchedFieldCount: 2, fieldMatchRatio: 0.6666666666666666 common.js:197:17
Relevance for 26DCD22371109546B91735E992FAB3E3 is: 43 common.js:206:17
Higher relevance score found for login 2 with formIndex 0 () common.js:197:17
Suitability of putting other field 0 into form field 0 (id: hiddenEmail) is 1 common.js:197:17
Suitability of putting other field 0 into form field 1 (id: ca) is 1 common.js:197:17
Suitability of putting password field 0 into form field 0 (id: ) is 76 common.js:197:17
formFieldCount: 3, loginFieldCount: 2, formMatchedFieldCount: 2, fieldMatchRatio: 0.6666666666666666 common.js:197:17
Relevance for 175860EFF266AB48864E286877F7AD89 is: 43 common.js:206:17
Higher relevance score found for login 3 with formIndex 0 () common.js:197:17
Suitability of putting other field 0 into form field 0 (id: hiddenEmail) is 1 common.js:197:17
Suitability of putting other field 0 into form field 1 (id: ca) is 1 common.js:197:17
Suitability of putting password field 0 into form field 0 (id: ) is 76 common.js:197:17
formFieldCount: 3, loginFieldCount: 2, formMatchedFieldCount: 2, fieldMatchRatio: 0.6666666666666666 common.js:197:17
Relevance for C9A4B1D651D6A648A0EA5AE210EA9541 is: 43 common.js:206:17
Higher relevance score found for login 4 with formIndex 0 () common.js:197:17
Relevance of form 0 () is 43 common.js:197:17
fillAndSubmit started. automated: true, formIndex: undefined, loginIndex: undefined common.js:197:17
Relevance of form is 43 common.js:197:17
Relevance of form is 0 common.js:197:17
The most relevant form is #0 common.js:197:17
We are allowed to auto-fill this form. common.js:197:17
Multiple logins for form, so estimating most relevant. common.js:197:17
We think login 0 is most relevant. common.js:197:17
Automatic form fill complete. common.js:197:17

I’m using Google Sync plugin in Keepass to synchronize the database, the file is not synchronized by GoogleDrive (Google Backup and Sync) to my laptops, it is always in the cloud and synced only via the plugin.

  • I did search just now for domain “accounts.google_com” in keepass at home and at work - in both cases 8 items were found (3 items marked as “hidden” so they are not shown in kee at work).
  • If I do search for “accounts.google_com” in Kee, at home, it shows me only 5 items (and that is correct), but autosearch for the field shows 17 matches.
  • If I do search for “google_com” in Keepass, it will return me 20 records at home and at work. 3 of them are hidden from Kee.
  • If I search for “google_com” in Kee, it will show me exactly 17 matches (20-3) which corresponds with number displayed on the screenshot.

What could be a reason for Kee to use google.com instead of full domain account.google.com for search at home? I didn’t configure any specific settings for google in Kee, but perhaps something went wrong. Is there a way to see for which sites regexp is used in Kee?

Thanks a lot for trying to help.

I think that you could have your database configured to search for domain matches (which is the default) but on one system, KeePassRPC is unable to determine what the domain name for each website is.

To do this, it needs to download the relevant data from the Public Suffix List service (and store it on disk for later use). If it can never connect to the internet to collect this data, it will have to fall back to hostname matching which in some cases (such as the accounts.google.com example) will result in fewer matches.

If you never want domain matching to work, make sure your database is configured for hostname matching. If you want it to work (even if only on some domains) you’ll need to find out why your system is preventing the download and/or storage of the PSL data.

Hi,
Thank you luckyrat :slight_smile:

I’ve copied Keepass from work, result is still the same.

Is it possible to change the default search mode in v 1.7.3 of KeePAssRPC or shall I install the latest version for that (all test before I did with the latest version of KeePassRPC)?
Where does the app store the PSL data? Perhaps I can clean it somehow?

Thank you.

No. That feature was added in 1.8.

There’s no easy answer for that but in most cases it would be in your Windows user account’s AppData folder. The full algorithm for selecting the location can be seen in the source code linked to below but probably you just need to fix the Windows folder permissions for your user account.

That wouldn’t be necessary - KeePassRPC automatically overwrites it if the file can’t be read or is quite old. The only exception to that I can think of is if you (or more likely some malfunctioning security software) has corrupted the permissions of the file KeePassRPC created such that it is no longer able to read or write it even though it was possible to create it in the first place… but that is going to be a very rare occurrence and I’d be surprised if it’s ever happened to anyone yet.

com-example

C:\Users\user\AppData\Roaming\KeePass\publicSuffixDomainCache.txt
does not contain the word zendesk.

I have numerous *.zendesk.com usernames and passwords. Even though “Hostname: The URL must match the hostname (domain and subdomains) and port.” is checked for each and every *.zendesk.com record, all of them show for each other. Hostname is totally ignored.

So i appended zendesk.com to the end of publicSuffixDomainCache.txt and now hostname works. Wondering if i could get that file to sync with dropbox so all my machines have the same set of domains. Or better yet, maybe keepass app trigger to add my custom file to their file, so it loads both.

I’m not really seeing how that behaviour can happen but don’t have much time to investigate in detail right now. Are you sure that you do not have an override for zendesk.com in your database settings to force it to match on domains? Do you have any alternative URLs listed for these entries?

Adding zendesk.com to the PSL will have the effect of meaning that every subdomain is treated as a top-level domain instead so one would expect the matching accuracy to change only if the configuration being applied to each entry is “Domain” rather than “Hostname”.

If you do choose to continue manipulating the PSL cache then be aware that KeePassRPC will overwrite it from time to time in order to keep it up to date with the latest standardised way for determining what part of a hostname is a domain.

I do not have any entries in the KeePass portion of database settings. It is set to Domain with no overrides. That would probably be a better place, but do not believe that worked either. I will try to look at the tutorials again. Currently, it is working great with zendesk.com added to that file.

All of the different *.ZenDesk.com entries were changed back to domain after adding zendesk.com as a tld.

Are domain names case sensitive? I know our untangle gateway is case sensitive when uppercase letters are used in the pattern.

image

well ,actually there is no publicSuffixDomainCache.txt in Users\user\AppData\Roaming\KeePass
actually even KeePass folder is not existed. and i tried to run keepass2 as admin,still the same , no files create.
both of my windows os missing files ,but my linux os works well ,i suppose win10 1809 update break something

edit:download the list manully fixed my issue,but still dont know why keepass2 cannot download it autolly

KeePassRPC 1.9 includes a fix for an issue that meant the database default configuration did not always apply to the match accuracy of an entry, which may be at least a part of what is causing confusion here. I’ve also created a new documentation page that discusses what goes wrong when the PSL can’t be used, including an edge case where per-site URL overrides can’t take effect - again, that might explain some issues being described here but there are definitely some pieces of the puzzle still missing.

I’ve also combined some existing information about minimum URL matching, updated it and posted it in a new documentation topic.

I’m afraid that after days of investigation, I still can’t explain all of the behaviour described in this and similar topics but I think the time has come to draw a line under this topic because it already contains a variety of related but different issues so I’m closing it now.

After you upgrade to Kee 3.1 and KeePassRPC 1.9 please check if you still see match behaviour that can’t be explained by the new documentation and post a new topic with detailed information about what system, database and entry configuration you have, what is going wrong and what you expect to happen.