You should be able to simply omit the subdomain that varies. For example:

https://amazon.com matches https://sub1.amazon.com and https://sub2.amazon.com
https://sub1.amazon.com matches https://sub2.sub1.amazon.com

At least that is the expected behavior. Either way, I support the asterisk wildcard, but not full on regex.

I already have a WIP branch supporting wildcards, but haven't had time to make it any further. But it's coming eventually.

@droidmonkey it looks like you are right - after I restarted the application, the matching worked as you indicated. I'm not sure why it didn't work right from the get-go...

¯\(°_o)/¯

I can confirm that using URLs without subdomain and without asterix works. This is a new behavior, as in older Versions the asterix was needed.

Keeping this open for wildcard support

Hi everybody,

I hope you on't mind me using this issue to place a question or two rather than opening a new issue. Is there a user forum somewhere?

I'm trying to familiarize myself with KeepassXC. I'm managing some 1200 website accounts and my problem is that each domain has different login pages (URLs) for different purposes and thus, of course, different login data. So I think this is kind of the opposite of what has been described above.

Example - 1 domain with 4 different login pages:

https://mydomain.com/login
https://mydomain.com/admin/login
https://mydomain.com/admin/install
https://mydomain.com/symfony-manager.php#packages

What's the best practice, if I want to login to the admin page without getting at least 3 more login suggestions? It seems to me that KeepassXC(-Browser) is listing all entries containing the domain "mydomain.com" instead of the matching string of the complete URL. It is even listing DB entries with other domain names if "mydomain.com" is contained in the username field as part of an email address.

Secondly KeepassXC should ignore fields on certain pages like

https://domainname.com/admin/main/user?edit=[...]

where user data of customer accounts are edited.

I've been using Acebit's Password Depot for at least decade, being used to work with wildcards in URLs as well as ignore-URLs. In the Wiki I read that regex can be used with page titles, but that doesn't seem to work, and since titles aren't unique and may change more often than URLs I'd prefer working with URLs. I'd very much appreciate any help to get ajusted to KeepassXC, that seems to be fast and looks very neat.

Regards,
Anke

@Anke This was a bug with KeePassXC 2.5.1. It's already fixed for 2.5.2.

Hi,
sorry, i'm new @github. I hope, you can help me. I tried to wildcard a website, but it won't function with keepass xc browser (firefox). I typed in "https://.test.de". Do you know, why this won't functions?

Thanks and kind regards,
Stefan

@Meza100 If you want to use a dummy wildcard feature, use https://test.de as the entry URL. It will match https://*.test.de.

EDIT: Just like an entry URL https://test.test.de will match https://*.test.text.de.

@varjolintu Thanks! But now I see, that my message was not complete. I have multiple sites, which has the same structure like https://placeholder.test-placeholder.de/

Is there a way for this? I know, that this sounds curious, but I can't change the password, so I thought, that I can make an entry for these websites in my database. Do you have a suggestion?

@Meza100 I'm not 100% sure what you mean, but you should use only that URL for the entries you want to use with that subdomain.

@varjolintu Thanks, so I will make different entries for each URL.

Maybe this is closer to regex support, but I'd like to see something like the following supported.

https://foo.*.bar.com that would be a closer match than bar.com. (though I suppose both would display in the dropdown.

bulk editing of additional URL would be nice too (I could just add all hundred or so hostnames I guess).

Unfortunately the need for an inner wildcard is very niche as most websites and scenarios do not require that amount of specificity. Having a second level subdomain remain constant when the first level varies is rather rare.

That's why I think generic regex could be the 'one-size fits all' solution

I disagree, @droidmonkey. The non-existent or difficult wildcard use is why I switched back to another password manager. Especially in times of dynamic webpages imho a comfortable wildcard handling is essential, not only for web developers and designers. I think that most people missing it just come to terms with the way things are.

FYI: I already have an experimental local branch for this kind of feature, which I will continue when I have the time. It only supports the * wildcard.

