Allow limited wildcard matching for Browser Integration URLs

[amkuchta]

Summary

With v2.5.0, the ability to add multiple URLs for a single entry is awesome. Some sites, such as the AWS console, require a certain URL for navigation (e.g. hitting the console login page for a specific account or alias). However, during the page load, the server redirects the user to a URL that may not always be the same.

Desired Behavior

It would be nice to be able to provide a set string (e.g. signin.amazon.aws.com), and have the browser offer up any and all credentials that match that string (via a wildcard lookup on either end of said string).

Possible Solution

Utilize a regex with the URL and additional URLs fields to search for applicable credentials. This behavior could (and probably should) be toggle-able via a switch in the application settings (e.g. "Regex match URLs for browser integration")

Context

Although I am sure that AWS is not the only site that does this, it is the most prominent of the use cases that I have. I am required to maintain several AWS accounts, and being able to utilize the browser integration for them would be awesome.

[droidmonkey]

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.

[varjolintu]

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

[amkuchta]

@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)/¯

[NoXPhasma]

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.

[droidmonkey]

Keeping this open for wildcard support

[Anke]

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

[varjolintu]

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

[Meza100]

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

[varjolintu]

@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.

[Meza100]

@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?

[varjolintu]

@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.

[Meza100]

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

[prometheanfire]

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.

[prometheanfire]

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

[droidmonkey]

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.

[prometheanfire]

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

[Anke]

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.

[varjolintu]

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.

[Anke]

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

[varjolintu]

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

[FichteFoll]

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.

[acbox]

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.

[droidmonkey]

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

[heylix]

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.

[uhausbrand]

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

[varjolintu]

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

[uhausbrand]

@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.

[kitgerrits]

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.

[bartowl]

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...

[varjolintu]

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

[melroy89]

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

That would be much appreciated! ❤️

[EBoisseauSierra]

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.}.

[mfrakka]

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

Thank you.

[Mayurifag]

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. 👍🏻

[varjolintu]

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

[the-moog]

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.

[mistr-2]

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.

Yes, please. Sometimes I have the feeling like authors do not really use their own creations in real life. This issue is opened for some 5 years...

[droidmonkey]

I use browser integration every single day and have no need for wildcards. It's a niche use case and opens a bunch of other problems. When you add wild card you can't click open the link anymore since it's invalid.

[bartowl]

I use browser integration every single day and have no need for wildcards. It's a niche use case and opens a bunch of other problems. When you add wild card you can't click open the link anymore since it's invalid.

That you do not have any use for wildcards does not mean noone has. I can imagine an entire subnet of VMs that share same LDAP credential and it is cumbersome to copy and paste dozens of entries and then update them (if someone does not use references) once password changes. Wildcards were a nice touch there. Also - you do not have to enter wildcard in the URL. you can use "additional URLs" under browser integration and put wildcards there. This will not make your displayed URL "unclickable".

I would like to have support for re-using same credential over multiple wildcard-based hostnames (like x.x.x.x.nip.io) as this would simplify managing small vm clusters for example. More configurations would also benefit from it.

[kitgerrits]

Dozens, try thousands. At Enterprise scale, having regex host matching would be a life-saver. Management Interfaces oer switches in a dedicated management subnet with centralized authentication (Active Directory/LDAP/Radius/Tacacs) would allow for a massive improvement to quality-of-life. Kind regards, Kit

…

On Fri, 10 Jan 2025, 16:17 bartowl, ***@***.***> wrote: I use browser integration every single day and have no need for wildcards. It's a niche use case and opens a bunch of other problems. When you add wild card you can't click open the link anymore since it's invalid. That you do not have any use for wildcards does not mean noone has. I can imagine an entire subnet of VMs that share same LDAP credential and it is cumbersome to copy and paste dozens of entries and then update them (if someone does not use references) once password changes. Wildcards were a nice touch there. Also - you do not have to enter wildcard in the URL. you can use "additional URLs" under browser integration and put wildcards there. This will not make your displayed URL "unclickable". I would like to have support for re-using same credential over multiple wildcard-based hostnames (like x.x.x.x.nip.io) as this would simplify managing small vm clusters for example. More configurations would also benefit from it. — Reply to this email directly, view it on GitHub <#3718 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIKX7VE5KRFCSHRDUNPIWL2J7QB3AVCNFSM6AAAAABU6NGUQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOBSHEZTSNRRGU> . You are receiving this because you commented.Message ID: ***@***.***>

[varjolintu]

I would like to have support for re-using same credential over multiple wildcard-based hostnames (like x.x.x.x.nip.io) as this would simplify managing small vm clusters for example. More configurations would also benefit from it.

This already works if you just set your entry URL to https://nip.io.

[droidmonkey]

Precisely what @varjolintu mentioned, we already support wildcards in the sense of *.example.com. Anything else is very niche and exposes several issues.

[mfrakka]

It may be a niche but it is a very broad or very deep-rooted niche, given that it has been insistently requested for years...

If you don't need a feature, you don't have to use it.
But if you need it and it's not there, you simply can't use it.

[mistr-2]

@droidmonkey There's a bunch of ppl here over the years, showing various examples, explaining, but you're so fixed on your "niche" mantra that you simply ignore that. You probably never met IoT, large scale networks or enterprise environment management, but there much more than just IP addresses, as others proved repeatedly.
Well, you put quite some time into the project over those nine years and in my book, you have the full right to screw the app as you want. But that doesn't make you automatically right on every topic and decision.

[uhausbrand]

As an user who also requested this issue I went back to keepass2 as there it is possible to do and solves my use cases even if this means in needing to use plugins for stuff keepassxc handles in core. So I am not interested in this anymore as I am not going to use keepassxc.

[varjolintu]

FYI: We are still doing the feature. Just restricting the usage to Additional URLs.

[mistr-2]

FYI: We are still doing the feature. Just restricting the usage to Additional URLs.

Sounds like the solution to everyone's concern, thank you.

[kitgerrits]

Thank you!

…

On Mon, 13 Jan 2025, 11:26 Sami Vänttinen, ***@***.***> wrote: FYI: We are still doing the feature. Just restricting the usage to Additional URLs. — Reply to this email directly, view it on GitHub <#3718 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIKX7TOAHYOKF6MHGKNA632KOIEVAVCNFSM6AAAAABU6NGUQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOBWG4ZDENBXHE> . You are receiving this because you commented.Message ID: ***@***.***>

[kubassyz]

Hi all,

I might missunderstand this asterix stuff, but if I try the https://*.signin.aws.amazon.com/ or *.amazon.com)/, I get an "invalid URL" message, in a red backgrounded field. What am I doing wrong? (2.7.6 on kubuntu)

update: I've tried the above mentioned https://*.test.text.de, and got the same error message as well

[droidmonkey]

It's not a feature yet