URI detection: sort results by match exactness

[grb]

@Tahlor Welcome to the forum!

@Tahlor

but each account has its own subdomain / password combination

You deal with this by changing the URI match detection setting to something other than the default “Based Domain” setting.

@Tahlor

you might have a central university account, but additional ones within your department, research lab, or other miscellaneous university resources.

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.

@Tahlor

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.

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.

[Tahlor]

Is this a real example?

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.

[grb]

@Tahlor

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?

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.

@Tahlor

I suspect many users do not find URL matching particularly accessible.

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.

@Tahlor

a default sorting based on the number of matched subdomains when base domain is selected would be great

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.

[blank]

This is a deal breaker for me. I can’t understand why this kind of feature gets so much pushback and hate. I’ve seen it proposed multiple times and always there are excuses and cop-outs to not implement it.

Some websites offer different services on different subdomains, and you need different credentials for them. Some sites even offer different login forms on different URIs on the same domain.

For example: myblogexample.com may be a personal blog or ecommerce shop or something, and users can log in. myblogexample[dot]com/admin could be some sort of admin panel with a different set of credentials. myblogexample[dot]com/phpmyadmin could be an instance of phpmyadmin where one can log into the database (insecure, I know, but these do exist and are fairly common). cpanel.myblogexample[dot]com could be where the owner can log into a cPanel instance to manage the hosting parameters for the site. dev.myblogexample[dot]com could be a testing instance of the site where developers implement and validate new features before enabling them on the live site. All these login pages have different sets of credentials. If I happen to be a developer working on the site, I’ll have accounts on all of them. This is actually a real scenario that I have to deal every day. I have around 10-20 credentials for each site I work on, but only 2-3 of them are relevant on each page of the site. I would like Bitwarden to be smart enough to recommend the right accounts for the right page.

I know you can tweak the URI and the match detection on an individual basis, but come on, who does that? Especially when, in fact, I do not need custom matching rules. I need THE SAME RULE FOR ALL MY LOGINS, just a smarter one. I just want to click Save on the prompt and have the password manager figure out what to do with my credentials.

This is how the matching should work: If I have credentials that match the exact URI, then obviously I want those suggested first. If I have credentials that start with the same subdomain, just happen to have something different at the end, those should come after the exact matches. If I have credentials that match the same subdomain, I want those suggested immediately after. If I have credentials matching only the base domain, those should come last. If there are multiple credentials matching the same level of priority, they should be sorted by history, the ones I used last time should be first.

This would be the ideal URI matching. In fact, this is what google already does with their password manager, and it works great. It always recommends exactly the credentials I need. Too bad it lacks all the other features… But it can’t be that hard to implement something like this…

I’ve kept trying Bitwarden over the years, and I always go back to just saving passwords on google or having them both at the same time, for this one reason alone. Google is so much more convenient in regards to recommending the proper credentials for each page. And it’s frustrating because this is not some kind of super-smart or complex algorithm that only Google could figure out. They just prioritize the URIs in a way that makes sense.

EDIT: Why can’t I use exact matching? Because I want just one global matching rule for everything. I do not want to configure matching rules on an individual or group/folder basis. If I switch to exact matching with all my logins, then services that have the same credentials on multiple domains will no longer work. I think google does this. And there are many other sites that sometimes ask you to login on app.domain[dot]com and account.domain[dot]com and so on.

[DenBesten]

@blank

This is a deal breaker for me.

In which case, scroll all the way to the top of the topic and in the top-left corner, click “vote”. ATM, this has zero votes, so it appears to be a priority for nobody.

[scruel (Scruel Tao)]

Some domains will have individual websites for its subdomains, for example:

• www.amazon.com
• aws.amazon.com
  Or company’s own inner website:
• service.corp.com
• voice.corp.com
• corp.com

For currently detection methods:

None of them can help users easily find the correct entry without effort, see related post:

Subdomain URI Matching

This feature request is for an additional URI matching type: subdomain matching. A case is where an application has a number of servers, so the user gets redirected to login at a random server: wwerpo23.appname.company.com w23rxpi34.appname.company.com wcpoiud83.appname.company.com wpicuek92.appname.company.com some unknown number of other servers, which could change at any time but it should not match other company domains, such as: otherapp.company.com In this situation, the existing op…

Which I want is similar but smartly combined all match detection methods, and we may call this detection method as “smart”.
For the “smart” one, we won’t let users have their own choose, and it should perform matches in the following order:

