The full details of this feature request were first posted as a bug on the GitHub page here.
I’ll paste the full content below, but here’s the gist:
Many websites/apps have super long URIs (like hundreds of characters) for their “Sign Up” pages. So the default URI in Bitwarden when creating a new item from this page is incredibly long.
If you rely upon a “Default URI match detection” setting of “Regular expression,” this incredibly long URI will not match the actual sign in page after signing up.
In the Bitwaden iOS app, when adding a new item from a sign up page, the keyboard for the “URI” field does not include a spacebar. So you cannot use the iOS keyboard feature of “press and hold spacebar to quickly navigate text string” to navigate to the end of the default URI and backspace all the junk.
The negative effect: After adding a new item, Bitwarden will be unable to match this new item on the sign-in page without you first manually editing the new item to fix the URI. This makes the process of creating a new credential very tedious.
Here’s what I posted to GitHub:
Steps To Reproduce
Be registering an account in an iOS app/website (any app or browser) not previously registered to Bitwarden.
Tap “Passwords” above default iOS keyboard, which will open the Bitwarden app overlay if Bitwarden is your default iOS password manager.
Tap the + in the upper right to create a new vault item.
The URI will pre-populate with the URI from which you initiated the Bitwarden overlay.
You will be unable to navigate to the end of the URI, as there is no spacebar on the keyboard. Nor will you be able to create an additional URI.
Expected Result
At least one of these things should occur:
I should have the ability to quickly navigate to the end of the URI so that I may backspace.
I should be able to create a second URI. This option does not exist after clicking the “plus” in the Bitwarden overlay after tapping “Passwords” on an iOS keyboard after tapping the registration field on a website or app. However, the option for a second URI is present in the app itself.
If my default URI match detection is regular expression, then when auto-populating the URI field, do not include anything after the first /
Actual Result
I am stuck generating credentials that I am unable to use, as immediately after creation, the absurdly long default URI does not match on the website I just used to create the credential.
Screenshots or Videos
No response
Additional Context
For users who set their Default URI match detection to “Regular expression,” the default URI that populates a new item is often an incredibly long URI that cannot be identified via regex. For example, creating a Microsoft account will use a default URI of:
(preferred) When auto-populating the URI field, do not include anything after the first / if your default URI match detection is regular expression.
(workaround) Provide a spacebar on the keyboard chosen for the URI field
(workaround) Provide the ability to add a second URI in the the “new item” overlay.
My personal workaround as an end user:
Instead of generating the new vault item in the overlay directly from the website at which I am registering an account, I switch to the Bitwarden app and create the item there first. Then I can navigate back to the website and populate it with the pre-created vault item.
Build Version
2024.6.0 (7846)
Environment Details
Device: iPhone 13 Pro
OS: 17.5.1, but the issue has been occurring for several releases, if not all of them.
This seems like a highly unusual thing to want to do (especially if you don’t plan to actually store any regular expressions in the URI fields!), and is the root cause of the “negative effect” you are experiencing. It sounds like you would be much better served by setting your default URI match detection method to “Host” (which matches only the FQDN and port sections of the URL, and disregards any other characters following the FQDN and port).
Can you provide a detailed explanation of what it is about your use-case that makes you want to select “Regular expression” as the default method for match detection? Usually, this method is rarely used, only to solve very challenging match detection problems that cannot be resolved using any of the other match detection methods.
For #1 and #2, please create separate feature requests. Each feature request thread should contain only a single proposal (including perhaps some different options for how to implement the feature), otherwise discussion and voting becomes too confusing.
Thank you for the recommendation that I try Host match detection. When I began using Bitwarden, I changed the default of Base Domain to Regular expression due to the following:
Many websites provide me with different subdomains depending on how I get to the login screen. For example, I might see "myaccount.live.com", "login.live.com", "signin.live.com". For this use case, “base domain” would suffice.
I self-host services in my home network using a single private domain (call it mydomain.com) and would have different logins for thing1.mydomain.com,thing2.mydomain.com, etc… Base domain does not suffice for this, but “Host” would.
I self-host some services that have the same FQDN but different ports. This is another use case where the granularity of regex comes in handy. Neither “base domain” nor “host” works here.
I chose regular expression because it appears to be the only match detection that works for my wide variety of logins. By entering ".*.live.com", I can use the same credentials no matter which live.com subdomain I access. Similarly, with regex, I can create unique logins for each self-hosted subdomain.
I have to admit that I found your response to my request hostile. You say it’s a highly unusual thing to do, as if it doesn’t warrant an improvement, but it’s a feature provided by the software that I’m asking to be improved. You may not use it, but it’s an existing feature in a dysfunctional state right now.
You assume I don’t plan to actually store any regular expressions in the URI fields, but I do. From a UX perspective, a user who uses Regular expression as the default URI match detection would benefit significantly from a vault-wide checkbox that will populate the URI field with the host (FQDN+port) and nothing else. This way, when creating a new item, I can easily modify the pre-populated URI field.
The core issue here is that it is impractical to use the entire URI string from the sign-in page as a default while simultaneously having the software require an iOS keyboard layout that lacks the spacebar. Ever since Apple stopped implementing Force Touch on their iOS devices, the ability to quickly navigate through a string by pressing and holding anywhere on the keyboard has been gone. Instead, you can only use the spacebar - which, again, can be made available in the Bitwarden URI field but isn’t.
For #1 and #2, I am not making feature requests. I don’t care how the developers resolve this. I simply copied and pasted the requested format from the GitHub issues page into this post instead of rewording for a different request portal.
If you are not a contributor to the Bitwarden code, I’d appreciate it if you did not post to these threads telling users the very real problem they are experiencing doesn’t actually exist.
Are you sure? The “Host” setting only matches when the FQDN and port number (if specified) are correct. See the examples provided in the documentation.
It sounds to me like you would be best served by setting your Default URI match detection method to “Host”. Then, for live.com and similar sites, either add all FQDNs as separate URI fields within the same login item, or keep just one URI and customize its match detection setting to be different from the default (e.g., set it to “Base Domain”, or even to “Regular Expression” if that is your preference).
My response was not intended to be hostile, I was just trying to assist by pointing out that there are much simpler ways to achieve what you want to achieve. And I’m not saying that the problem doesn’t exist for you, only that it seems to be a problem akin to putting a square peg into a round hole.
I wish you best of luck getting traction with your feature request, although I note that it currently stands at zero votes. If you wish to support your own proposal, scroll to the top of the thread and click the Vote button.
“Regular expressions are an advanced option and can be quite dangerous if used incorrectly. You should not use this option if you do not know exactly what you are doing.” This quote is a warning well worth heeding because match-detection is the primary defense against lookalike websites.
Taking the example you provided, it will match any the following, yet you likely only want the first two.
The two gotchas are that “.*.live.com”, is not anchored, so it can match anywhere in the URL, including after the question mark. And secondly, a period matches any character, not just a literal period. To literally match, one needs to escape the period with a backslash. The proper regular expression for matching what you presumably want is:
^[\w]+://([^./?]+\.)?live\.com(/|?|$)
Or, as @grb suggests, just use “base domain” match detection, which gets it right in a much more friendly way, even if you end up with a few URLs on one vault entry.
And if one needs to explicitly use regex, understand its syntax very well, especially with respect to how it differs from wildcard matching. In Bitwarden, regex really only belongs on individual entries; not as the default match method.
I disagree. Host and base domain are the trick for matching FQDN+port. Matching the rest of the URL is pretty much what regex is built for. It gives the customizability when I want to match my tenant ID on a cloud service, when I want to force matching to just a single protocol (https, but not http), etc.
Using the example from your first link, looks like this may be safe as well: ^https://[a-z]+\.live\.com
But yeah, .*.live.com is definitely unsafe. I have over 1000 items in Bitwarden. Many (most) use regex. I’ve got my work cut out for me to change my URIs.
It was so long ago that I initially set up Bitwarden, maybe I had a different use case I don’t remember. In any case, I didn’t read the doc and assumed the ^ and $ were implied. Even if they were, I didn’t backslash the second dot, so it was pretty inadequate regardless. And I made the mistake of assuming that what I had done in the past was correct and kept using the same schema. Pretty embarrassing for a software engineer. I’ve got a lot of self-reflection to do.
Close. An anchor is also needed at the end of the hostname portion to prevent https://www.live.com.badactor.com from incorrectly matching. That can be solved by adding this to the end:
(/|?|$)
It just comes with the territory. Computers are humbling, all by themselves. Then throw in the creativity of bad actors. And for seasoning, add regular expressions, which are the poster-child for needing to consider border-cases. And people wonder why we don’t sleep well at night.
