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 .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
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 .lan
addresses 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: