github-starred/android
2
0
Fork 0
mirror of https://github.com/bitwarden/android.git synced 2026-03-13 13:44:36 -05:00
Code Issues 144 Packages Projects Releases 116 Wiki Activity

Local DNS URIs Identified as "--" #1336

New Issue
Closed
opened 2025-11-26 22:45:24 -06:00 by GiteaMirror · 13 comments
GiteaMirror commented 2025-11-26 22:45:24 -06:00
Owner
Copy Link

Originally created by @edomatedlogic on GitHub (Aug 21, 2021).

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".

Originally created by @edomatedlogic on GitHub (Aug 21, 2021). ## 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".
GiteaMirror commented 2025-11-26 22:45:25 -06:00
Author
Owner
Copy Link

@jamescridland commented on GitHub (Aug 22, 2021):

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

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

@jamescridland commented on GitHub (Aug 22, 2021): Can confirm this behaviour on Version: 2.11.3 (3653). I am running Android 11 on a Google Pixel 3a.
GiteaMirror commented 2025-11-26 22:45:26 -06:00
Author
Owner
Copy Link

@larena1 commented on GitHub (Aug 22, 2021):

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.

@larena1 commented on GitHub (Aug 22, 2021): 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.
GiteaMirror commented 2025-11-26 22:45:26 -06:00
Author
Owner
Copy Link

@fdisamuel commented on GitHub (Aug 23, 2021):

I have this problem too.

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

@fdisamuel commented on GitHub (Aug 23, 2021): I have this problem too. Running android 11 on MI 9 SE. Bitwarden version 2.12.0 (3742)
GiteaMirror commented 2025-11-26 22:45:26 -06:00
Author
Owner
Copy Link

@manningtelfer commented on GitHub (Aug 31, 2021):

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

@manningtelfer commented on GitHub (Aug 31, 2021): This issue is also occuring for me, on Android 11 as well as on iOS14.7 and iPadOS14.7.1
GiteaMirror commented 2025-11-26 22:45:26 -06:00
Author
Owner
Copy Link

@athisun commented on GitHub (Oct 31, 2021):

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.

@athisun commented on GitHub (Oct 31, 2021): 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](https://publicsuffix.org/list/), and since `lan` is not a valid public TLD, parsing fails.
GiteaMirror commented 2025-11-26 22:45:26 -06:00
Author
Owner
Copy Link

@jamescridland commented on GitHub (Oct 31, 2021):

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

@jamescridland commented on GitHub (Oct 31, 2021): Good catch. I've reported the lack of `.local` to the public suffix list. `.local` is defined by [RFC 6762](https://datatracker.ietf.org/doc/html/rfc6762), so is a valid public TLD. Perhaps you might star the issue over there? https://github.com/publicsuffix/list/issues/1466
GiteaMirror commented 2025-11-26 22:45:27 -06:00
Author
Owner
Copy Link

@edomatedlogic commented on GitHub (Nov 1, 2021):

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 on GitHub (Nov 1, 2021): > 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](https://publicsuffix.org/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.
GiteaMirror commented 2025-11-26 22:45:27 -06:00
Author
Owner
Copy Link

@edomatedlogic commented on GitHub (Nov 1, 2021):

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.

@edomatedlogic commented on GitHub (Nov 1, 2021): > Good catch. > > I've reported the lack of `.local` to the public suffix list. `.local` is defined by [RFC 6762](https://datatracker.ietf.org/doc/html/rfc6762), so is a valid public TLD. > > Perhaps you might star the issue over there? > > [publicsuffix/list#1466](https://github.com/publicsuffix/list/issues/1466) Looks like the maintainers at public suffix are having none of that.
GiteaMirror commented 2025-11-26 22:45:27 -06:00
Author
Owner
Copy Link

@jamescridland commented on GitHub (Nov 1, 2021):

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.

@jamescridland commented on GitHub (Nov 1, 2021): 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.
GiteaMirror commented 2025-11-26 22:45:27 -06:00
Author
Owner
Copy Link

@athisun commented on GitHub (Nov 1, 2021):

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.

@athisun commented on GitHub (Nov 1, 2021): Without stepping through the code to confirm, to me it looks like in BitWarden's `jslib.getDomain()` [util.ts#L229](https://github.com/bitwarden/jslib/blob/1bd968a0234f61e0d873da6017008db067b2e491/common/src/misc/utils.ts#L229), tldjs is returning a urlObject with `domain: null` (as expected since there's no valid public TLD, [source](https://github.com/oncletom/tld.js/blob/ae4c23b6db9cf934996a8ff748013dfff01d64e9/index.js#L83)), which means that on [util.ts#L240](https://github.com/bitwarden/jslib/blob/1bd968a0234f61e0d873da6017008db067b2e491/common/src/misc/utils.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](https://bitwarden.com/help/article/uri-match-detection/#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.
GiteaMirror commented 2025-11-26 22:45:28 -06:00
Author
Owner
Copy Link

@DLCIncluded commented on GitHub (Dec 28, 2021):

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

@DLCIncluded commented on GitHub (Dec 28, 2021): > Without stepping through the code to confirm, to me it looks like in BitWarden's `jslib.getDomain()` [util.ts#L229](https://github.com/bitwarden/jslib/blob/1bd968a0234f61e0d873da6017008db067b2e491/common/src/misc/utils.ts#L229), tldjs is returning a urlObject with `domain: null` (as expected since there's no valid public TLD, [source](https://github.com/oncletom/tld.js/blob/ae4c23b6db9cf934996a8ff748013dfff01d64e9/index.js#L83)), which means that on [util.ts#L240](https://github.com/bitwarden/jslib/blob/1bd968a0234f61e0d873da6017008db067b2e491/common/src/misc/utils.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](https://bitwarden.com/help/article/uri-match-detection/#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
GiteaMirror commented 2025-11-26 22:45:28 -06:00
Author
Owner
Copy Link

@jvalskis commented on GitHub (Mar 8, 2024):

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.

@jvalskis commented on GitHub (Mar 8, 2024): 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.
GiteaMirror commented 2025-11-26 22:45:28 -06:00
Author
Owner
Copy Link

@vvolkgang commented on GitHub (Jun 20, 2024):

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

@vvolkgang commented on GitHub (Jun 20, 2024): Issue migrated to https://github.com/bitwarden/mobile/issues/1509
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
app:authenticator
app:password-manager
bug
bug-passkey
customer-support
duplicate
enhancement
good first issue
help wanted
needs-reply
needs-response
pull-request
Mirrored from GitHub Pull Request
 question
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/android#1336
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?