Local DNS URIs Identified as "--"

edomatedlogic commented 3 years ago

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

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.
Open a browser.
Go to the URL of the server with local-only DNS entry.
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 commented 3 years ago

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

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

larena1 commented 3 years ago

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 commented 3 years ago

I have this problem too.

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

manningtelfer commented 3 years ago

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

athisun commented 2 years ago

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 commented 2 years ago

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?

https://github.com/publicsuffix/list/issues/1466

edomatedlogic commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 7 months ago

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.

vvolkgang commented 3 months ago

Issue migrated to https://github.com/bitwarden/mobile/issues/1509

bitwarden / android