keepassxc
keepassxc copied to clipboard
keepassxreboot
Allow limited wildcard matching for Browser Integration URLs
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.
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.
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.
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?
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:
https://github.com/keepassxreboot/keepassxc/pull/3558#issue-319191219
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.
Ah, so this is where it should go, thanks. It doesn't mention the subdomain wildcards, but that was what I was looking for.
Where would others find such information?
That doesn't address wildcards, but it does let you put in any number of additional urls
It seems that now * is supported? When I use * in the url field in the client it warns me of invalid url, which made me think that the wild card is not supported, but it does work fine with the browser plugin despite warning me of invalid url.
We have decided that wildcards are unnecessary with the current implementation.
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.