1. match with “exact”.
2. match with “starts with”, with will consider the protocol (http, https, ftp, etc.), and the whole URI.
3. match with “host”, this will consider subdomains (won’t include domain level records).
4. match with “regex”, this can be optional.
5. match with “Base domain”, this should include all related records for the domain.
   Once there is a match, the corresponding records will be returned. If there is an error, the user needs to modify the record.

Even more, we can provide a “custom” option, which allows users to reorder the detection methods.
Then we should only need three items in the “Default URL match detection” in its context menu:

• Smart
• Custom
• Never

This feature can provide more user-friendly and (should ) make them happy!

[scruel (Scruel Tao)]

Not:

if URL == URI
   then return true
   else if host(URL) == host(URI)
      then return true
      else if basedomain(URL) == basedomain(URI)
         then return true
         else return false
      end
   end
end

Its a matching order rule:

1. match with “exact”.
2. match with “starts with”, with will consider the protocol (http, https, ftp, etc.), and the whole URI.
3. match with “host”, this will consider subdomains (won’t include domain level records).
4. match with “regex”, this can be optional.
5. match with “Base domain”, this should include all related records for the domain.

Once there is a match, the corresponding records will be returned. Empty or wrong match is not a thing we need to consider, the user needs to modify the record to make it work, but I don’t think inthis way user will even have questions.

According to your pseudocode, it seems that bitwarden will perform marching one by one rather than global query, then for my idea, it should be:

func match
  if URL == URI
    return 1
  if URL.startswith(URI)
    return 2
  # if host(URL) == host(URI) and protocol same
  #  return x
  if host(URL) == host(URI)
    return 3
  if URI_REGEX.match(URL)
    # should sort domains for results
    return 4
  if basedomain(URL) == basedomain(URI)
    # should sort domains for results
    return 5
  retun 0

for res in vault:
  if match(res) > 0:
    results.add(res, level)

if results empty
  return empty
grouped = group_by_level(results)
for cur_level from levels 1..5
  if grouped.cur_level not empty
    return grouped.cur_level_res

retun empty

But I prefer:

rules = [
  query URI == URL
  query URL.startswith(URI)
  ...
]
for rule from rules
  res = run rule
  if res not empty
    return res
return empty

So if I have following records:

• corp.com
• voice.corp.com
• sub.corp.com

For visting sub.corp.com, I will get only one matched record “sub.corp.com”, rather than three (with base domain)

you can say now you can match with host, but we will need base domain match sometime, and we can’t choose it both, switching between them over and over again? Not a chance!

For visiting x.corp.com, I will get both three

For this, if autofill could put “corp.com” record at the top, then it will be awesome!

[ivantha (Oshan Mudannayake)]

I am thinking about moving away from Bitwarden exactly because of this issue. Leaving a comment because I couldn’t figure out how to vote.

[grb]

@ivantha Welcome to the forum!

To vote, scroll to the top of the thread, and click the Vote button next to the thread title:

 

Also, can you explain your use-case? In the context of this feature request, what are some specific situations in which you wish that Bitwarden would behave differently?

[ivantha (Oshan Mudannayake)]

Thanks for trying to help. Unfortunately, it doesn’t look like I can vote yet as this is what I see at the top.

Here is my use case. I have a set of services provided through the domain fruits.com. I can log into each service through URLs such as below.

• fruits .com/apple
• fruits .com/orange
• fruits .com/banana

Each of these login pages requires distinct credentials.

Bitwarden typically matches URIs using the base domain (based on what we set in options), which functions well for my needs except in the case of fruits .com. For this domain, I have three separate sets of login credentials saved for apple, orange, and banana. Unfortunately, Bitwarden suggests the last used login details among these three whenever I attempt to log in again.

I want Bitwarden to override its default behavior of matching URIs only using the base domain (and filling the login form using the last used credentials if there are multiple) and autofill the login form with the set of credentials that best matches the URI.

fruits .com logs me out every few hours, and having to manually right-click and select the correct credentials each time I log back in is really frustrating.

-I had to put a space before the period of every fruits .com as this forum apparently limits new users from using more than 2 URLs in a response.

[DenBesten]

@ivantha

I can log into each service through URLs such as below.

• fruits .com/apple
• fruits .com/orange
• fruits .com/banana

