This has been discussed before, but TL;DR the current implementation of the “Never match URI” strategy is counterintuitive (IMO). Some others agree.
What I expected was, if I add a “never match” URI to a login, that Bitwarden will not show it in the list of matches (or try to autofill) when sitting on a page that matches the never URL pattern – even if there are other match strings that DO match.
In other words, a Never URL matching the page overrides any other possible matches found for that login. Example:
Login A:
URI 1 (base domain): https://google.com/
URI 2 (never): https://myaccount.google.com/
Login B
URI 1 (base domain): https://google.com/
If I am visiting:https://myaccount.google.com/personal-info
I would like only Login B to be shown since there is a “Never URI” matching on Login 1.
If I am visiting:https://mail.google.com/mail/u/0/
I would expect both Login A and Login B to be shown.
If it’s not acceptable to change this behavior due to backwards compatibility, then I suggest adding a new type of match called "Hide" (or "Skip", "Block" etc) to indicate that the login should be omitted if there’s a match.
I run into this a lot. I never understood the developer’s response with regards to the use case of “Never”. The exact same behavior that the dev described can also be achieved by leaving the URI matching pattern blank, rendering the “Never” match (as it currently is) useless and probably should be removed to avoid further confusion unless “Never” is re-purposed to work like your suggestion.
I’d love this feature. Currently I use a lot of logins on the same domain, matching a regex. It’d be really useful to be able to exclude some URLs from the match.
Absolutely agree, the current implementation of never is completely counterintuitive - just make it a simple AND NOT IN (…) in the where clause, which is what the documentation suggests it does.
Note: Original post tagged as browser, but also a big problem on mobile app.@luckman212 perhaps you could retag to add app:mobile or app:all?
Alternative Solution as suggested by @adamluzsi on GitHub thread #1610, i.e. introduce “exclude” (or “NOT”) option as a new feature on match type selection dialog, so the users can use the current match types but there would be a “exclude/not” tick box next to them, which makes them interpreted as opposite.
match-1
match-2
[exclude] match-3
match-4
[exclude] match-5
expected interpretation:
(match-1 OR match-2 OR match-4) AND NOT (match-3 OR match-5)
This way, backward compatibility is guaranteed with the “never” option, while people who want to exclude subdomains also have a regexp free option.
Yes, I also think they should put “never” rule at the top priority.
Or allow users to manually set the order of the rules, skip the remaining rules when it find associated rule.
@Peter_H In OP’s example, setting the URI2 to “Never” will still cause autofill to be done on that URI, because it will still match URI1, which is set to “Starts with”. Setting the match detection to “Never” just causes the URI to be ignored (as if it was never there to begin with), it doesn’t override matches that were made for other URI entries.
The current logic of matching multiple URIs is that they are combined using boolean OR, so that if there is a match on any of the stored URIs, autofilling can occur. With NOT operator in the mix, the logic would have to be adjusted slightly, as follows:
(URI1 OR URI2 OR URI3) AND NOT (URI4 OR URI5 OR URI6)
where URI4-URI6 have the NOT option enabled, and URI1-URI3 do have the NOT option disabled.
This suggests a possible implementation of the requested feature: just translate the presence of NOT URIs into a regex behind the scenes, and piggyback on the existing matching logic for the current regex detection method.
I would like to add my support to this, as I’m having problems with Amazon AWS.
aws.amazon.com will always be matched by the regular amazon.com domain matcher, which means you end up with all of your regular logins available when you go to log in to aws.
Being able to set aws.amazon.com to Never and have it specifically override and not match when on aws.amazon.com would be a useful feature to have.
Currently you would have to add every domain with more explicit matching, and you would have to remove amazon from the Global Domain Equivalence list. Being able to discretely not match with a specific subdomain would be useful.
Not sure exactly what you had in mind, but no, the ability to order the URI list was never a solution to the problem expressed in this feature request thread. And it was always possible to re-order URIs, it was just less convenient before (you had to copy URIs to their new position in the list).
Setting the match detection to “Never” for a specific URI will just make the matching algorithm ignore that particular URI (same as if it was simply deleted from the list), and this is the behavior whether the “Never”-match URI is placed at the top or at the bottom of the list.
This test showed that your assumption was wrong. I am not surprised, since this would have been a major change in the behavior of URI matching, and would have been accompanied by an official announcement and an update to the documentation.
The reordering of URIs by drag-and-drop is strictly for the purpose of organizing information and facilitating use of the “Launch” function.
The idea of sorting/prioritising is a red herring and polluting this thread; the Bitwarden URL matching algorithm is a simple filter / where clause, and that would be absolutely fine if we just had the ability to add a NOT operation as requested and clearly described by Phil Church & Wild Wanderer above. This does not sound like a big ask to me but would solve so many problems without requiring users to write obscure RegEx that many (including me) will probably get subtly wrong.
TBH I am surprised we are still discussing this issue year’s after it was raised and a good solution proposed, and that it has not just been implemented by now. Perhaps it’s harder than I think?
Polluting? Sorting/prioritizing is inherently required for this FR to work. To behave as envisioned, “NOT” needs to be prioritized over “match” entries. (hence the () AND NOT () syntax). Bitwarden introduced the ability to easily order the URL list. That too could also be seen as a prioritization method. Hence the reason I asked the question.
A red herring is something intended to distract. That was not my intent in asking if Bitwarden might have solved the request in a different way. A simple “unfortunately it does not” would have been much more appreciated.
Sorry, I did not mean to cause any offence, but in the Boolean logic of “(a OR b) AND NOT (c OR d)” there is no order or priority required or inferred, (beyond the brackets obviously!) that is all I was trying to say. Once (IF) we get the NOT operator, everyone should be able to easily do what they need, no need to scare the developers by asking for sorting, prioritisation or firewall first match wins logic, etc. which is a long way from the simple filter logic we have. Adding a NOT operator has no side effects (that I can see) and fits the current design pattern. Sorting/prioritisation is a change to the pattern, hence why I said it’s a red herring.
However, although I think I was correct, I am sorry to have caused you offence.
