Local DNS URIs Identified as "--"

[edomatedlogic]

Describe the Bug

When attempting to fill credentials on LAN-only websites with local DNS entries (*.mydomain.lan) from a browser on Android, Bitwarden reports, "There are no items in your vault for --."

Steps To Reproduce

On an Android device

1. Connect to a LAN containing a web server with a local-only DNS entry (e.g. server.mydomain.lan) which also has its credentials properly added to your vault.
2. Open a browser.
3. Go to the URL of the server with local-only DNS entry.
4. Click the Bitwarden "Auto-fill with Bitwarden/Go to my vault" fly out.

Expected Result

Bitwarden should identify the URL and fill the credentials.

Actual Result

Bitwarden will open and present the message, "There are no items in your vault for --."

Screenshots or Videos

N/A

Environment

• Device: Samsung Galaxy S21
• Operating system: Android 11
• Kernel version: 5.4.61-qgki-22265714-abG991USQU4AUGQ
• Build Version: RP1A.200720.012.G991USQU4AUGQ
• Is this a Beta release? N
• Browser: Firefox or Chrome, latest versions from Google Play Store

Additional Context

Local-only host names are provided by a local DNS server running dnsmasq which contains entries for servers with LAN IP addresses of the form "*.mydomain.lan".

[jamescridland]

Can confirm this behaviour on Version: 2.11.3 (3653).

I am running Android 11 on a Google Pixel 3a.

[larena1]

Having the same issue since forever. Thing is that when you add an entry to the vault from that page it'll save it with the correct url so it seems to know the correct url.

They stated they're actively working on fixing autofill for some months already but progress still remains to be seen. There's also no response as to what the status is unfortunately.

[fdisamuel]

I have this problem too.

Running android 11 on MI 9 SE. Bitwarden version 2.12.0 (3742)

[manningtelfer]

This issue is also occuring for me, on Android 11 as well as on iOS14.7 and iPadOS14.7.1

[athisun]

Having this same issue. It seems related to how the domain is parsed in https://github.com/bitwarden/mobile/blob/master/src/Core/Utilities/DomainName.cs - TLD's are expected to be included in the public suffix list, and since lan is not a valid public TLD, parsing fails.

[jamescridland]

Good catch.

I've reported the lack of .local to the public suffix list. .local is defined by RFC 6762, so is a valid public TLD.

Perhaps you might star the issue over there?

publicsuffix/list#1466

[edomatedlogic]

Having this same issue. It seems related to how the domain is parsed in https://github.com/bitwarden/mobile/blob/master/src/Core/Utilities/DomainName.cs - TLD's are expected to be included in the public suffix list, and since lan is not a valid public TLD, parsing fails.

It is interesting that this would be handled differently in mobile than in extensions.

[edomatedlogic]

Good catch.

I've reported the lack of .local to the public suffix list. .local is defined by RFC 6762, so is a valid public TLD.

Perhaps you might star the issue over there?

publicsuffix/list#1466

Looks like the maintainers at public suffix are having none of that.

[jamescridland]

Yes, so it does. Well, then, that then puts the ball back into Bitwarden's court.

This is inconsistent behaviour within Bitwarden, since .local is correctly identified on the desktop browser, and works just fine there; just doesn't work on Android. That seems to be a shame.

[athisun]

Without stepping through the code to confirm, to me it looks like in BitWarden's jslib.getDomain() util.ts#L229, tldjs is returning a urlObject with domain: null (as expected since there's no valid public TLD, source), which means that on util.ts#L240, the value used for URI matching defaults to the hostname.

This is either a feature that could be added to the mobile app, or a bug to be fixed in the browser extension. I'm hoping feature.

As a temporary workaround, you can change the match detection options from the default 'Base domain' to 'Host'. This is working for my local .lan addresses now, but will likely break auto-fill on sites that share the same credentials across multiple sub-domains or ports.

[DLCIncluded]

Without stepping through the code to confirm, to me it looks like in BitWarden's jslib.getDomain() util.ts#L229, tldjs is returning a urlObject with domain: null (as expected since there's no valid public TLD, source), which means that on util.ts#L240, the value used for URI matching defaults to the hostname.

This is either a feature that could be added to the mobile app, or a bug to be fixed in the browser extension. I'm hoping feature.

As a temporary workaround, you can change the match detection options from the default 'Base domain' to 'Host'. This is working for my local .lan addresses now, but will likely break auto-fill on sites that share the same credentials across multiple sub-domains or ports.

Can confirm, the temp workaround works for me using a local domain (.nas in my case) thank you

[jvalskis]

This issue still persists in both ios and android apps and the workaround doesn't seem to work in all cases. It's very frustrating having to search for the saved password, especially when, as someone already pointed out, the application correctly saves an entry while on the -- address. It seems weird to me that there is some TLD whitelist in the app and not in the plugin. I would expect the app to work the same way that the browser plugin does.