Site Preferences need exact domain matches, can't automatically match subdomains

[e-t-l]

Expected Behavior

If I create a Site Preference to disable all features for "https://example.com", I expect features to be disabled for https://www.example.com, https://subdomain.example.com, and https://example.com/ page

Current Behavior

Individual subdomains have to be specified in separate rules. Also, pages of a domain only get matches if the site preference entry is "https://example.com/*" (with an asterisk wildcard). The asterisk should not be required.

Possible Solution

Make it so entries that specify a subdomain should apply only to that subdomain, but entries that specify just the domain should apply to all subdomains (aka "https://example.com" === "https://*.example.com" which is the current behavior of the KeePassXC app itself).

Debug info

KeePassXC - 2.7.9
KeePassXC-Browser - 1.9.3
Operating system: Windows
Browser: Firefox

[droidmonkey]

You usually want exceptions to be as minimal as possible. As you mentioned, you can add asterisks when needed to make them broader. The current behavior is the desired behavior, imo.

[e-t-l]

Except asterisks don't work for sub domains. Entering "http;//*.example.com" returns an error. Maybe your reasoning would hold water if wildcards were properly supported.

But when would someone even want to change the behavior of this extension on a website but not any of the subpages of that website? I can think of plenty of instances that the opposite is true: The login flow for "https://example.com" frequently looks like "https://example.com/signin" > "https://secure.example.com/redir_landing" > "https://secure.auth.example.com/signin/credentials" > "https://secure.auth2.example.com/signin/twofactor". If I don't want KPXC to autofill my credentials for example.com, why in the world would I ever want it to autofill on any of its subpages?

[droidmonkey]

Then the behavior of the wildcard needs to be fixed...

[varjolintu]

Thee KeePassXC's behavior differs only because it doesn't support wildcards by default. The feature is coming though.

And settings the Site Preferences to https://*.example.com actuall works on Chromium based browsers. Firefox handles the situation differently, and there's an open issue about it: #1612

[e-t-l]

That's good to know - and I didn't realize it was broken on Firefox. The wildcard thing was really a secondary bug I noticed when making this issue. I still contend that subdomains and paths of a website could be included by default without needing the asterisks, but I guess if the majority consensus is to rely on wildcards, then fixing #1612 would be sufficient.