Currently “Exact” URI match includes query strings and fragment identifiers.
This behavior causes unnecessary mismatch when the base URI is the same but query parameters or fragments differ.
Please consider adding an additional matching option where autofill triggers only when the base URI (scheme, host, port, and path) matches exactly.
@fg3hfpav Welcome to the forum!
Wouldn’t that be what the “starts with” matching option already can do?
Hello, @Nail1684! Thank you for the welcome.
The “starts with” option behaves differently from “Exact” (it also matches subpaths) and cannot be conveniently registered using “Fill and save.”
To function properly with it, the query and fragment parts must be manually removed one by one.
“Exact” and “Starts With” both match subpaths (if subpaths are included in the stored URI). So I don’t understand what you are stating above, and would appreciate a clarification of what you meant.
As noted by @Nail1684, you can already do this using “Starts With”. Alternatively, you could do it using “Regular Expression”. In both cases, you would have to edit the stored URI to make the matching work as intended.
It seems that the feature you are actually proposing is some mechanism to avoid having to edit the URI strings that are stored using “Fill and Save”. This could either be a modified “Starts With” method that automatically ignores query or fragment strings at the end of the stored URI, or a modified “Fill and Save” function that automatically strips query or fragment strings from the end of the stored URI.
Doesn’t the “Starts with” option also match a URI like example.com/path/path if autofill is set for example.com/path?
Regex solution would require updating thousands of saved login entries, which is inefficient.
And I believe regular expressions are unlikely to match URIs as accurately as the URI libraries used by the languages in Bitwarden clients.
It would be more effective if the client provided an additional matching option.
It’s quite similar, but as mentioned above, due to the subpath issue, a modified “Exact” match would better address the use case than a modified “Starts With”.
Currently, the autofill options do not work well with the “Fill and Save” feature. For example, if a login is saved from example.com/login?redirect=settings, neither “Exact” nor “Starts With” will match example.com/login?redirect=home, even though the path structure is effectively the same.
Yes. So am I understanding that you want to match all of the following:
https://www.example.com:1234/tophttps://www.example.com:1234/top?query=paramhttps://www.example.com:1234/top#fragmentbut none of the following:
https://www.example.com:1234/top/subhttps://www.example.com:1234/top/sub?query=paramhttps://www.example.com:1234/top/sub#fragment… is that correct?
This could be done with a regular expression, but again, it seems that your core request is to not have to edit the URI strings (preferring instead to just use the exact string that is captured by “Fill and Save”). Now that I understand your concern with subpath matching better, I see that simply stripping queries and fragment identifiers during “Fill and Save” would not work.
Thus, the two approaches that could be used to address your needs would be:
Yes, that’s true.
Since asking every user to manually edit thousands of entries is far from ideal, it would be best if both options were supported, or at least if a match detection method were implemented.
The idea of adding an option to specify regular expressions is good, but it would be better if the URI library handled this by default.
That’s the reason for this feature request.