Adjust or supplement behavior of "Never URLs" matching algorithm

related GitHub issues:

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.

That is a great suggestion. I have run into this as well. Not too often but it seems like this would be a simple “repair job”.

2 Likes

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.

3 Likes

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.

2 Likes

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.

#app:all

4 Likes

I’ve found the following workaround. Maybe this is useful for someone

On the website I use, there are two different login screens
One for regular users and admin user access.

https://some.stage.domain.com/de/login/
https://some.stage.domain.com/de/admin/login/

I’ve found that I can exclude the admin user login by extending the regex.
.*stage\.domain\.com\/((?!admin).)*$

The idea is from

Now the credentials for the regular login don’t match on the page for the admin login anymore.