To protect against various autofill vulnerabilities I prefer to set my URI matching to “Exact” whenever possible.
I just encountered a page where I had trouble getting a match (using the Chrome browser extension). The password change form for ID.me has the URL
https://account.id.me/signin/password (as copied verbatim from the browser address bar).
However, when I add this as as a second URI, and set the matching the “Exact”, the form is not recognized as a match; adding a trailing slash (
/) to the URL doesn’t help. However, if I change the matching method to “starts with”, then the page is recognized as a match.
Why is it not possible to use “Exact” in this case? Is there a better way that I can check what URI the loaded page is presenting to the Bitwarden app, other than copying what is in the browser address bar?
If I go to the URL you posted, I get redirected to a login form an a different page at the URL:
Using this URL and Exact match, Bitwarden autofills just fine for me.
Perhaps there is some redirect happening at your end, also?
No. To reproduce the issue, you need to first sign in to an account at ID.me. Once logged in, then go to the problematic URL (or navigate to Sign In & Security, and then to Password).
If you attempt to go directly to the password change form without first logging in, you will be redirected to the login form, as you found out. I don’t have any issues with getting an exact match on the login form, but I cannot get an exact match on the password change form.
[Edit: The fact that Bitwarden does match on the URL when changing the matching method from “Exact” to “Starts with” proves that the “real” URL has something extra appended to the end of what is displayed in the browser address bar.]
Is there a better way that I can check what URI the loaded page is presenting to the Bitwarden app, other than copying what is in the browser address bar?