github-starred/android
2
0
Fork 0
mirror of https://github.com/bitwarden/android.git synced 2026-05-06 07:48:22 -05:00
Code Issues 1.1k Packages Projects Releases 122 Wiki Activity

[GH-ISSUE #578] URI Match Detection 'Starts with' doesn't work in Chrome on Android #13437

New Issue
Closed
opened 2026-04-14 23:03:37 -05:00 by GiteaMirror · 42 comments
GiteaMirror commented 2026-04-14 23:03:37 -05:00
Owner
Copy Link

Originally created by @ghost on GitHub (Aug 12, 2019).
Original GitHub issue: https://github.com/bitwarden/android/issues/578

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.

Originally created by @ghost on GitHub (Aug 12, 2019). Original GitHub issue: https://github.com/bitwarden/android/issues/578 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.
GiteaMirror commented 2026-04-14 23:03:38 -05:00
Author
Owner
Copy Link

@kspearrin commented on GitHub (Aug 14, 2019):

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.

<!-- gh-comment-id:521231187 --> @kspearrin commented on GitHub (Aug 14, 2019): 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.
GiteaMirror commented 2026-04-14 23:03:38 -05:00
Author
Owner
Copy Link

@ghost commented on GitHub (Aug 14, 2019):

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.

<!-- gh-comment-id:521368196 --> @ghost commented on GitHub (Aug 14, 2019): 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.
GiteaMirror commented 2026-04-14 23:03:38 -05:00
Author
Owner
Copy Link

@kspearrin commented on GitHub (Aug 14, 2019):

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

<!-- gh-comment-id:521373587 --> @kspearrin commented on GitHub (Aug 14, 2019): 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".
GiteaMirror commented 2026-04-14 23:03:39 -05:00
Author
Owner
Copy Link

@ghost commented on GitHub (Aug 14, 2019):

Ah okay, thank you!

<!-- gh-comment-id:521412037 --> @ghost commented on GitHub (Aug 14, 2019): Ah okay, thank you!
GiteaMirror commented 2026-04-14 23:03:39 -05:00
Author
Owner
Copy Link

@quthla commented on GitHub (Oct 7, 2019):

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?

<!-- gh-comment-id:539037524 --> @quthla commented on GitHub (Oct 7, 2019): > 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?
GiteaMirror commented 2026-04-14 23:03:40 -05:00
Author
Owner
Copy Link

@kspearrin commented on GitHub (Oct 7, 2019):

Yes

<!-- gh-comment-id:539043408 --> @kspearrin commented on GitHub (Oct 7, 2019): Yes
GiteaMirror commented 2026-04-14 23:03:40 -05:00
Author
Owner
Copy Link

@jikamens commented on GitHub (Jan 12, 2020):

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?

<!-- gh-comment-id:573375752 --> @jikamens commented on GitHub (Jan 12, 2020): 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?
GiteaMirror commented 2026-04-14 23:03:41 -05:00
Author
Owner
Copy Link

@quthla commented on GitHub (Feb 4, 2020):

@kspearrin is there any fix for this planned maybe?

<!-- gh-comment-id:582035908 --> @quthla commented on GitHub (Feb 4, 2020): @kspearrin is there any fix for this planned maybe?
GiteaMirror commented 2026-04-14 23:03:41 -05:00
Author
Owner
Copy Link

@ghost commented on GitHub (Feb 4, 2020):

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

<!-- gh-comment-id:582038525 --> @ghost commented on GitHub (Feb 4, 2020): > @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.
GiteaMirror commented 2026-04-14 23:03:42 -05:00
Author
Owner
Copy Link

@quthla commented on GitHub (Feb 4, 2020):

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

<!-- gh-comment-id:582039842 --> @quthla commented on GitHub (Feb 4, 2020): Yeah it's really annoying when you have multiple apps in different subfolders and need "starts with" matching
GiteaMirror commented 2026-04-14 23:03:42 -05:00
Author
Owner
Copy Link

@ghost commented on GitHub (Feb 4, 2020):

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

<!-- gh-comment-id:582046692 --> @ghost commented on GitHub (Feb 4, 2020): > 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. 🙁
GiteaMirror commented 2026-04-14 23:03:43 -05:00
Author
Owner
Copy Link

@BeecherNetworks commented on GitHub (Mar 10, 2020):

This problem occurs in Firefox too.

<!-- gh-comment-id:597348425 --> @BeecherNetworks commented on GitHub (Mar 10, 2020): This problem occurs in Firefox too.
GiteaMirror commented 2026-04-14 23:03:44 -05:00
Author
Owner
Copy Link

@rg9400 commented on GitHub (Apr 20, 2020):

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.

<!-- gh-comment-id:616826599 --> @rg9400 commented on GitHub (Apr 20, 2020): 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.
GiteaMirror commented 2026-04-14 23:03:47 -05:00
Author
Owner
Copy Link

@ghost commented on GitHub (Apr 20, 2020):

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.

<!-- gh-comment-id:616858212 --> @ghost commented on GitHub (Apr 20, 2020): 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.
GiteaMirror commented 2026-04-14 23:03:47 -05:00
Author
Owner
Copy Link

@BeecherNetworks commented on GitHub (Apr 20, 2020):

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.

<!-- gh-comment-id:616870413 --> @BeecherNetworks commented on GitHub (Apr 20, 2020): 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.
GiteaMirror commented 2026-04-14 23:03:48 -05:00
Author
Owner
Copy Link

@jffernandez commented on GitHub (Apr 21, 2020):

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.

<!-- gh-comment-id:616998153 --> @jffernandez commented on GitHub (Apr 21, 2020): 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.
GiteaMirror commented 2026-04-14 23:03:49 -05:00
Author
Owner
Copy Link

@Stephan-P commented on GitHub (Apr 30, 2020):

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

<!-- gh-comment-id:621646895 --> @Stephan-P commented on GitHub (Apr 30, 2020): 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".
GiteaMirror commented 2026-04-14 23:03:49 -05:00
Author
Owner
Copy Link

@quthla commented on GitHub (Apr 30, 2020):

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.

<!-- gh-comment-id:621778222 --> @quthla commented on GitHub (Apr 30, 2020): 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.
GiteaMirror commented 2026-04-14 23:03:50 -05:00
Author
Owner
Copy Link

@jffernandez commented on GitHub (Apr 30, 2020):

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!

<!-- gh-comment-id:622001944 --> @jffernandez commented on GitHub (Apr 30, 2020): 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!**
GiteaMirror commented 2026-04-14 23:03:50 -05:00
Author
Owner
Copy Link

@quthla commented on GitHub (Apr 30, 2020):

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.

<!-- gh-comment-id:622007709 --> @quthla commented on GitHub (Apr 30, 2020): 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.
GiteaMirror commented 2026-04-14 23:03:51 -05:00
Author
Owner
Copy Link

@jffernandez commented on GitHub (Apr 30, 2020):

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!

<!-- gh-comment-id:622038405 --> @jffernandez commented on GitHub (Apr 30, 2020): 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!
GiteaMirror commented 2026-04-14 23:03:51 -05:00
Author
Owner
Copy Link

@ghost commented on GitHub (Apr 30, 2020):

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

For example:

My use case really needs Starts with detection to work.

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

<!-- gh-comment-id:622046811 --> @ghost commented on GitHub (Apr 30, 2020): 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.
GiteaMirror commented 2026-04-14 23:03:51 -05:00
Author
Owner
Copy Link

@quthla commented on GitHub (Apr 30, 2020):

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:

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

<!-- gh-comment-id:622056024 --> @quthla commented on GitHub (Apr 30, 2020): > 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
GiteaMirror commented 2026-04-14 23:03:52 -05:00
Author
Owner
Copy Link

@ghost commented on GitHub (Apr 30, 2020):

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

<!-- gh-comment-id:622067973 --> @ghost commented on GitHub (Apr 30, 2020): @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.
GiteaMirror commented 2026-04-14 23:03:52 -05:00
Author
Owner
Copy Link

@ghost commented on GitHub (May 1, 2020):

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?

<!-- gh-comment-id:622187028 --> @ghost commented on GitHub (May 1, 2020): > 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?
GiteaMirror commented 2026-04-14 23:03:53 -05:00
Author
Owner
Copy Link

@rg9400 commented on GitHub (May 1, 2020):

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

<!-- gh-comment-id:622189736 --> @rg9400 commented on GitHub (May 1, 2020): 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).
GiteaMirror commented 2026-04-14 23:03:53 -05:00
Author
Owner
Copy Link

