Filter Autofill search results

[thgoebel]

Is your feature request related to a problem? Please describe.
KeePassXC allows having more than one web domain associated with a single entry. They do that by storing those additional URLs as custom attributes that have keys of this form:
KP2A_URL, KP2A_URL_1, KP2A_URL_2, ..., KP2A_URL_n

Describe the solution you'd like
Please consider trying to parse those additional attributes as well when resolving entries for a given domain.

Describe alternatives you've considered
Ignore them, as those attribute keys are not standardised (as far as I know).

Additional context
In my case: my university login can be used in tons of different places, so I have over eight URLs for that entry.
KeePassXC added this in v2.5.0 with this PR.

[J-Jamet]

Normally, the autofill search parser looks at all the fields, so it should work.
Research does not look at the label, as you say, it is not standardized ...
The search offers a maximum of 6 entries, but it should still work. Can you upload a sample database?
Are you using version 2.5RC1?

[thgoebel]

Ooops, yes 2.5RC1, sorry for not stating that. Lineage 16, OnePlus 5.

Ah, I didn't know about the entry limit of 6.
I tested again with another domain for which I only have two entries and it works as expected there.

Then my issue is something different:

KeePassDX matches parts of domains in the "user" field. This leads to entries being suggested where they needn't be.
In my case, I am registered with my uni address [email protected] at lots of different services. All of them are being suggested when I want to login on ethz.ch itself, but not the entry for ethz.ch!

Example database: keepassdx-test.zip
(created with KeePassXC 2.5.4, zipped because GitHub want me to, password is password)

Screenshots:

This is with KeePassDX 2.5RC1 on an OnePlus 7, OxygenOS 10.0.4 in Firefox Preview 4.2.1

To reproduce:

0. Install KeePassDX, enable autofill service
1. Open https://ethz.ch/login/en.html
2. Select KeePassDX, unlock
3. Be prompted with 6 different entries - non of which have URL or KPA2_URL fields set for the pure ethz.ch domain. The expected entry (titled "Main") is not shown.

I see that this behaviour can be useful if the user hasn't set the URL field.
However in cases where you use your organisational account to signup elsewhere it would make sense to not parse the user field. Or maybe do, but give lower priority to entries that only match in the user field?

[thgoebel]

Dunno if I should rename this issue and continue discussion here, or open a new one. You decide :)

[J-Jamet]

Thank you for your detailed feedback. We can continue here it is not annoying.
Google recommends a limit between 5 and 10 items for Autofill.
Here we have two solutions for the issue:

1. filter the searches

• to not process usernames (maybe by setting).
• or we can manually define the fields to search (it requires a lot more work)

2. add a 7th element which would allow manual selection.

It is also possible to add both options. I think it is best to implement the 1.1 solution and add the second solution in a second step.
What do you think?

[thgoebel]

1.1))

I agree that ignoring the user field would make the most sense for now.

Leaving the URL field empty and relying on the user field to match a website/app does not seem like a sensible use case to me. The user field is semantically just not an website identifier. Don't be so lazy, just fill out the URL field.

Given that the user field is guaranteed to be there (correct me if I'm wrong) ignoring it should be safe, shouldn't it?

Whether by setting or not: I can't think of any argument for or against specific to this case. Generally I tend to value sensible defaults over a plethora of settings, but I know that many people in the FOSS world like to be able to customise everything. (tldr: no setting)

1.2))

Manually whitelisting fields to search does indeed sound like quite a rabbit hole, I wouldn't go there.
Unless more people complain I would leave it at excluding just user names. Only if other valid cases crop up expose it as a fully customisable blacklist.

2))

Would be good a catch-all solution for other future cases where the parsing doesn't work as expected.

[J-Jamet]

Given that the user field is guaranteed to be there (correct me if I'm wrong) ignoring it should be safe, shouldn't it?

No, the user field may be empty, this is not a problem. No setting is ok for me too. I will see if a special case arrives.

So I'm going to develop the solution 1.1