URI Match Detection 'Starts with' doesn't work in Chrome on Android

[douglasparker]

URI Match Detection doesn't work when using 'Starts with' in Chrome on Android.

For example, using the following URI: https://mail.example.com/admin

The above URI format works just fine in Firefox on Android when using 'Starts with' as the URI Match Detection rule, but no results are returned when using Chrome on Android.

This was an issue in the old mobile version as well, I just never got around to reporting it.

Works fine in Chrome on Windows.

[kspearrin]

It is working on Android by my tests, but isn't obvious because of how URLs are parsed on Android. Often times (depending on the browser and which autofill service you are using), I don't know the true URL of the page you are viewing. For example, I may only know the domain "amazon.com" or some other shorted version of the true URL that is displayed in the address bar of the browser app. Because of this, your existing URI detection rules may not work on android or you may need to add additional rules to accommodate.

[douglasparker]

I'm using a personal domain name, with a subdomain and directory path.

When attempting to use the accessibility service to autofill my login credentials, I get the following message in Bitwarden:

There are no items in your vault for example.com.

I receive this message despite being on https://mail.example.com/admin and a properly formatted 'Starts with' match detection on the entry.

I do plan to switch to Firefox, and I can confirm everything works there. It also works properly in Chrome on Windows. The only place this match detection fails seems to be while using Bitwarden in Chrome on Android.

EDIT: There is a hyphen in the base domain name. I am unsure if this may be apart of the problem or not but might be worth mentioning.

[kspearrin]

As previously mentioned, chrome doesn't show the whole URL in the address bar, so Bitwarden isn't able to match a starts with "https://mail.example.com/admin".

[douglasparker]

Ah okay, thank you!

[quthla]

As previously mentioned, chrome doesn't show the whole URL in the address bar, so Bitwarden isn't able to match a starts with "https://mail.example.com/admin".

Are you referring to the visible address bar in the browser window at the top?

[kspearrin]

Yes

[jikamens]

If Chrome on Android doesn't make the whole URL available to Bitwarden to match against, then shouldn't Bitwarden adjust how it does the matching so that vault entries which would match of the whole URL were available store up in the list of entries available for autofill?

[quthla]

@kspearrin is there any fix for this planned maybe?

[douglasparker]

@kspearrin is there any fix for this planned maybe?

I really hope there is a work around. It's annoying trying to fill these entries on mobile.