Sounds like the “Starts With” match detection will fit your need.

So, the you would have three vault entries:

Name: fruits.com - apple
Username: apple
Password: MacintoshGoldenGalaHoneycrisp
URI: https://fruits.com/apple
Matching Rule: Starts with

Name: fruits.com - orange
Username: orange
Password: ValenciaMandarinBloodNavel
URI: https://fruits.com/orange
Matching Rule: Starts with

Name: fruits.com - banana
Username: banana
Password: OnlySomeBananasArePlantains
URI: https://fruits.com/banana
Matching Rule: Starts with

The help document does not make it overly clear, but you can have different Matching Rules for each vault entry. It is accessed by selecting the gear icon to the right of the URI field in the vault entry.

[ivantha (Oshan Mudannayake)]

you can have different Matching Rules for each vault entry. It is accessed by selecting the gear icon to the right of the URI field in the vault entry.

I found the gear icon to the right of the URI field and this solves my issue.

Even if I saw @grb’s reply earlier stating that this could be achieved, I couldn’t find the gear icon because I guess I was skimming through the replies fast and looking for it in the top right of the vault entry.

Thanks for explaining this to me again.

[grb]

@ivantha Glad you found the setting for customizing URI match detection!

For your case, you could use either “Starts” with or “Exact” as your matching method, depending on whether or not the login form URLs have any variable characters at the end of the URL string (e.g., tracking info, redirect info, etc.).

To use the “Exact” matching method, it is best to capture the URI by navigating to the login page, opening the details view for the corresponding vault item, and clicking the Auto-fill and save button below the item details. Then edit the vault item, delete any old URI strings (other than the one just added), and set the URI match detection to “Exact”.

With regards to your inability to vote, that is an issue that has been plaguing the forum recently, but was supposed to have been fixed last week. Try logging out and back in and/or clearing your browser cache, and if you still are unable to vote, send a DM to @sj-bitwarden.

[blank]

I will refer back to my previous post from above. I know it’s fairly long, but I think it is worth a read, as it addresses the points brought up afterwards:

https://community.bitwarden.com/t/base-domain-versus-host-best-of-both-worlds/51339/19?u=blank

You keep pushing for using the current matching settings. Here are a few key points from that post, along with some new observations:

• Going through each login to set a custom matching mode is not feasible, as I have hundreds of logins.
• Half of my logins would kind of work with exact matching, the other half would need domain matching. Setting one default rule is guaranteed to break at least half of my logins.
• We do not in fact need multiple matching rules with tedious customization for each item. We need ONE SORTING RULE which you keep pushing back against.
• Having a very strict default matching rule would hide relevant credentials on a lot of pages. Having a very generic default rule with random sorting would show too many results on sites with different credentials on different subdomains. The solution is a generic rule with proper sorting. Why does that help? Because on generic sites that only have one credential for all URIs you will see the saved login on all subdomains. On sites with different credentials on different URIs you will see all the credentials for that domain, but they will be sorted by relevance, so you only need to care about the first result.
• I provided real-life examples in the post that illustrate the issue. Those cannot be all solved by matching rules alone. Instead of asking whether the examples given by the users are real or made up, you could either take that feedback to hearth or admit honestly that you do not care about those use cases. Similarly, I do not see the value in asking why someone has ‘so many matching items for a single site’ instead of discussing the actual solution that was proposed.
• There is value in sorting the results, even if you do not see it. It seems sorting is what everyone is asking for. If sorting is that complex of a problem to solve, or if you feel that either one of the proposed sorting methods would not satisfy everyone, why not add the option to allow users to write a simple macro for sorting? To me that would be great, and since there are so many people proposing pseudocode, I feel others would agree as well. I am tired of splitting hairs trying to justify a legitimate request, just to have other people dismiss it and try to convince me that I don’t actually need the feature. If I hadn’t had an issue I wouldn’t post about it.
• How many votes does it need to have to be considered? Just because people do not realize they are missing a feature or do not have the habit of getting involved in discussions/voting for features or are not aware that this thread exists, that doesn’t mean they wouldn’t benefit from it.

[grb]

@blank

I provided real-life examples in the post that illustrate the issue. Those cannot be all solved by matching rules alone.

All of the examples you gave can be solved by existing matching rules.

@blank

Instead of asking whether the examples given by the users are real or made up, you could either take that feedback to hearth

