Fair warning — this feature request will likely be closed, because no one has been able to clearly explain how it would work.
Feel free to take a stab at explaining — I couldn’t really follow your comment above. Please fully describe the examples (for each hypothetical vault login item, list an example of the URL or URLs that would be stored in that item; then list a set of webpage URLs, and describe which of the hypothetical vault login items Bitwarden should offer as an autofill suggestion on each webpage).
If it helps, you can start with the hypothetical vault login items that I proposed above, and then explain which ones should show up as autofill suggestions on various webpage URLs:
I had a post written out but it blocked me for multiple images being a new user despite the moderator approval requirement…
basically to clarify, having it fail over would prevent seeing 10 logins at a time while allowing websites that are difficult to match or have a random subdomain depending on where you access it from like mobile.samsun/g.com or desktop.samsun/g.com example
Still having trouble with your explanation, as the URLs are truncated in your screenshot.
I would suggest just typing out each URL instead of making screenshots (redacting any sensitive information if necessary). To avoid running into restrictions on posting of links by new forum user, just highlight each typed-out link (fake or real), and then press the keyboard combination Ctrl+e. That should insert backticks (`) before and after the URL, which should look like this in the editor window:
`https://login.example.com`
and like this in the preview window:
https://login.example.com
This makes the URL unclickable, so it doesn’t count towards your link limit.
Also, please explain why you can’t just set the match detection to “Base Domain” for the logins that require it (like your samsung.com example), while leaving the reverse proxy URLs on “Host” matching?
You may not be aware that Bitwarden allows you to customize the match detection method individually for each stored URL. If a login item doesn’t match as it should using the default match detection method (which is set using the option “Default URI Match Detection” under Settings > Autofill > Additional Options), then you can edit the login item, click the icon next to the URI string, and change the selection from “Default” to any other match detection method.
Thus, you can edit the login items that are not getting matched using “Host” (as the default method), and customize those to use “Base Domain”. Alternatively, you can keep “Base Domain” as the default match detection method, and customize the login items that need “Host” matching to prevent false positives.
Think the issue is switching between those when necessary, I suppose I’ll have to do this it’s more tedium though instead of ‘no matches>try next type’
What do you mean? Bitwarden switches between them automatically. The customized URI match detection method specified for an individual URL string always takes precedence over the global default method that was specified in Settings > Autofill.
So you global default should correspond to the match detection method required for the majority of your stored URLs — then customize the remaining URLs to use individual URI match detection methods as required. Bitwarden will handle the rest.
No, there is not. After a while you will find that you really are not creating that many vault entries, so spending a bit of initial effort seems much less burdensome.
Feature request regarding the autofill default URI matching.
Currently, the two most used options are “base domain” and “host”.
If you select base domain, it will suggest every option for the said base domain. If you are like me and run many services on different subdomains of the same base domain, the list can get really long really quick.
Changing it to “host” solves this issue for multiple subdomains and only suggest the relevant one, but then it fails to make suggestions for other websites where the subdomain isn’t a perfect match.
I suggest that a new URI match option is added: base domain with preference for host.
It would work like this:
If a match is found for base domain, it checks to see if there is a more exact match (e.g. a match for this EXACT subdomain / host) and suggests only that.
If no exact match exists, it will ‘fallback’ to suggesting an item that matches just the base domain.
That way we get the best of both worlds. It prevents you from getting a giant list of suggestions when you have multiple items with the same base domain but several subdomains, and it ensures that you still receive a suggestion if an exact host match isn’t found but one with the base domain is.
Here I’ll explain, FYI as a new user I can’t add more that one site so I have used _ instead of .
site1_example_com
site2_example_com
site3_example_com
site4_example_com
Right now the defaul will match all vault items against example_com, the issue is I have 30+ sites with different logins for each site where (subdomain).example.com and I have to scrollthorugh the list of 30+ logins to select the correct one for the subdomain I need to login to.
If Bitwarden could allow match on prefrence order. for example.
So I have deidcated logins for site1&2 ea. and then site3&4 share the same login.
Going to site1_example.com becasue I have a vault item site1_example_com, this will be matched with only 1 login User_Site1|Pass_Site, and the same would apply for site2_example_com.
Now goign to either site3 or site4 or another (subdomain).example.com this will not match on Exact, and fallthrough and match on BaseDomain.
We undersatnd that we can individually configure this at a vault item, but this is not a simple task if you have 100s of items, and when adding a new site one has to remember to go and update it.
If you could set it like that, then you would always have a match - as long as it is included in “base domain”. But where would be the difference to just setting it to “base domain” now?
With base domain set it will offer you all three choices. With host preference it would only offer you an exact match unless there was none and then it would give you all three options.
Does that make sense?
Say you have a dozen different logins at subdomains of the same base domain. Like I do…
Being able to set a hierarchy gives you a couple of advantages.
First if there is an exact match that is what you will be shown rather than a cluttered list of a dozen different logins.
But if there is no exact match for this particular host it will offer you all of the logins for that base domain.
Currently you can only have one option or the other, that is.. a cluttered list of a dozen different logins or zero matches if you have match set to host and you happen to go to a different subdomain for that same base domain.
The proposed solution seems to be an elegant one with no downsides.
And if you were using “Host” as default - to add that “different subdomain” as another URI is no option?
So you prefer a sometimes not cluttered, but sometimes cluttered view? I’m not sure I understand why you don’t want it always not cluttered with using (e.g.) “Host” as default…
I may have a dozen different logins at different subdomains of the same base domain for one particular base domain…. But I also may have another base domain that has a single login that works for all subdomains of that base domain. I see this fairly often.
The point is that if you can avoid a cluttered list when possible that is a good thing.
But when there is no exact match to have options be presented to you rather than no matches at all is also a good thing.
We like good things.
As an alternative to this entire discussion there is another potential solution that I would be perfectly fine with: when base domain is set for match, if it would simply present an exact match at the top of the list that would be acceptable to me. But it doesn’t. Instead you get the full list of every single login for that base domain and what I believe is alphabetical order.
If the logic could be adjusted so that an exact match is shown at the top of the list and then all other matches for that particular base domain or underneath it that would be fine too. Because then I wouldn’t have to go searching through a long list to find the right one.
Do keep in mind that the default is just that, a default. One can override the match detection for each URL on the vault entry itself.
Even with my default match detection set to “base domain”, I can set both vault.bitwarden.com and community.bitwarden.com to “host” match detection (as below, on the vault entries themselves). The result is that whenever I go to one of those sites, I do not see the other set of credentials.
For this pair of sites, this is primarily a convenience. But, as the recent clickjacking vulnerability shows, “host” also prevents your goodguy.googlesites.com credential from being auto-filled onto badguy.googlesites.com. The lesson from this this vulnerability is that the more conservative approach is setting your default to “Host” and then overriding with “base domain” only for those credentials that that need it, such as within your own company if they use Windows Authentication for internal websites.
I just want to chime in, because I have grappled with this feature request topic for a few years, and I think that lately, I do have a better understanding of what is being requested:
First, even though the end goal of the requested functionality can already be achieved by properly configuring the URI match detection for individual URIs (as well as the default URI match detection method), some users want a more convenient process, which doesn’t require customization of individual vault items.
Second, the only way this can work is by iterating the current match detection process. Currently, when a web page is opened, the browser extension checks every URI stored in every login item, using the specified URI match detection method. In the requested feature, this process will not be performed just once, but as many as five times: all login item URIs in the vault will be first be checked against the active tab using “Exact” match detection; then, if (and only if) there are no matches, all login item URIs in the vault will be tested again, to see if any stored URIs match the active web page when using a more permissive match detection method (e.g., “Starts With” or “Host”). This process will be iterated through increasingly permissive match detection methods until “Base Domain” matching is attempted, or until at least one matching login item is found using one of the more restrictive match detection methods.
My concern is that this iterative matching process will be slow, due to the need to repeat (multiple times) the pattern matching procedure for every URI that has been stored in the vault.
icon next to the URI string, and change the selection from “Default” to any other match detection method.
