Autofill: Recognize distinct hyphenated domain names

[JJohnGreenSr]

Describe the bug
Not sure if I worded the title right, but whenever I log in to my Microsoft Outlook email, I'm sent to login.live.com. But KeePassDX also lists accounts for forums.nba-live.com (a site for basketball discussion)

To Reproduce
Steps to reproduce the behavior:

1. Have an account for login.live.com
2. Have an account for forums.nba-live.com
3. Go to outlook.com
4. Tap sign in button, which redirects you to login.live.com
5. Tap Sign in via KeePassDX button on keyboard
6. Unlock database
7. Both account entries should be listed on autofill

Expected behavior
Only the one for login.live.com should be listed on the autofill section of my keyboard.

KeePass Database

• Created with: KeePass 2 (looking at settings)
• Version: KDBX 4.0
• Location: Remote file retrieved with Nextcloud app
• Size: Maximum size 6 MiB
• Contains attachment: No

KeePassDX (please complete the following information):

• Version: 2.10.5
• Build: libre
• Language: English

Android (please complete the following information):

• Device: Galaxy A11
• Version: 11

Additional context
Add any other context about the problem here.

• Browser for Autofill: Brave 1.29.79, Chromium 93.0.4577.63

[J-Jamet]

KeePassDX cannot guess that credentials from one domain are running on another domain. You just have to fill a new custom field in the basketball site entry, to add login.live.com.

[uduerholz]

I guess what happens here is the following:
Subdomain search is not enabled per default.
When you open a URL with a domain *.live.com the autosearch for the autofill will search the database for entries that contain the string "live.com" in either the URL, title or notes:

return stringToCheck.isNotEmpty() && stringToCheck.contains( searchParameters.searchQuery, true)

So an entry with URL "forums.nba-live.com" will also match.

[uduerholz]

@J-Jamet Did you read my comment? What do you think?

[J-Jamet]

Yes you're right, I got the problem backwards.

[J-Jamet]

My first idea to solve this problem is to add a "." to search as a prefix, but it won't work if there is no subdomain. So I think it's better to leave the current behavior, just select the right domain when clicking. Unless you have another idea for fixing this bug.

[uduerholz]

I had a look at the code last week and was a bit surprised how much effort is made to determine the "public suffix" of the domain (which is not necessarily the top level domain, e.g. co.uk is a public suffix).
What if only the complete domain name is considered a match, no matter if a sub domain is present or not?
Why is it the default that subdomains are disregarded in the search?

[J-Jamet]

I don't have the whole subject in mind anymore but I know that it solves specific problems, I had done many tests.

In one case there will be URL redirection, in other cases not, so for example if you register a url with www and the next time you go to the same site without www, it will not work. I also know that websites use subdomains only for login. (Same thing for mobile version .m if a database is shared with a desktop version). Some sites even use lots of subdomains to handle large-scale simultaneous connections, so it won't be the same subdomain for every login.
So it requires the user to register all login URLs, which would be horrible.
but without searching for the subdomain, it makes things much easier for the user.
Unfortunately, there will always be special cases.

Link #1044 #728 #584 #614

[uduerholz]

I see, so probably it's better to leave it as it is.

[JJohnGreenSr]

I know that's often the case for subdomains with periods (for example en.m.wikipedia.org has the same login and domain as en.wikipedia.org), but I don't think that applies to hyphens. live.com and nba-live.com are completely separate domains with separate ownership and Whois registrations ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

…

On Thursday, September 23rd, 2021 at 3:20 AM, Uli ***@***.***> wrote: I see, so probably it's better to leave it as it is. — You are receiving this because you authored the thread. Reply to this email directly, [view it on GitHub](#1105 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AQ7LBTFFE4QQM73TDWFUYOTUDIUARANCNFSM5EAGN3NA). Triage notifications on the go with GitHub Mobile for [iOS](https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675) or [Android](https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub).

[J-Jamet]

We can manually see that they are different domains in your case, but the search doesn't know that since "live.com" is searched and I don't see a method to solve this problem without breaking something else.

[zinalili]

J-Jamet, could you add an option to only look up matches in URL section for autofill suggestions?

[J-Jamet]

I have found a satisfactory solution, the idea is to check the URL field of the entry if :

• It is rigorously exact to the domain (ie: domain.org)
• It's a string that ends in the domain with a “.”, which indicates a sub-domain (ie: subdomain.domain.org)
• It's a string that ends in the domain with a “/”, meaning that the protocol is present. (ie: https;//domain.org)
• Other domains containing the domain name are not checked. (ie: myootherdomain.org)

This will be in the next release. Please let me know if you see any regressions with your URLs.

[J-Jamet]

Please retest with version 4.1.0 and let me know if the problem has been solved.

[cbiere]

Feel free to merge this with issue #1820 because it's the same, maybe just seen from a different angle. I hadn't realised how old this issue was. Wow. This is a big problem because it makes phishing way easier. Also as I have mentioned in #1820 this was not fixed correctly. At the moment, most of my entries don't match at all regardless of the setting "subdomain" search. It seems to work if the login is on the www subdomain.

[J-Jamet]

Actually, this issue is fixed but not the #1820. I thought it would solve both at the same time, but no.