Thanks for the ping, I actually had this post bookmarked for review later on so this helped bring it to my forefront.
Unfortunately I’ve never come across this issue similarly within my internal networks. My home network is using a personal valid domain.tld and all internal devices have linked hostnames for my internal subdomain. Our work’s network is a .local which as it appears in the linked
seems to be a valid public suffix per the comment
jamescridland commented on Oct 31, 2021
Good catch.
I’ve reported the lack of
.localto the public suffix list..localis defined by RFC 6762, so is a valid public TLD.Perhaps you might star the issue over there?
Though I do not see this on the public suffix list used, and in the linked issue the maintainers closed this as “
wontfix”
This perhaps could be explained in this comment further down in the post.
As a temporary workaround, you can change the match detection options from the default ‘Base domain’ to ‘Host’. This is working for my local
.lanaddresses now, but will likely break auto-fill on sites that share the same credentials across multiple sub-domains or ports.
Referencing my logins for work they either have URIs set for the pure https:Hostname:port or https:Hostname.domain.local:port with match detection also set to Host.
I believe this was due to some machines running multiple services on the same Hostname but with different ports i.e https:Machine1.domain.local:8080 & https:Machine1.domain.local:8443, etc.
@justarandomsysadmin Perhaps you can test your http://gitlab.whateverinternal.lan your login is set to and test to see if the Host match detection will work for you?
While I don’t currently have any HA setup, I do have a few internal services running behind a reverse proxy and some others that are not. As mentioned I use the Host detection for internal services as the standard Base domain function would match all different logins for separate services from sub-domains, as expected from the documentation.
I.e machine1.corp.domain.tld & machine1.corp.domain.tld
The Host option allows for Bitwarden to separate logins for the separate internal services.
One last thing I can possibly think of would be to check your URI matching, if it is set to your default Starts with as you say. Possibly check for any discrepancies in the URI such as a trailing /, according to https://bitwarden.com/help/uri-match-detection/#starts-with
For example, if the URI
https://sub.domain.com/path/uses starts with match detection:
URL Auto-fill? https://sub.domain.com/path (absent trailing slash)