@quthla commented on GitHub (May 1, 2020):

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.

<!-- gh-comment-id:622197251 --> @quthla commented on GitHub (May 1, 2020): 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.
GiteaMirror commented 2026-04-14 23:03:53 -05:00
Author
Owner
Copy Link

@ghost commented on GitHub (May 1, 2020):

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.

<!-- gh-comment-id:622200469 --> @ghost commented on GitHub (May 1, 2020): > 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.
GiteaMirror commented 2026-04-14 23:03:53 -05:00
Author
Owner
Copy Link

@ghost commented on GitHub (May 3, 2020):

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.

<!-- gh-comment-id:623098719 --> @ghost commented on GitHub (May 3, 2020): 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.
GiteaMirror commented 2026-04-14 23:03:54 -05:00
Author
Owner
Copy Link

@rg9400 commented on GitHub (May 5, 2020):

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.

<!-- gh-comment-id:624074809 --> @rg9400 commented on GitHub (May 5, 2020): 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.
GiteaMirror commented 2026-04-14 23:03:54 -05:00
Author
Owner
Copy Link

@BeecherNetworks commented on GitHub (May 5, 2020):

I think I've mentioned previously but my problem is more general and I think others in the thread are experiencing the same thing: Nothing with a subdomain is found, no matter what the settings. For developers and hosts working on dozens of sites and servers, it's an absolute pain.

