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).
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
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
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.
You deal with this by changing the URI match detection setting to something other than the default “Based Domain” setting.
Same. You can set the URI match detection to “Host”, Starts With", or “Exact” so that each set of login credentials is matched only to the relevant web page and not to other websites in the university’s web domain.
Is this a real example? I find it implausible. Most universities use SSO these days, so there would be a single set of credentials common to all password-protected services on the university domain. But no matter how many different sets of login credentials you have on a specific domain, you can set up URI match detection to deal with it.
If the example above is real, then I would suggest using “Exact” as your default URI Match Detection (which you can set in Settings > Auto-fill). If you come upon a web page that doesn’t get matched by the extension, but that has the same login credentials as one of the login items stored in your vault, then use the Search function to bring up the stored credentials, and use the “Auto-fill and Save” button; next time that you visit this web page, it will match.
No, I just like to troll devs by posting obscure counterfactuals I’ve never experienced.
Corporations have SSOs. Universities do for some core services, but not for clubs, labs, or dozens of other miscellaneous organizations with ad hoc websites run by students, nor necessarily for different departments, or e.g., high-performance compute resources that have different security requirements (mine has SSO and all of the above still apply to me).
The point is not that BitWarden can’t handle these scenarios with sufficient configuration (e.g., why offer anything besides regex), but I suspect many users do not find URL matching particularly accessible. But more to the point, there seems to be very little downside with having the matches be sorted even slightly intelligently. Is the reason not to do this primarily because it is too much work to implement or because it is somehow counter to BitWarden’s intended functionality? In principle, it seems like it could be layered onto BitWarden’s existing domain matching fairly simply.
I can’t speak for the devs, but as I already explained earlier in the thread, sorting matches based on the URI would run counter to the intended functionality. The list of matches is supposed to represent every set of credentials that can be used to log in on the active web page. If your list of matching items also includes irrelevant login credentials that cannot be used for logging in on the active web site, then your URI Match Detection settings are incorrectly configured.
For the vast majority of users, the default URI Match Detection method (“Base Domain”) works fine. For users such as yourself, setting the default URI Match Detection method to “Exact” will solve 90% of your problems. The remaining 10% are fixable with a little bit of customization, and if you work in the Computer Science department at University.edu, then it should not be difficult.
Not even sure I understand what you are proposing. If you want to further promote some proposed implementation of this feature request, please provide a more detailed description of what you are suggesting.