Browser: Match detection for URI: "Never" is not working.

Created on 24 Oct 2018  路  15Comments  路  Source: bitwarden/browser

Step to reproduce:

  • Create a login entry
  • Add a regex/host/ or just base match to a whole domain
  • Add a second match to Never on a subdomain.
  • Open the subdomain: The entry is still shown.

When dealing with HTTP basic auth, the fact that Bitwarden will prefill only if there is one entry makes this bug extremely annoying since there are no way of having multiple different logins for dynamic subdomains.

Most helpful comment

Then what's the purpose of "Never"? Just do not specify the domain and that's it. For example, my google.com account will not be offered for autofill when I am on yahoo.com domain. If I add yahoo.com as "never" this changes absolutely nothing. If I add domain.com and add sub.domain.com as "never", this again does not change anything because autofill no matter still will be suggested.

I also thought that "Never" provides a way to exclude some subdomains if they match the domain from another rule. I totally miss the point of "Never" then.

All 15 comments

I just tested this and was not able to reproduce. Please provide a sample URL and the URI values you are using to reproduce the issue. My guess is that your regex is not doing what you think it is.

I'm using version 1.33.3 on Firefox Dev Edition
Here's a screenshot of the configuration of the item which is still matching when I load the exact URL set to Never.
https://imgur.com/a/AIKCZXY

If you go to https://dashboard.njibhu.eu it will still match the first URI and be presented. Seems to be behaving as expected. I imagine you want a more strict rule on the first entry.

The problem is that I have dynamic subdomains where I want this entry to be matched with names I can not predict. But I do not want it to be matched on this subdomain.
Having a Never rule should override any other match, if not, what's the point of it ? Not having any rule has then exactly the same effect than having a Never rule, right ?

(changing the order doesn't change anything)

Temporary solution is to use a regex like:
^(https?)://(?!dashboard)\w+\.njibhu\.eu
But having the Never rule to override other match would really be handy to add exceptions to a rule super easily, and that's what I think people are expecting with a never rule.

Rules do not override each other like that. If one rule matches the item will still be returned.

Then what's the purpose of "Never"? Just do not specify the domain and that's it. For example, my google.com account will not be offered for autofill when I am on yahoo.com domain. If I add yahoo.com as "never" this changes absolutely nothing. If I add domain.com and add sub.domain.com as "never", this again does not change anything because autofill no matter still will be suggested.

I also thought that "Never" provides a way to exclude some subdomains if they match the domain from another rule. I totally miss the point of "Never" then.

I agree with @plashenkov, what is the point of "never" if it can't override a rule? I also originally thought it was a way to exclude domains from an initial matching rule. @kspearrin could you kindly give a use case for "never"?

@kurisu-gh Use case: You create 2 login items, A and B, for "https://google.com" but you do not want it to autofill. You want A to autofill, but not B. Set B's URI match detection to "Never".

@kspearrin I see. I still don't understand why you would want B (a login for google in this example) to never autofill with the google URI. "Autofill" meaning that when I click on the Bitwarden extension button (or right click -> Bitwarden), the list of matching logins show up and I click on the desired login to use. How would you use B? Would you search for it? Why not just let B match like A and select the login you want to use via the autofill list?

If I didn't want B to appear in the autofill list, then I'd leave the URI entries blank.

I can see how it might spin out of control, but would an "exclude" function be warranted if people keep assuming "never" means that. (I'm one of those people)

Adding my name to the list of people bamboozled by this option!

I completely agree with njibhu, in that adding a "never" entry _should_ allow the default match rule to work while _excluding_ any subdomains explicitly defined by "never" rules. Right now the only way to do this is via regex, which is far from user friendly, and your own docs specifically put dire warnings against doing.

kspearrin's use case makes zero sense to me.

@kspearrin anything to add about this? A number of users here, including myself, expected the "never" entry to be a way to exclude subdomains. It is clear that this would be a much better use case instead of having to write out a regex pattern , an approach not recommended in your docs.

The use case you brought up doesn't seem to be very useful. Why not set the login item B with blank URI entries so they don't match with anything at all? The "never" option, as it is now, doesn't have any meaningful purpose.

I also understand making "never" as an exclude function from the initial match is also not so straightforward. It is also a matter of how the "never" function will match the exceptions and what would be a user-friendly way to configure it. But I imagine the most popular use-case will be to exclude a particular subdomain.

In the mean time, if anyone wants to have a pseudo "never" function, here is the regex I use:

^https:\/\/(?!.*(mail|photos)).*(google\.com).*$

Matches any https google.com URI except those with a mail or photos subdomain and respective sub-subdomains. You'll need to remove the original default matching pattern and add a regex matching URI based on the pattern above.

Note that you'll have to also make another regex for login items that specifically work with the mail or photos subdomain... or use "host" matching for those subdomains. In my use case, host matching was not enough as some funky sites I use have a sub-subdomain.

In case anyone needs to specifically match any sub-subdomain with a fixed sub-domain URI like I had to, here's an example:

^https:\/\/.*mail\.google\.com.*$

This would specifically match any https mail.google.com sub-subdomain like https://something.mail.google.com.

Then what's the purpose of "Never"? Just do not specify the domain and that's it. For example, my google.com account will not be offered for autofill when I am on yahoo.com domain. If I add yahoo.com as "never" this changes absolutely nothing. If I add domain.com and add sub.domain.com as "never", this again does not change anything because autofill no matter still will be suggested.

I also thought that "Never" provides a way to exclude some subdomains if they match the domain from another rule. I totally miss the point of "Never" then.

Totally agree!

^https://(?!.(mail|photos)).(google.com).*$
This works and I don't mind using Regex but it really only for advanced users. Whilst I can figure out what the above does after a little research I totally forget again after a period of time and gotta look it up to figure it out.

Using 'Never' as described above seems to be how users expect it to work ... the reason that I found this thread! For the average user, the Regex above is just gibberish and OTT.

I agree. I much prefer a non-regex solution to exclude subdomains, but I guess the developers are not listening and the explanation of 'Never' by @kspearrin is not so compelling for all the reasons discussed in this thread, and he has yet to follow up. This issue has been closed for some time now, so I'm not sure how much visibility this issue will get.

So I'm forced to use regex in the meantime, and if anyone wants similar functionality for an otherwise excellent password manager, they can start with the pattern example I posted. But I much rather prefer the developers to have a proper never/exclude host function.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

blockloop picture blockloop  路  6Comments

gavrilfb picture gavrilfb  路  4Comments

HizzyHaz picture HizzyHaz  路  4Comments

kosvrouvas picture kosvrouvas  路  3Comments

passcod picture passcod  路  5Comments