<!-- gh-comment-id:624207190 --> @BeecherNetworks commented on GitHub (May 5, 2020): I think I've mentioned previously but my problem is more general and I think others in the thread are experiencing the same thing: **Nothing** with a subdomain is found, no matter what the settings. For developers and hosts working on dozens of sites and servers, it's an absolute pain.
GiteaMirror commented 2026-04-14 23:03:55 -05:00
Author
Owner
Copy Link

@quthla commented on GitHub (May 5, 2020):

@BeecherNetworks try with only accessibility service turned on and make sure you then get the accessibility popup and not the autofill one. They look slightly different.

<!-- gh-comment-id:624274844 --> @quthla commented on GitHub (May 5, 2020): @BeecherNetworks try with only accessibility service turned on and make sure you then get the accessibility popup and not the autofill one. They look slightly different.
GiteaMirror commented 2026-04-14 23:03:55 -05:00
Author
Owner
Copy Link

@BeecherNetworks commented on GitHub (May 7, 2020):

With Accessibility it only works some of the time. When it does, Bitwarden does find the correct item, but only when I click through, it isn't available from the popup.

I've found triggering pretty wonky lately sometimes too, sometimes it works when I click the username field, sometimes only the password field, and sometimes not at all.

The new fashion for two-stage logins is causing problems too. I don't really get the fascination for this. A username and password are a username and password, why put it on two bloody pages!?

