I propose a new (default) URI Match Detection logic:
Show in descending order:
exact hits
starts with
host
base domain
It could be called “Automatic” match detection.
Example:
Logins in bitwarden:
- university.org
- sub1.university.org
- sub2.university.org
Result for https:// sub1.university.org/:
1) sub1.university.org # host
2) university.org # base
2) sub2.university.org # base
(Maybe another few lines of code could rank university.org before sub2.university.org in this example.)
It would solve this issue of mine:
My default match detection scheme is “Base domain”, which works fine with 90 % of my logins. The remaining 10 % (still about 100 logins!) are sites with different subdomains and logins, but the same base domain (my university, for example, where I have 17 entries). There, I must manually change to “Host”.
If this algorithm were the default, I would never have to change these settings. The wrong logins would be displayed, but the correct one would always be the top result.
The current options allow you to get the exact matches you need. I wouldn’t want to see any results that don’t meet the match detection criteria I’ve set. If a vault entry is set to “host” match detection, I definitely wouldn’t want to see results that don’t match the exact host.
I think this is a very interesting idea, but I share @danmullen’s concern as well. Specifically in the case the OP mentions (17 distinct sub-domains/URIs and 100 credentials), the proposed search could yield an overwhelming number of hits returned to the user.
I suggest that if URI match detection will incorporate rules-based logic, then the logic should be complete. Specifically, if a higher-order match is made, then no further matches should be returned; otherwise, cascade the search down to the next search level.
For example, given this search order for a query:
exact hits
starts with
host
base domain
Logic: if an ‘exact hit’ is matched, then only that result is returned and the search is complete. If not, move to a ‘starts with’ search and return all matches. If no ‘starts with’ matches are found, move to ‘host’ matches, etc.
On mobile, I’ve noticed that if you don’t have an exact match it does actually give you some suggestions. For example, if you have some credentials saved for a website but don’t have the app package name set up as one of the URIs to match against, it does often show the correct credentials as a suggestion.
For the Auto Fill option I like choosing Host here. But when I chose Base Domain, I got more choices. I want the best of both worlds. I just want my Host choices first and then the remaining Base Domain choices tacked on at the end.
By the way, you will notice the extra small font in the pop-up menu in the middle of the screen. Also there ought to be a help button as a third button and pressing it will bring us to the familiar web page that explains all this.
Actually, why in the world, are not the best matches presented first in the Base Name list? Apparently just all the matches are just thrown one after another, with no ordering at all. Oh okay maybe they’re alphabetically ordered. But why not have the best matches first? I mean if we are on a site that is a perfect match that match should not be way down at the bottom of the list just because it starts with a w.
If we are logging in to W.B.C that should be the first that we seen the list and not A.B.C, B.B.C, C.B.C…
In fact, we get about 8 or 9 choices deep and that seems to be the limit and then the final choice is the Bitwarden vault. So even the perfect choice (100% match) might be too far down the list and won’t even show and we have to tap the vault to get to them.
Yes I’m talking about the behavior when one has Base Name selected as one preferred Auto Fill method.
It is not clear what you are asking for, or you may have misunderstood the purpose of the setting, which has nothing to do with sorting of vault items.
For each URI stored in every login item in the vault, you have the ability to specify the match detection method, which is used only for the purpose of determining whether it will be possible for associated the login credentials to be auto-filled at the URI in question.
The setting that you are playing with in the screenshot you posted specifies which of the available match detection methods should be used by default, for any stored URIs that do not have a customized match detection option. The default value can really only be one of the available options, so your request doesn’t make sense. If you want to customize the auto-fill behavior for specific sites, you would change the match detection option for those specific URIs, not the global default.
Your follow-up post makes even less sense to me, but perhaps that is because I don’t use the mobile app. But in my time on the forum, I have never heard of a “base name list”, nor any option to have “base name selected as one preferred Auto Fill method.” Certainly the browser extension, desktop, and web vault apps have no such features, and the Help Center documentation also does not describe anything of the kind. Apologies if this is an undocumented feature in the mobile app that I am not familiar with.
Okay! Let me Express this in terms that probably are applicable to the desktop experience too. I’m using totally default settings in my example here. Okay let’s say you’re on this webmail website and you choose to go to the vault:
I am just saying that instead of always just giving alphabetical order, some sensitivity should be applied here by noticing that the site we have just come from is indeed right there on the list and should be elevated to the top. That would also benefit cell phone users because their lists are limited in length and less accessible.
Not only could they be moved to the top, they could also be in some different color or have a star added to them or be highlighted or something, because they are perfect matches. I’m talking about the last two entries in the immediately above photo.
Well, none of the above looks anything like the desktop or browser extension, but by reviewing the documentation for Android, I’ve determined that your last screenshot is a list of vault items that have at least one URI matching the site that you are visiting.
This begs the question: why do you have so many matching items for a single site? Do you really have a dozen different login accounts on the same website? This is not a standard use-case, so perhaps if you explain a little why you need to have so many different accounts for the same site, that would be helpful.
Also helpful would be if you could share the full URL of these web sites (substituting private information using aliases, if necessary).
Anyway, even if there’s only two matches at least the first one should be the exact match of the site we’re already on. And add a little color to show that it’s not just thrown at the top by accident.
Do all of those URL access the same (set of) services? For example, if you log in to webmail.example.com, is this equivalent to logging in to help.example.com?
OK, now I have a better idea of your situation. You are not using Bitwarden the way it is intended to be used. When you’ve browsed to a specific site and then access your vault to auto-fill, it should only display login accounts for that particular site. So in your example, when you go to webmail.example.com, you should only see two vault items: the webmail login for jimmy@... and the webmail login for jimmy-test@.... Thus, there should be no need for sorting of the list, unless you have more than a dozen different test accounts for the same site.
It appears that setting the global default URI match detection option (the setting you were messing with in the screenshot in the OP) to Host is a more appropriate option for you. If the default setting mostly works as intended (i.e., narrows the list of vault items only to the set of login credentials that can be used on the current web page), but does not always produce the desired result (e.g., sometimes shows irrelevant vault items, or sometimes fails to show a relevant vault item), then you can (and should) customize the URI match detection option for the individual URI stored in the problematic vault items.
To customize the match detection method for a specific URI, open the corresponding vault item for editing, and click the gear icon () shown to the right of the URI. This should bring up a drop-down menu, where you can change the option from Default (i.e., use the default match detection rule that was specified in the global settings) to something specific to use for that URI only (e.g., Base domain, Host, Starts with, Exact, Regex, or Never). If the vault item is being offered in the autofill list when it isn’t relevant, select a match detection method that is more restrictive than the method specified in the global default setting. If the vault item is not being offered in the autofill list when it should, select a match detection method that is more permissive than the global default method. In a few cases (e.g., if using the Starts with option), you may also need to edit the URI itself.
If you are having trouble getting this to work for a specific site, you can request help in the Ask the Community forum.
Yes, I know about the setting to restrict it to exact matches,
but I don’t want to do that. Yes I know that I can even do that
per-site.
I love the default setting, even for just this *.example.com site group. I’m just saying
that it could be enhanced (or optionally enhanced via a setting),
so that it could show the exact matches first at top (marked slightly
differently too.)
Wouldn’t that be a great added value, instead of just throwing them all
at the user, merely alphabetically sorted?
Indeed, being the default option, less users would “not be using the app
as intended, thus getting frustrated” because in more cases they would
see what they were looking for, right at top.
Thus they needn’t research Settings right away to make the app do what
they want, as the defaults will be working fine for them in even more cases.
You are trying to take an existing function (listing all accounts that can be auto-filled on a given login form) and change it into something entirely different (listing all services available under a given web domain).
For your needs, I would suggest using other available methods to organize and view your vault content (e.g., the vault search function, folders, or favorites). The “Matching Items” list is strictly for listing different login accounts that are available to autofill on the current site, not for suggesting related services.
For most users, this works as intended when leaving the individual match detection option as Default on each saved URI, and leaving the global default match detection method as Base Domain. Adjustments to these standard settings are necessary only in special cases (e.g., if different subdomains are used for different services on the same base domain).
Apparently what I need to do is go into each and every single one of these 12 matching items. And set them all to “exact” . Otherwise whichever I leave as default is still going to interfere when it comes time to match, meaning I still would have to need an extra step of selecting which which one I want.
Yes even if I only use one of them very often, and the others once in 5 years. Because the others still match, I can’t just get away with changing one. I sure wish they didn’t bury the way to change one of these so deep. It’s about as deep as you can get in the vault for each one of them. So many clicks needed.
This is a good idea. Most restaurants use the same app/rewards base domain (e.g., myguestaccount.com, punchh.com, etc.) but each account has its own subdomain / password combination. Account proliferation is also common at universities, where you might have a central university account, but additional ones within your department, research lab, or other miscellaneous university resources.
Then you have instances where you have the same credentials for cs.university.edu, xxx.cs.university.edu, and yyy.cs.university.edu. So if you set cs.university.edu to match Host to avoid matching with university.edu, then you might need to add all of the subdomains xxx.cs.university.edu, yyy.cs.university.edu, etc. Not only this, but you probably also want to set university.edu to Host matching so it doesn’t match with cs.university.edu, so you also need to worry about adding every possible other subdomain zzz.university.edu that shares credentials with university.edu, even though it’s probably a good default assumption.
I appreciate that Bitwarden gives you a number of ways to handle this, but a default sorting based on the number of matched subdomains when base domain is selected would be great for most users compared to adding every possible subdomain or some abstruse regex command.
) shown to the right of the URI. This should bring up a drop-down menu, where you can change the option from Default (i.e., use the default match detection rule that was specified in the global settings) to something specific to use for that URI only (e.g., Base domain, Host, Starts with, Exact, Regex, or Never). If the vault item is being offered in the autofill list when it isn’t relevant, select a match detection method that is more restrictive than the method specified in the global default setting. If the vault item is not being offered in the autofill list when it should, select a match detection method that is more permissive than the global default method. In a few cases (e.g., if using the Starts with option), you may also need to edit the URI itself.