bitwarden / mobile

Retired Bitwarden mobile app for iOS and Android (MAUI/Xamarin).
https://bitwarden.com
GNU General Public License v3.0
156 stars 25 forks source link

[Android] Match Detection settings misbehaving with Inline Autofill #1946

Open YZbTje3bxjESYwpMO4erlo4YQ1ddLxDPDL92f8R opened 2 years ago

YZbTje3bxjESYwpMO4erlo4YQ1ddLxDPDL92f8R commented 2 years ago

Steps To Reproduce

  1. Create two password items. First is for domain.com/test or any subpath. This needs to be set to use Match Detection as "Starts With". Then create one for domain.com (has to match prior domain). Set this url to use Match Detection "Exact"
  2. Enable Inline Autofill and Accessibility services for the quick-action tile
  3. Go to domain.com/test
  4. Try to use the inline autofill. Notice how it pulls the password item for domain.com and not the one for domain.com/test
  5. Try to use the quick setting tile. Notice how it pulls the password item for domain.com/test and not domain.com

Expected Result

The Inline Autofill should behave like the Quick Actions tile in the above example. In other words, it should respect that the domain.com password is not relevant since domain.com/test is not an exact match for domain.com, and likewise, it should see that domain.com/test is meeting the match detection for domain.com

Actual Result

I am not sure exactly what is happening because in both password items, the match detection option is failing. Yet it is still recognizing that domain.com is the base domain for domain.com/test and giving that password. It seems to work in most other cases and is only failing in this type of specific example, at least that I have noticed. Might be some sort of edge case?

Screenshots or Videos

No response

Additional Context

No response

Operating System

Android

Operating System Version

Android 12

Device

Samsung S22 Ultra

Build Version

2022.05.0 (4636)

Beta

YZbTje3bxjESYwpMO4erlo4YQ1ddLxDPDL92f8R commented 2 years ago

@creyhani I noticed this issue was marked closed, but I am still having this bug. Is it released to a beta/stable build yet?

clayadams5226 commented 2 years ago

Hey @rg9400, apologies for this getting closed without a comment that was an oversight on our part. Have you had a chance to test this on the most recent Android build? We are unable to reproduce it on our side.

YZbTje3bxjESYwpMO4erlo4YQ1ddLxDPDL92f8R commented 2 years ago

Yes, I am still having this issue on the latest build. I am going to show my exact setup. I have this URL Match Detection configured for my "Plex" item. Everything blocked out is my domain. You can see that I have the root domain as an exact match, and a variety of subfolders as Stars With match

image

This is my "Filebrowser" item. It is set to a different subfolder, with URL Detection set to Starts With as well

image

The theory is that if I go to domain.com, domain.com/tautulli, domain.com/#Stuff, then Plex item should pop up. This works as expected.

However, if I go to domain.com/filebrowser, then I expect to see the Filebrowser item pop up. This is not happening with Inline Autofill. Crucially, this works fine on Desktop and even using the Settings Tile or Autofill Overlay. Only Inline Autofill is failing and shows the Plex item. I am unable to take a screenshot of the overlay/Settings Tile, but trust me it shows the Filebrowser item correctly. So only the Inline Autofill is failing with something related to this configuration.

190051736-85689f18-e995-4d87-9964-c5e328209f52

image

clayadams5226 commented 2 years ago

Thanks for the added details @rg9400. We'll get a couple more people to take a look at this.

QO45PwjvHPBuDrfhm2s8VubYHHqVnQGBinD7lri commented 2 years ago

I am also experiencing this same issue.

I run my own nginx webserver using swag and have many domains like @rg9400

the password for https://mydomain.net has 3 URIs all set to exact

https://domain.net https://domain.net/#Homepage https://domain.net/#OrganizrLogin

I run many reverse proxied services all with similar setups e.g Tautulli

https://tautulli.domain.net is the URI that is reverse proxied. I have this set to exact or starts which both work fine When I access through Organizr it presents each app as an iframe at e.g https://domain.net/#Tautulli I set this to exact or starts with and both work as expected on my pc browser extention, but on mobile (pixel 4a and pixel 7 pro) I am given options for domain.net and not tautulli. If i swipe down and select autofill from the android settings tiles it only suggests the correct tautulli login.

GFGhMDzgpEEJmJndUtGFDO4xSJCi4ZzSNfRDEz8 commented 1 year ago

I have the same issue when using paths after my main domain. Works fine with the Chrome extension but matching is broken in Android 13 (Pixel 7 Pro)

YZbTje3bxjESYwpMO4erlo4YQ1ddLxDPDL92f8R commented 1 year ago

@clayadams5226 any update on this issue? I noticed a few others confirming this is broken on Android, and the bug request has been open for nearly a year. Thanks!

YZbTje3bxjESYwpMO4erlo4YQ1ddLxDPDL92f8R commented 1 year ago

@clayadams5226 and @creyhani any update on this? It's been open for a year, and might be related to https://github.com/bitwarden/mobile-maui/issues/578 which has been open for 4 years. This is still very cumbersome, so it would be nice to have some update on it

rxIKPQFZFzsGD3PPlBFtteRrpkzkqbWEmkaPvNU commented 8 months ago

Got the same issue, is there any fix yet? Attached picture from bitwarden forum describes it perfectly.

Login Screen