<!-- gh-comment-id:625414792 --> @BeecherNetworks commented on GitHub (May 7, 2020): With Accessibility it only works some of the time. When it does, Bitwarden does find the correct item, but only when I click through, it isn't available from the popup. I've found triggering pretty wonky lately sometimes too, sometimes it works when I click the username field, sometimes only the password field, and sometimes not at all. The new fashion for two-stage logins is causing problems too. I don't really get the fascination for this. A username and password are a username and password, why put it on two bloody pages!?
GiteaMirror commented 2026-04-14 23:03:56 -05:00
Author
Owner
Copy Link

@rg9400 commented on GitHub (Jun 17, 2020):

Any updates on this? I've been finding the mobile app fairly frustrating to use because of this bug since it seems most of the sites I am populating passwords on mobile tend to be these subfolders that refuse to match using the "Starts With" detection method.

<!-- gh-comment-id:645543331 --> @rg9400 commented on GitHub (Jun 17, 2020): Any updates on this? I've been finding the mobile app fairly frustrating to use because of this bug since it seems most of the sites I am populating passwords on mobile tend to be these subfolders that refuse to match using the "Starts With" detection method.
GiteaMirror commented 2026-04-14 23:03:56 -05:00
Author
Owner
Copy Link

@quthla commented on GitHub (Dec 16, 2020):

@fmeum as you're pretty knowledgeable in regards to autofill: is it correct that the native autofill API in Android does not provide the url path to the autofill service?

<!-- gh-comment-id:746411258 --> @quthla commented on GitHub (Dec 16, 2020): @fmeum as you're pretty knowledgeable in regards to autofill: is it correct that the native autofill API in Android does not provide the url path to the autofill service?
GiteaMirror commented 2026-04-14 23:03:57 -05:00
Author
Owner
Copy Link

@fmeum commented on GitHub (Dec 16, 2020):

@fmeum as you're pretty knowledgeable in regards to autofill: is it correct that the native autofill API in Android does not provide the url path to the autofill service?

Yes, that is correct. The content of the URL bar goes through setWebDomain, which extracts only the scheme and the host. This makes sense as it prevents accidentally leaking secrets contained in the URL and all security guarantees offered by the web platform only apply to origins (scheme + host + port) anyway.

<!-- gh-comment-id:746585857 --> @fmeum commented on GitHub (Dec 16, 2020): > @fmeum as you're pretty knowledgeable in regards to autofill: is it correct that the native autofill API in Android does not provide the url path to the autofill service? Yes, that is correct. The content of the URL bar goes through [setWebDomain](https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/java/android/app/assist/AssistStructure.java;l=1436;drc=master), which extracts only the scheme and the host. This makes sense as it prevents accidentally leaking secrets contained in the URL and all security guarantees offered by the web platform only apply to origins (scheme + host + port) anyway.
GiteaMirror commented 2026-04-14 23:03:57 -05:00
Author
Owner
Copy Link

@MexHigh commented on GitHub (Mar 12, 2022):

Just to add something that might be useful to fix this:

It seems like the "starts with" matching with the URL from the browser starts here: 2e8824ce05/src/Core/Services/CipherService.cs (L409-L415)

--> url.startsWith(u.Uri)

  • with u being the "match URL" object here (u.Uri is the string like "example.org/whatever" and u.Match is the explicit matching method set for this URL or the default matching method).
  • and with url being passed to the function in this function:

2e8824ce05/src/Android/Autofill/AutofillHelpers.cs (L146)

... which is, in turn, called here with a new instance of the Parser class which contains the URL which is later checked against u.Uri.

2e8824ce05/src/Android/Autofill/AutofillService.cs (L73)

The value of parser.Uri is calculated here:

2e8824ce05/src/Android/Autofill/Parser.cs (L32-L55)

... with Website being composed like:

2e8824ce05/src/Android/Autofill/Parser.cs (L155)

Conclusion

So yes, the URL that gets matched with the specified URL(s) in the password records only contains the scheme and domain. Appending the path to the Website variable would probably solve the problem.

Sadly, I'm not able to resolve this myself, as my C# is not that good (just about good enough to understand what happens here). But maybe this is useful for someone capable of fixing this.