Not sure who you think I am or what you think my role here is, but to clarify, I am not a Bitwarden employee and I have no more influence over their decision-making than you do. I am just a Bitwarden user like all other participants in this thread.

or admit honestly that you do not care about those use cases.

When the use case is that the existing, fully functional feature is too much trouble to use, then you are right, perhaps I personally don’t care as much as I would about other issues.

@blank

It seems sorting is what everyone is asking for.

I think you are right about this, so I will merge this thread with an older feature request about sorting of URI matches; this should increase the total vote count from 10 to 14.

@blank

How many votes does it need to have to be considered?

Bitwarden does not have any specific rules or guidelines for this. The feature requests are just one factor that go into their decision-making. Features have been implemented even with 0 votes but sometimes had to wait for almost 1000 votes before implementation.

[d0gkiller87]

Currently, when the autofill mode is set to Base Domain, Bitwarden displays logins for different subdomains and services on various ports in an arbitrary order. This makes it inconvenient to quickly find the most relevant match.

For instance, when visiting blog.example.com, the autofill suggestions might appear as: map.example.com, bank.example.com, and finally blog.example.com.

Switching to the stricter Host autofill mode may seem like a solution, as it prioritizes the exact match at the top of the list. However, this approach falls short for websites like google.com, where most subdomains share the same set of credentials. In this case, logins for myaccount.google.com would not appear when visiting mail.google.com, making this mode a bit impractical (at least to users that are used to the Base Domain mode).

To overcome these inconveniences, I would love to see a mechanism that allows users to customize how autofill suggestions are sorted, based on factors like:

• Levenshtein distance between the login entry’s name and the visiting page’s host:port
• Levenshtein distance between the login entry’s URI and the visiting page’s host:port
• Last used (autofilled) time of the login entry
• And more rules that I couldn’t think of at the moment, but people might find them useful…

Additionally, offering advanced users the option to write custom comparison functions in a secure, sandboxed environment would be extremely useful. Without such a feature, the only workaround is to clone and rebuild the extension/app, which is far from convenient.

[DenBesten]

Welcome, @d0gkiller87 to the community!

I don’t know if you are aware of it, but you can set the auto-fill mechanism individually for each vault entry. This is done by clicking the gear icon to the right/above the URL for the vault entry,

So, you might set “host mode” for map.example.com , bank.example.com , and blog.example.com . But, then set “base domain” for example.com. This would result in generally having 1 or two entries for the mentioned sites.

Also, the order is not arbitrary. Entries “recently used” appear first, (most recent first) followed by those not recently used in alphabetical order. The reason behind this is to make it easy to fill in web sites that put the username and password on different pages.

[d0gkiller87]

Hi @DenBesten! Thanks for your clarifications.

You can set the auto-fill mechanism individually for each vault entry.

While setting autofill modes individually for each vault entry can partially mitigate the issue, there are a few shortcomings:

• It may not be as convenient, as users have to determine whether the website shares the same account pool across services. Then, they must manually select the appropriate mode or adjust existing entries.
• It’s less flexible compared to allowing users to design their own custom rules tailored to their specific needs, especially for use-cases that we can’t think of right now.

Since this feature request aims to enhance Bitwarden’s convenience, I believe there’s still room for the said improvements.

Entries “recently used” appear first, (most recent first) followed by those not recently used in alphabetical order.

I was aware it’s sorted by recent usage, and it’s my bad for not explaining this clearly in the original post. However, since users often visit subdomains in a random order, the list gets rearranged accordingly. As a result, the entry for the current site can appear in an unexpected position, therefore difficult to locate. (oppose to showing as the first entry automatically)

[grb]

@d0gkiller87 Welcome to the forum! I moved your request into an overlapping feature request thread. You might find it helpful to review the discussion above (and this comment in particular).

[d0gkiller87]

Update:

Just made a dirty patch that uses Levenshtein distance to sort entries, and
the matching accuracy is pretty good as anticipated. Of course there’s still rooms for improvements (make it smarter, integrate better to Bitwarden’s codebase, more customizations via UI, etc…) but it’s just a proof of concept to demonstrate the idea!

If anyone is interested to test it out:

GitHub - d0gkiller87/bitwarden-clients-fork: Bitwarden client apps (web, browser extension,...

Building steps:

cd bitwarden-clients-fork
npm i
cd apps/browser
npm run build # the extension directory will show up at apps/browser/build