It seems like the answer to most bugs in Bitwarden is switch to Firefox. :( I just like my Chromium based browsers.

[quthla]

Yeah it's really annoying when you have multiple apps in different subfolders and need "starts with" matching

[douglasparker]

Yeah it's really annoying when you have multiple apps in different subfolders and need "starts with" matching

I use Starts with when reverse proxying a lot of apps on the same subdomain. Otherwise there ends up being a lot of autofill clutter by just matching against the hostname.

Logging into these apps on mobile is always a pain. I have to hit search every time and start typing in the app I want to fill.

Edit: Sometimes the first fill doesn't actually work, so I end up having to do the search process a second time. 🙁

[BeecherNetworks]

This problem occurs in Firefox too.

[rg9400]

I'm still having this issue on beta build 2279. It's fairly cumbersome if you are reverse proxying across multiple subfolders/subdomains where the "Starts With" match detection is the most relevant option.

[douglasparker]

Is there a chance this can be addressed in the near future? This is the only thing left that drives me absolutely insane on a daily basis.

[BeecherNetworks]

Ditto. I run a ton of services on subdomains set to match on Host, and they never match in Firefox, I have to search each time, and autofill from search is very hit and miss.

[jffernandez]

Pay attention to the next release, please, verify if that works for you too. https://github.com/bitwarden/mobile/issues/432#issuecomment-612528533 After the fix in my PR https://github.com/bitwarden/mobile/pull/830 if no results in the list, you should switch to default match on settings, but if full URL is available, the filter will be applied.

[Stephan-P]

I'd like to chime in here, as I've been experiencing the same issue with Vivaldi and Edge browsers as well.

Today's beta version 2.3.1 (2376) resolves the issue "items for --", but unfortunately does not provide a solution for this issue with the "Starts with" url matching option. If I set the matching option to "Starts with" no items are found in the database. They are properly found when using options "Base domain" or "Host name".

[quthla]

As a workaround, you can either set a regex match which optionally matches the scheme or just another starts with match without the scheme prepended.

That's probably your best bet as I've reported this issue more than a year ago but nothing happened since then.

[jffernandez]

I think it's working now, as nice as it can work on Android, because the APP can not get the full URL from the page in your navigator, only the protocol and server, that is, for example: https://github.com even it will get the host if present as https://www.github.com

So, if you try to login, for example at Github, your full URL will be: https://github.com/login?return_to=... and maybe that is what you have on your database (or maybe https://github.com/login)

Finally, when Bitwarden check if your current URL (https://github.com/ for Bitwarden, because of the stated above) "startsWith" https://github.com/login (or whatever you have in your database) it's a False, so will be not found. It will work if you store your github login with URI: https://github.com

In a computer, Bitwarden will get the full URL of the page on your browser, so it works.

You can try "Host" as your match method, it works great for me!

[quthla]

I think it's the other way around. In Chrome on Android there's no scheme in the url and if you've got a vault item with starts with https://github.com but the url Bitwarden reads from Chrome is github.com, it will not match this.

[jffernandez]

Try to shorten the URI you have saved in your database, delete all after the domain, that worked for me. And on the debugger I got the scheme from Android emulator (maibe it depends on the service too, I'm using Auto-Fill, not Accesibility one) Anyway, Host match is now working, and that will solve your problem, give it a try!

[douglasparker]

Using host as a match method isn't ideal when you reverse proxy multiple applications on your domain.

For example:

• https://media.example.com
• https://media.example.com/requests
• https://media.examole.com/sonarr
• https://media.example.com/radarr
• https://media.example.com/lidarr
• https://media.example.com/tautulli
• https://media.example.com/nzbget
• https://media.example.com/qbittorrent

My use case really needs Starts with detection to work.

At this point I am considering multiple subdomains as a work around.

[quthla]

Try to shorten the URI you have saved in your database, delete all after the domain, that worked for me. And on the debugger I got the scheme from Android emulator (maibe it depends on the service too, I'm using Auto-Fill, not Accesibility one) Anyway, Host match is now working, and that will solve your problem, give it a try!

It seems you don't understand the actual issue. It is not about what's after the domain but rather what's before. Check the address bar in Chrome. There's no url scheme to be matched. And yes, it might work with autofill instead of accessibility, but autofill is hopelessly broken in Chrome and will just randomly stop working, so I've got that turned off.

EDIT: I've just tested it with only autofill enabled and accessbility disabled. It won't work there either with starts with match detection on newest beta. Even worse, autofill seems to be cutting off the whole path of the url.

Using host as a match method isn't ideal when you reverse proxy multiple applications on your domain.

For example:

• https://media.example.com
• https://media.example.com/requests
• https://media.examole.com/sonarr
• https://media.example.com/radarr
• https://media.example.com/lidarr
• https://media.example.com/tautulli
• https://media.example.com/nzbget
• https://media.example.com/qbittorrent

My use case really needs Starts with detection to work.

At this point I am considering multiple subdomains as a work around.

You can use my workaround

[douglasparker]

@quthla I'll take a look at the work around you mentioned above later today. Thanks for the tip!

Edit: I was unable to get a match using regex and a second Starts with entry without the scheme. Regex: ^https:\/\/media.example.com\/sonarr\/* Starts with (no scheme): media.example.com/sonarr/

At this point the only workaround I see is to use multiple subdomains and match via hostname.

I would really like it if Starts with could be made to work on mobile.

[douglasparker]

As previously mentioned, chrome doesn't show the whole URL in the address bar, so Bitwarden isn't able to match a starts with "https://mail.example.com/admin".

Are there any possible workarounds to make Starts with functionality work on Chrome?

[rg9400]

Yeah, I tried just doing Starts With on domain.com/mypage with no luck either. This functionality seems to be completely broken on Android, and I have to use a different matching scheme to make it work (which is not ideal at all).

[quthla]

You must turn off autofill service and only use the accessibility service.

^(https?://)?domain.com/path/

This is the regex I'm using with different paths on the same domain.

[douglasparker]

You must turn off autofill service and only use the accessibility service.

^(https?://)?domain.com/path/

This is the regex I'm using with different paths on the same domain.

Your regex expression works, as long as the autofill service is disabled like you said. :)

Thanks for the workaround. Still hoping for an official fix.

[douglasparker]

As it turns out, disabling the autofill framework and using a regex expression doesn't work for me, simply because I require the use of the autofill framework to get an autofill option when using HTTP Basic Auth.

In a nutshell, you don't automatically get an autofill prompt for HTTP Basic Auth prompts. However, you can tap and hold on the username / password input and then tap ... and there will be an Autofill option. This is essential as I have a few non-public web services secured by HTTP Basic Auth and use randomized passwords. To autofill using this method, it's required to have the autofill framework enabled.

In the case of having the autofill framework disabled (So regex expressions work), switching to the Bitwarden app and back to fill in this rare case isn't reasonable, because it results in the prompt going away and the page returning 401 Authorization Required. Normally not a big deal either, but the username is randomized too. i.e. netdata-{randomnumbers}. Which means I need to copy the username and password since the username isn't as memorable.

Ultimately there should be an official workaround within the Bitwarden codebase to make the functionality work on browsers that do not show the full URL in the address bar. I'm not even sure if it's possible, but a man can only hope.

Bitwarden is near perfect in every way for me as of late, especially now that the accessibility service uses the overlay that the autofill framework uses. Just a few more edge cases to polish up for those of us that are in the tech crowd.

[rg9400]

Unfortunately, the workaround does not work for me either. This is a fairly big bug on the mobile app for Bitwarden, and hopefully it can be fixed soon.