Auto-fill: Form is hosted by a different domain - confirmation popup

Pop-up:

I’ve never seen this popup before. Had to check and make sure my browser extension and browser were up to date and nothing changed just today. It hasn’t.

I can’t make sense of why it is appearing in the first place based on my auto-fill settings and the URI matches I’ve configured the login item for. Please take a look at that info below.

Does anyone have an idea as to why this is happening?

Item:

Auto-fill settings:

@element6 Welcome to the forum!

This message occurs because the webpage that you are logging in to uses an iframe to render the login form, and the HTML source code for the iframe contents are loaded from a URL that is different from the URL of the main page (the one in your browser address bar).

The warning message was implemented in March of 2023, so you would not have encountered it prior to that date. It is possible that the website itself has recently reconfigured its HTML code to specify a different source for the iframe contents.

You need to add a URI to your account that recognizes the URI from which the iframe source is loaded.

Your setup for that account is quite odd, since it can match a large number of websites (basically, any website that specifies a URL path or query parameter that ends with -ilo\, -ilom\, -mgmt\, etc.). Thus, Bitwarden would automatically transfer your login credentials to a website like https://password.thieves-r.us/load?ghroegh-oqeoi-hrgo-ihq-egh-mgmt\, should your browser ever be redirected to such a page while your Bitwarden extension is unlocked.

However, most likely, the iframe source URL ends with -mgmt (and not -mgmt\), which is why it is not recognized by Bitwarden. I would suggest inspecting the page source code to examine the expression used for the iframe source, and then add this expression to your URI list (with appropriate URI match detection).

Hello and thanks for the response.

Yes, I am aware this is an odd match type. This vault is being used on a machine on an internal only subnet. I am aware of all of the implications/risks of matching based on regex and know what I am doing.

Good call on the iframe issue. I wasn’t thinking about that earlier because the error message doesn’t provide a valid explanation. I will create a feature/enhancement request for that.

I right clicked within the login iframe and clicked on view frame source. Which revealed the full URI of the actual login portion of the page.

So in this particular case, when I visit the site, I am going here in the address bar:
https://hostname1234-mgmt/
and the address bar always reflects that exact format when I am at the initial login page. After I log in, it changes, but that isn’t important to this conversation aside from proving that my browser(s) are accurately showing where they are.

Using https://hostname1234-mgmt/ as an example, here are the 2 important URI regexs I’m using (separated by a pipe) in the regex101 playground so you can view and modify the regexs and test strings to see what matches in real time:

I made only one minor change to the original regex to address your example, despite it being unnecessary in my use case, as the machine using the vault is never used to access the internet. This vault is for a machine I use to work on servers on an internal subnet. Only.

Thanks again!

1 Like

Had the error message in my first post told me that the form was not matching because it was located in a different folder on the webserver, instead of incorrectly stating that it was hosted by a different domain (not true), the user would actually be able to determine what the problem is.

1 Like