I currently run into some scenarios where I have different credentials for independent apps within the same domain.
They are saved independently using distinct URLs, unique by subdomain or port, but the autofill seems to put the first one that matches the domain, that is incorrect.
I believe it should have a priority rule, complete URL match, then subdomain or port match, then domain.
Something like that, to avoid mixing auto fills.
Welcome, @mencargo to the community!
Bitwarden has a wide variety of match rules that you can use to accomplish this.
Their mindset is a bit different, though. Match detection shrinks the list. It is a filtering mechanism, not a sorting mechanism.
@mencargo Welcome to the forum!
Do these independent apps have distinct login credentials, or do they all use the same username/password?
If they have different credentials, and are saved in separate login items, then you should be able to resolve the issue simply by setting the URI match detection method to Host, either globally (by changing the default URI match detection method, under Settings > Autofill), or by customizing the URI match detection individually for each of the stored URL strings (to do so, edit the Login item, click the 
icon next to the URI field, and then select “Host” in the drop-down menu; don’t forget to save the changes to the login item).
If this doesn’t address the issue, then please share the specific format of the URL strings for the apps that are not being properly matched by Bitwarden.
Exactly! THAT is what we severely miss: a sorting or a priority mechanism. Other password managers do support them.
are (quite) typical examples of very common, completely DIFFERENT accounts ON THE SAME HOST. As other password managers do, they give preference to certain matching methods above others, OR, when the methods are equal, standard select the longest match, especially with “URL starts with”. So it would prefer to match my webmail account since mydomain/roundcube matches mydomain/roundcube more than just mydomain or mydomain/ anything-else .
As a system administrator I run in these kind of scenario’s all the time and I dearly miss this ability. Coming from another manager that does have it.
PS: Great! A discussion on URL matching where I am not allowed to post URL’s by the discussion board. Hurray! Hence the awkward workarounds
@RLievaart Welcome to the forum!
Brand new forum users have restrictions on posting of URLs, as a way to prevent the forum from getting flooded with spam. It should take at most 30 min of participation in the forum to get promoted from “new user” (TL0) to “basic user” (TL1), which will lift most such restrictions. In the meantime, the easiest work-around for posting a URL is to enclose it in back-ticks (`InsertURLhere`), which will render as pre-formatted (non-clickable) text: https://www.example.com.
Regardless, to deal with your use-case, the way to configure this in Bitwarden would be to set the URI Match Detection method to something more specific. For example, if randompath really means a random text string that changes each time that you access the login form (e.g., some kind of session identifier), then you can truncate the stored URL to omit the variable part of the string:
https://www.mydomain.com/squirlmail/
Then set the match detection method to Starts With. To change the URI match detection method, edit the login item, click the icon next to the URI field (which toggles the visibility of the match detection selector), and then select the desired match detection method in the drop-down menu; don’t forget to click Save when done.
If no part of the URL is variable, then you can use the Exact match detection method. For complex matching scenarios, there is also a Regular Expression option.
@grb has exactly the right approach, but I do want to mention a seemingly surprising behavior. When you update the squirlmail URL, it removes squirlmail from the match list for the other websites; it does not suddenly make the squirlmail website have only one match. So things will not start to “look right” until you get all 4 vault entries tightened down.
www.mydomain.com/any-where is a tough one to get right. The easiest solution is to find a more specific match, such as www.mydomain.com/login. Otherwise, you are entering into the realm of negative match rules with the regular expression method – which is neither easy nor pretty.
Another gotcha is that Starts With requires the protocol (https://) at the beginning.
1 Like
Hey grb! Thanks for the welcome, the reply and the tip!
I was reacting to DenBesten who wrote: “It is a filtering mechanism, not a sorting mechanism.”
And yes, I know how to filter the url’s. I use Starts With (in my language it has a different name). The point is that there is no prioritising. There is no “this matches much better than that”. It’s just: match or no match. The last password I used will be on top - even if I need another one with a much better match. If I go to mydomain,com/specific/stuff, I want my password stored for mydomain,com/specific on top — not the one that only has mydomain,com. But since both match, and Bitwarden does not support any prioritising, the last one you used will be on top. (On iPhone not even that.) And it can be quite the hassle. I have used prioritising in other managers more than 10 years ago, so it IS possible 
Could you explain the use-case for which you would want Bitwarden to offer an autofill suggestion for a set of login credentials that cannot be used to log in to the site that is open in your browser?
I’m having trouble understanding a scenario under which you would want the “no match” case to still be displayed (even with some kind of “prioritization”).
Is the actual problem that your base-domain matched www.mydomain.com login is not being filtered, when it is not relevant to the open webpage? If so, the second paragraph in @DenBesten’s response above offers a way to address this situation. Is your login form for www.mydomain.com really accessible from each webpage under https://www.mydomain.com/every/conceivable/path?
The general idea is that only the credentials that work on that particular domain website should match. If a cred will not work, it should not be presented as an option. Once tuned, this makes “match priority” much less relevant.
Back to www.mydomain.com/any-where. Presuming any-where is intended as a wildcard, You would need to use a regular expression, something like this to keep it from matching the sites on which the credential will not work:
^https://www.mydomain.com/(?!(roundcube|myphpadmin|squirlmail)).+
Or, as earlier mentioned, cheat and find something like www.mydomain.com/login to match on instead.
Just like the OP said in his very first sentence. If you have heard of roundcube or phpmyadmin, you will understand. Many system managers have MANY apps running on the same domain. Direct Admin or cPanel, Database, webmail, front-end vs back-end, etc. All different “apps”/accounts on the same domain. It is quite common. I cannot explain any better because I start repeating myself because it is really really common to me and has been for 20 years… This is also why other password managers have had the possibility of prioritising. Am I repeating myself again? I am.
It is needed. It is possible. It is done by others. Why not Bitwarden?
I do use roundcube and other apps on my domain without issues; I do understand how there can be multiple distinct login accounts under the same domain. The question I wanted to get an answer to is why you would ever want Bitwarden to show your phpmyadmin login credentials at all as an autofill option when you are trying to log in to your roundcube app?
Interesting, DenBesten that you mention that. I DID try negative lookahead but it failed. Now since it is regex, even though I am quite experienced with it, it still might be me. They are so easy to screw up, that’s what they’re known for . Are you sure negative lookahead is possible in Bitwarden? I tried quite some times and concluded it wasn’t. I hope I am wrong because that WOULD solve it for me! (Not al regex engines support lookaheads and lookbehinds, of course.)
PS. I still think that prioritising has its use since regex’es are out of most user’s ballparks.
Unless someone can explain why you would ever want an irrelevant set of login credentials being shown by Bitwarden as an autofill suggestion for a non-matching webpage (even if demoted from the top position in the autofill suggestions list), then I think that the following feature request would be a more suitable solution for the use-cases described above:
My negative lookahead experience is all outside of Bitwarden, but they do claim to support regular expressions, which have long included lookaheads.
Another untested theory is that since one can now specify the order for URLs to match, perhaps you could on the www.mydomain.com/any-where vault entry add an URL https://www.mydomain.com/squirlmail to the top of the list with its match detection set to “never”.
Now tested; does not work.
Not denying that, but there then would be an interaction between “most recently used” and “prioritized” to work out.
And for sites with usernames on one page and passwords on a second page, anything other than “most recently used” greatly risks the wrong vault entry’s password being entered.
As explained in the other feature request that I linked, the effect of the “Never” match detection method is equivalent to deleting the corresponding URI from the item altogether.
Subsequent to your description (that URIs are “or-ed”), Bitwarden has introduced the ability to reorder URIs. This makes me suspect that they might have switched to “first match wins”.
1 Like
“Never”: Oh, I wish, but it needs to match exactly for “never”. and these apps have a lot of URL’s like `https://mydomain.com/phpmyadmin/index.php?route=/table/structure&server=1&db=my_example_db&table=my_example_table
I had the exact same thought a few onths ago – I think I really tried it all… but no
This is not the case, as far as I can tell. Still not 100% sure I understand what you mean, so perhpas you can describe (or better, perform) a test that would prove or disprove your hypothesis.
Here’s my initial test:
Item1:
https://www.example.com/path/(Never)https://www.example.com(Base Domain)
Item2:
https://www.example.com/path/(Exact)
If I go to https://www.example.com/path/, I still get two matches (Item1 and Item2), as always.
1 Like