iOS keyboard AutoFill disregards URI

[bobfatherx]

Steps To Reproduce

1. Enable Bitwarden AutoFill in Settings
2. Configure subdomains (e.g., site1.myFQDN.com, site2.myFQDN.com, etc.)
3. Create Bitwarden login and password entries for each subdomain, enter a URI, and set URI match to ‘starts with’
4. Navigate to site1, site2, and inspect the keyboard AutoFill suggestion that appears to the left of the key that invokes BitWarden’s pop up

Expected Result

AutoFill suggestion should use the URI match to suggest the matching login credentials.

Actual Result

AutoFill suggestion ignores URI and suggests the login credentials of the first alphabetical Bitwarden item with a matching host. However, clicking the key invokes the Bitwarden pop up that properly matches the subdomain. See photo examples.

Screenshots or Videos

Keyboard AutoFill displaying bw.FQDN.space instead of blueiris.FQDN.space because in the vault, accordingly, the items are named ‘Home - Bitwarden’ and ‘Home - Blue Iris’

Clicking the Bitwarden key pops up the correct site, as does using the iOS share sheet (thanks for fixing the share sheet access in the recent update!)

Additional Context

No response

Operating System

iOS

Operating System Version

15.1

Device

iPad, iPhone

Build Version

Version: 2.15.0 (1225)

Beta

• [ ] Using a pre-release version of the application.

[guyyst]

I'm not sure what your exact setup is, but after playing around with different configurations for a while I think I know what's happening. It seems like the iOS autofill is only looking at the first URI for any login entry.

When I set up myFQDN.com, site1.myFQDN.com and site2.myFQDN.com with the respective URIs and 'starts with' match detection at the first URI position, everything works fine. I get the immediate suggestion of the correct login that only requires one tap to continue: https://i.imgur.com/KdU0al5.png

But when, for example, I set up the site1.myFQDN.com login with https://site1.myFQDN.com as the second URI entry and something else as the first, iOS doesn't immediately match the login.

Again, I tested this as much as I could with my setup and haven't confirmed this suspicion by looking at the code.

[bobfatherx]

Thanks for playing around with it. I can also confirm that my issue appears to have stemmed from the first URI being for an internal IP and the second URI being for a reverse proxied host. After moving the reverse proxy host to the first URI position, sites now populate the correct login from the iOS keyboard pop up.

[guyyst]

[ ... ] the first URI being for an internal IP and the second URI being for a reverse proxied host.

Yeah same here. It's not a perfect solution since I now don't get an automatic completion on iOS for the internal IP, but since I hardly ever access that after setting up the proxy it's fine.

[snab43]

Currently having this issue with localhost:port. I have a server on http://192.168.1.100 and a bunch of docker containers all the same IP but different port numbers at the end. So an example URL would be https://192.168.1.100:8181. I set them to URI match to “host”. On my desktop it matches everything perfectly. Only the login for that docker container shows. However, on iOS the wrong one is suggested. And the issue is that even when hitting the key icon to see the list of every login, I can’t tell what’s the right one because the majority of them have the username “admin”.

[linedpaper]

Having this issue too. For me they are different entries and the match detection is set to host. It appears to not respect this and shows me every entry for the domain.

[gmcinalli]

@linedpaper Try the “starts with” matching.

[linedpaper]

@gmcinalli Thanks, that's a great workaround, but this bug has been here for so long, why can't the actual issue get fixed?

[Gerardv514]

Signed up to say I’m having the same issue. The auto fill above keyboard isn’t correct, iOS chrome shows just one incorrect match. iOS safari shows same incorrect as well but you can click open the menu and it shows all subdomains. If I click the password key on chrome, which opens a pop up of bitwarden, there it will return one exact correct match.

[katosabi]

I too have this issue; guyyst's suggestion to put the FQDN URI first makes the first match work correctly.

[Gerardv514]

@dwbit can this be pushed to the team to review? This has been a problem for a while now, and I am not able to resolve by setting the FQDN uri as the first one in order.

[Gerardv514]

@Krychaz can you reproduce this issue? Been opened for almost 2 years and it’s very annoying

[Gerardv514]

Hi @djsmith85 can you reproduce this issue? Been opened for almost 2 years and it’s very annoying

[SergeantConfused]

Hello everyone,

Thank you all for your contributions and input. The Auto-Fill suggestion on iOS uses (Base domain) as its URI match detection regardless of what the URI match detection is set to within the vault item, and that is the expected behaviour on iOS and we also mention that here; I have communicated internally about this matter and this appears to be the way iOS operates and it cannot be adjusted.

I hope this clarifies everything, and I thank you in advance for your understanding. I will now proceed and close this GitHub thread.

All the best,

[Gerardv514]

@SergeantConfused this makes no sense since apples’ built in keychain has the ability to utilize subdomains.

I switched my autofill iOS option from bitwarden to keychain in iOS settings. The iOS keyboard can properly detect and match each separate sub domain.

I’m also pretty sure at one point i never had an issue with this when I first started using bitwarden.

Where does the limitation then fall?