Great to hear, thank you! I'll be patient. Would you let us know here, when it's ready to use?

@Anke Yes of course. But don't expect it soon.

I've been looking for documentation on how to achieve such a wildcard match for URLs and in this issue I learned that subdomain wildcard matching is automatic. I also learned that apparently you can specify multiple URLs, but the exact method isn't mentioned. Could I request adding both of this as documentation on https://github.com/keepassxreboot/keepassxc/wiki, which was the first place I looked at?

Context: I'm using keepassxc-browser.

For the benefit of others wanting alternative URLs for an entry (as mentioned by @FichteFoll), I had success in version 2.5.4 by copying the process shown in the Screenshots heading here:

#3558 (comment)

Namely, defining an Additional attribute named KPA2_URL_1 containing the URL under the Advanced section for the entry. Additional URLs can be configured with KPA2_URL_2, KPA2_URL_3 etc. (see the PR comment for better instructions).

You can't put a regex in there but you can use a subdomain to widen the net.

Just use the gui interface that was introduced in that pr!

We have decided that wildcards are unnecessary with the current implementation.

I think they are necessary. For instance, at work we have all the testing sites at say, *.playdev.net, but depending on which part of the project we are testing (frontend or backend), the URLs become:

• portal-*.playdev.net
• backend-*.playdev.net
  both set of sites having a separate user-base (because they are for testing purposes)

but... I used the star (*) on the URLs because depending on the release we are testing, the infrastructure team adds the version to that url, getting, for instance:

• portal-v440.playdev.net which has the same users-base of portal-v441.playdev.net

which have a separate users-base than:

• backend-v440.playdev.net which has the same users-base of backend-v441.playdev.net

so, everything within portal-*.playdev.net share the same users and passwords, and everything within backend-*.playdev.net share the same users and passwords; but no user/password is shared between portal and backend.

Adding only user for https://playdev.net will share on KeePassXC users for both portal and backend, which are separate in practice. I would need both entries on KeePassXC, but a wildcard to match any future version that arises.

We'll take another look. This will complicate "return best matching credentials" but otherwise not difficult.

FWIW, I came here looking for wildcards because my additional URL was not being used for subdomains. Restarting KeePassXP caused it to start matching, as described above.

I think I run into this issue using AWS services which have a sub-domain for each region's login. This means anytime I have a different region cached I get prompted to allow access to this new url. That event is easy to miss and can cause confusion. I create an entry, set its url to "https://aws.amazon.com", then navigate to one of the login pages (ie. us-east-1.signin.aws.amazon.com). So, it picks up that subdomains should probably match, but I would prefer if I could just auto-allow subdomains. The app currently appends to entry/properties/"KeePassXC-Browser Settings" with some json in there with several entries under allow.

Let me know if this is the right issue or if I am missing some feature I should be leveraging 😺 .

Heres my 2 most annoying cases currently, where it would be great to have a wildcard in the TLD:

• Amazon uses the same account on at least .com, .de, .se (and i would assume all tlds they have). curretly i have to use copy&paste for logging in to .se or my aws-console on .com, since keepass is configured with the .de TLD.
• In another service i use, you log in on your local tld (eg. co.uk) for trading and .com for your profile settings.

Just add the other tld domains as additional urls. Do this in the browser integration section of editing an entry.

Can we exclude a certain subdomain? Something like

!sub2.example.com,example.com

which matches example.com and sub1.example.com, but not sub2.example.com.

You can deny the subdomain access through the browser access confirmation. This is a long as you haven't allowed it for all sub domains already.

Plus one

Hello,
I have another use-case for it. I manage a lot of IoT devices. All are on a subnet with dhcp, so they get an ip in a range like 10.11.x.x. Each has the same password. So I'd like to add a wildcard entry in my password manager with http://10.11.*

Same issue here, I create some ephemary webapps, calling them using their random IP which are in a specific range.
A wildcard support would be nice in this special case: https://172.x.x.*

You can deny the subdomain access through the browser access confirmation. This is a long as you haven't allowed it for all sub domains already.

That's kind of annoying if you only want to have a few subdomains where it should match and some where it shouldn't. Automatically using subdomains when you have https:// in front is kind of unintuitive. I would have expected this if you did example.com to maybe match subdomain.example.com but with https://example.com the https:// implies that there's nothing to be added between protocol and domain, if that's understandable.

I suggest changing the current behaviour to only include subdomains if you added an asterisk somewhere, as this is expected by the user coming from other software doing partial matching. Another reason to do this is that a URL is a Uniform Resource Locator, meaning that there's not really a concept of a "sub URL" other than adding some path at the end. So calling the field "URL" while actually matching the domain (and potentially subdomain) is misleading. Maybe there could be a help text with a small ⓘ next to the "URL" label or a dotted underline of the label where there's a tooltip when you hover which explains the possibilities of the field?

I too have the case where I have domain names starting with contoso-srv-00123.example.com where I want to use user A, but contoso-test-00123.example.com with another user, kind of like baco explained. However, there might also be a case where I don't want to match contoso-srv-00111.example.com which means I would have to enter this as an exception. The IP example by nmenetrier is another one which would be handy.

This is the only feature I am missing since switching from keepass2 to keepassxc. As I use it also for work where we have various servers e.g. test1.projectA.company.com, test2.projectB.company.com and so on which use all the same test logins.

Minimalistic wildcard support would be usable, but regex support (which would include negation and so on) would be appreciated.

Best regards

@uhausbrand Your situation could be solved by just using https://company.com as the entry URL. It works similar to https://*.company.com.

@uhausbrand Your situation could be solved by just using https://company.com as the entry URL. It works similar to https://*.company.com.

But this would make all logins visible for all projects. And no, I don't view the deny login dialog as a viable solution.

so, everything within portal-*.playdev.net share the same users and passwords, and everything within backend-*.playdev.net share the same users and passwords; but no user/password is shared between portal and backend.

backend-*.playdev.net

Especially if you manage many servers with IPMI interfaces, *-ipmi could be a very useful pattern to have.

I also upvote this as having multiple IoT devices configured and addressing them by IP addresses would require me to generate alternative URL for each IP possible which is really cumbersome and wastes a bit of space...

I hear you. I'm about to improve things for KeePassXC 2.8.0.

I hear you. I'm about to improve things for KeePassXC 2.8.0.

That would be much appreciated! ❤️

FWIW, another use case is to use the same credentials on the “same” website across multiple countries, e.g., amazon.{com, co.uk, de, etc.}.

I hear you. I'm about to improve things for KeePassXC 2.8.0.

Thank you.

I hear you. I'm about to improve things for KeePassXC 2.8.0.

Thanks! It's been some time since the comment, but its the most awaited feature for me. 👍🏻

See #9835 for a draft PR if you wish to test the feature.

Don't forget the ports, nobody mentioned the ports!...

I can think of half a dozen sites where this would be the regex that would match a login and still fail because of popup windows. e.g.
https?//(www|portal|login)\.site\.(co\.uk|com|org):(443|80|808[0-9])/(login|blog|gallery|support)/((login|timeout)|\.*)
In fact I find that sites that "just work" are the exception....

What about those poor folks stuck with organisations that still think outbound proxies are a good idea and/or the operators that are unaware reverse proxies exist. Then you add the sites that try and make things "restful" and hence have multiple synonyms for login....

Currently what happens is that you can't login and have to fail usually locking yourself out. All this an you and up auto typing a password you don't recognise maybe into a site other than one you wanted.

More than just regex, or other wildcards, I would say that the user flow needs to be better.
If there is no match, rather than just an uninformative "no match" message. Instead, make a fuzzy match, e.g. a partial domain or a partial path, or common port(s), then Keepass should take what you do to those records and offer an alternative suggestion and then propose a longer term solution, e.g. merging existing records, applying wildcards or adding to and alternate list.