Adjust or supplement behavior of "Never URLs" matching algorithm

Feature Requests Password Manager
1

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.

1 Like
2

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
3

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
4

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
5

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

5 Likes
6

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.

7

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.

8

Feature name

  • “NOT” operator for URI configurations

Feature function

The benefit is that I could then have my login available everywhere on the site except the NeverAutofill page.

Related topics + references

9

You could achieve this now using a regular expression, though it’s still a good idea.

10

How about using the already existing feature to set the match detection of an URI to “never” ?

11

@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.

1 Like
12

grb, thanks for explaining better than I could. I would use regex, but I never have and am concerned I might set it up incorrectly.

2 Likes
13

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.

1 Like