<!-- gh-comment-id:1065885574 --> @MexHigh commented on GitHub (Mar 12, 2022): Just to add something that might be useful to fix this: It seems like the "starts with" matching with the URL from the browser starts here: https://github.com/bitwarden/mobile/blob/2e8824ce05a1b6cd6584e993114f8c956c6279ed/src/Core/Services/CipherService.cs#L409-L415 --> `url.startsWith(u.Uri)` - with `u` being the "match URL" object here (`u.Uri` is the string like "example.org/whatever" and `u.Match` is the explicit matching method set for this URL or the default matching method). - and with `url` being passed to the function in this function: https://github.com/bitwarden/mobile/blob/2e8824ce05a1b6cd6584e993114f8c956c6279ed/src/Android/Autofill/AutofillHelpers.cs#L146 ... which is, in turn, called here with a new instance of the `Parser` class which contains the URL which is later checked against `u.Uri`. https://github.com/bitwarden/mobile/blob/2e8824ce05a1b6cd6584e993114f8c956c6279ed/src/Android/Autofill/AutofillService.cs#L73 The value of `parser.Uri` is calculated here: https://github.com/bitwarden/mobile/blob/2e8824ce05a1b6cd6584e993114f8c956c6279ed/src/Android/Autofill/Parser.cs#L32-L55 ... with `Website` being composed like: https://github.com/bitwarden/mobile/blob/2e8824ce05a1b6cd6584e993114f8c956c6279ed/src/Android/Autofill/Parser.cs#L155 ### Conclusion So yes, the URL that gets matched with the specified URL(s) in the password records only contains the scheme and domain. Appending the path to the `Website` variable would probably solve the problem. Sadly, I'm not able to resolve this myself, as my C# is not that good (just about good enough to understand what happens here). But maybe this is useful for someone capable of fixing this.
GiteaMirror commented 2026-04-14 23:03:58 -05:00
Author
Owner
Copy Link

@pabohoney1 commented on GitHub (Jul 17, 2023):

Adding a comment to bump this up, this seems like a silly bug to have and also seems like it should be a quick fix.

<!-- gh-comment-id:1638218294 --> @pabohoney1 commented on GitHub (Jul 17, 2023): Adding a comment to bump this up, this seems like a silly bug to have and also seems like it should be a quick fix.
GiteaMirror commented 2026-04-14 23:03:58 -05:00
Author
Owner
Copy Link

@DawidPietrykowski commented on GitHub (Dec 24, 2023):

I looked for this issue since I was having problems with Bitwarden autofilling passwords to my selfhosted services which have domains like:
service1.domain.com
service2.domain.com

After reading @MexHigh 's findings I tried to implement appending the path to the domain, but unfortunately I think it may not be possible.

Bitwarden relies on Android API to provide the AutoFillService with information about the app, which in case of a browser is WebSchema and WebDomain.

Citing the documentation from the API docs, WebDomain doesn't contain path:

domain-only part of the document. For example, if the full URL is https://example.com/login?user=my_user, it returns example.com. This value may be null.

It seems like there's no way to get the path.

I did find a solution to my problem though and in case anyone faced similar issues I will include it here.

My Bitwarden entries had the url match options set to "Starts with" (which seemed to make sense at that time) and had URLs like: https://service1.domain.com/. Because of that "/" at the end the android app wasn't able to match it since it's part of the path not the domain.

The workaround on the user side is to remove that slash at the end or change matching type to "Host".

I do think however that Bitwarden should match that URL since "/" is essentially the same as "" in terms of website's path. We could then append "/" to the Website @MexHigh mentioned and the problem would be fixed.

I believe it to be a good workaround that doesn't compromise security and increases usability, but I'd love to hear other people's opinions on the matter.

<!-- gh-comment-id:1868395545 --> @DawidPietrykowski commented on GitHub (Dec 24, 2023): I looked for this issue since I was having problems with Bitwarden autofilling passwords to my selfhosted services which have domains like: service1.domain.com service2.domain.com After reading @MexHigh 's findings I tried to implement appending the path to the domain, but unfortunately I think it may not be possible. Bitwarden relies on Android API to provide the AutoFillService with information about the app, which in case of a browser is WebSchema and WebDomain. Citing the documentation from [the API docs](https://developer.android.com/reference/android/app/assist/AssistStructure.ViewNode#getWebDomain()), WebDomain doesn't contain path: > domain-only part of the document. For example, if the full URL is https://example.com/login?user=my_user, it returns example.com. This value may be null. It seems like there's no way to get the path. I did find a solution to my problem though and in case anyone faced similar issues I will include it here. My Bitwarden entries had the url match options set to "Starts with" (which seemed to make sense at that time) and had URLs like: https://service1.domain.com/. Because of that "/" at the end the android app wasn't able to match it since it's part of the path not the domain. The workaround on the user side is to remove that slash at the end or change matching type to "Host". I do think however that Bitwarden should match that URL since "/" is essentially the same as "" in terms of website's path. We could then append "/" to the Website @MexHigh mentioned and the problem would be fixed. I believe it to be a good workaround that doesn't compromise security and increases usability, but I'd love to hear other people's opinions on the matter.
GiteaMirror commented 2026-04-14 23:03:58 -05:00
Author
Owner
Copy Link

@Neurology0443 commented on GitHub (May 28, 2024):

Somehow the same issue on Android 13 with Firefox beta 125.0b9. My own self-signed domains on mobile with 'start with' don't work as expected (On Linux, MacOS, Windows everything works as expected).

@DawidPietrykowski workaround (thanks by the way !!!) works but some urls need more than that

e.g.: https://pihole.myown.domain/admin/login.php needs to be shorted to https://pihole.myown.domain in the URI part with 'start with'.

Also I found out that when I add the URI first with my phone to bitwarden, it works correctly on all devices.

<!-- gh-comment-id:2135847151 --> @Neurology0443 commented on GitHub (May 28, 2024): Somehow the same issue on Android 13 with Firefox beta 125.0b9. My own self-signed domains on mobile with 'start with' don't work as expected (On Linux, MacOS, Windows everything works as expected). @DawidPietrykowski workaround (thanks by the way !!!) works but some urls need more than that e.g.: https://pihole.myown.domain/admin/login.php needs to be shorted to https://pihole.myown.domain in the URI part with 'start with'. Also I found out that when I add the URI first with my phone to bitwarden, it works correctly on all devices.
GiteaMirror commented 2026-04-14 23:03:59 -05:00
Author
Owner
Copy Link

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

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

<!-- gh-comment-id:2181551923 --> @vvolkgang commented on GitHub (Jun 20, 2024): Issue migrated to https://github.com/bitwarden/mobile/issues/578
GiteaMirror commented 2026-04-14 23:03:59 -05:00
Author
Owner
Copy Link

@don-dolarson commented on GitHub (Oct 15, 2024):

Bump. It's also a problem for regular expression on Bitwarden on Android, both the old stable and beta. Is this anything you look at or never gonna be fixed? Everything after the slash / doesn't work. The same for 'start with' rule.

^(http|https)://example.* works ^(http|https)://example.*/ and anything after the slash not.
No problem for Firefox based forks running Linux or Windows.

<!-- gh-comment-id:2414545430 --> @don-dolarson commented on GitHub (Oct 15, 2024): Bump. It's also a problem for regular expression on Bitwarden on Android, both the old stable and beta. Is this anything you look at or never gonna be fixed? Everything after the slash / doesn't work. The same for 'start with' rule. ^(http|https)://example\.* works ^(http|https)://example\.*/ and anything after the slash not. No problem for Firefox based forks running Linux or Windows.
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#13437
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?