Default match policy bug - Browser Extension can't match local hostnames without explicit local domain

[castigo86]

Steps To Reproduce

The issue affects only local network resources called by hostname, with default match policy selected.

URIs as http(s)://hostname.localdomain match to a login credential in bitwarden browser extension.

URIs as http(s)://hostname do not match the same login credential, even though the specific URI is linked to the login credential.

Both URI were matched to the correct login credential before the 2022.12.0 client update. Both are set to the default match policy.

It does not seem to affect websites with a TLD.

Expected Result

Both sites (http(s)://hostname.localdomain and http(s)://hostname) should be matched by bitwarden extension when both URIs are matched to a login credential, just as before.

Actual Result

The only matched URI with matched policy set at default is the one formatted http(s)://hostname.localdomain.

The http(s)://hostname gets a match only if the matching policy for its URI is set to "host" or "start with".

Screenshots or Videos

No response

Additional Context

I have a local TrueNAS server and various local web pages responding at https://hostname and https://hostname.localdomain. Both versions are saved in my bitwarden extension to match and have worked perfectly with default match polices until client version 2022.12.0.

Since the update https://hostname is no longer recognised by the bitwarden's browser extensions, no login data or match shows up in the extension.

Only Https://hostname.localdomain works as expected.

The issue is repeatable with other webpages running on my network in the same fashion.

Operating System

Windows

Operating System Version

10

Web Browser

Chrome; Firefox

Browser Version

Chrome 108.0.5359.125; Firefox 108.0.1

Build Version

2022.12.0

Issue Tracking Info

• [x] I understand that work is tracked outside of Github. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.

[Ascathon]

Even though workarounds exist, hope this gets fixed. Prefer using those single world hostnames instead of full local domain.

[castigo86]

Bug still present on 2022.12.1

[Shuttleu]

I believe it was 8c59eef257bcef9d9866ed7c009784d6b586c77a which has introduced this bug. Building the commit before, allows the extension to work as expected, but since this commit, local domains no longer work.

[castigo86]

Looks like it... I'm sure it's going to be an easy fix then

[Shuttleu]

Current solution is to either remove your current extension, install V2022.10.1 and prevent it from updating. Or build commit 94e9744d0603f46fd3244d935a0e4fe9baf10e30 and install that one (I don't believe manually installed extensions update automatically, or at least mine hasn't)

[castigo86]

Thanks! For anyone else reading this, in the interim, I think that less technical users might prefer to temporarily change from "default match" to "host" for their local domain credentials while the app is being fixed.

I wouldn't mark the issue solved though.

[dwbit]

Thanks for your patience everyone, this is the result of a recent fix: https://github.com/bitwarden/clients/pull/3168, setting your matching to 'host' or 'exact' should resolve the issue, let us know otherwise and we can re-open the issue.

[evils]

setting my matching rule to either host or exact does work for local hostnames, but breaks regular domains... is there a way to get both to work?

[Shuttleu]

setting my matching rule to either host or exact does work for local hostnames, but breaks regular domains...

is there a way to get both to work?

Instead of setting the default to 'host' or 'exact', set it in the individual accounts.

[evils]

i'm not going to edit every entry to get back the old working by default behaviour...

[Shuttleu]

You only need to do it in the accounts with a local hostname.

That is currently the only way to get it working.

[evils]

odd i can't find the setting in the specific entry's edit pane

also, it seems newly captured local hostname entries do work with the base domain setting (unless localhost is a special case)

[castigo86]

Hi,

I can confirm that sadly you have to do the rain dance to set to "host" all the local sites that are formatted like https://host, while https://host.localdomain will work with default settings. You can find the setting for each URI by entering the edit mode for an element in the client and clicking on the gear icon on the URI line. Set the general default policy back to stock and edit only those entries that you know need to be formatted without the ".localdomain" part. Hope it helps.

[dyfrgi]

Am I right in understanding that this is the canonical bug for this issue and that no fix is planned? Which is to say that it is now intended behavior that default matching will not match bare hostnames. This isn't mentioned on bitwarden/clients#3168 or in any of @djsmith85's linked PRs like bitwarden/jslib#547, so it seems like it was an accident.

[abcd678]

any update on this? .home.arpa is the recommended way to handle home hostnames and bitwarden lumps everything together, requiring manual copy pasting for each host https://www.rfc-editor.org/rfc/rfc8375.html