Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] User defined service URLs #40

Open
ubergeek77 opened this issue Nov 13, 2023 · 2 comments
Open

[Feature Request] User defined service URLs #40

ubergeek77 opened this issue Nov 13, 2023 · 2 comments

Comments

@ubergeek77
Copy link

ubergeek77 commented Nov 13, 2023

(Apologies if I missed something and this use case is already covered, would be very happy to know there is a solution to this already 😅)

Mooltifill, to my knowledge, doesn't take into account cases where the URL calculated from the package name, subdomain or not, is not the same URL that a user would have saved to log into a service from a PC browser. To provide some examples:

I have a protonmail.com credential saved in my Mooltipass, but the app package name makes Mooltifill search for protonmail.ch, which to my knowledge has never been a URL serving a login page. And now with Proton's new SSO, you would actually sign in with proton.me credentials for newer accounts. You also use the same account for the ProtonVPN app, which has a completely different package name.

For federated apps, like Mastodon, the user would likely log in with an instance's URL, or sometimes even their own, and not the URL autogenerated from the package name.

For my Synology apps, I have my credentials under a custom domain, so I can't use Mooltifill to log on.

What I would like is the ability to type in the URL to use in Mooltifill before it sends the request to the device, with a way to save multiple "aliases" for an app that the user can click when requesting a credential. This avoids situations where Mooltifill is not usable if the service changes domain names for whatever reason.

As an example of what a solution might look like: the first time I log in to the ProtonMail app, I would click the Mooltifill autofill bubble, then select some new option that says "proton.ch is not correct, add alias." Then I would add protonmail.com as an "alias." Then I would be able to look up the credential with this and log in.

Let's say I log out and want to log in again, but this time with a proton.me account. Rather than replace the protonmail.com alias, I would add a second one, and now for all future logins, I would be able to pick which of these URLs I want to use to retrieve the credential from the device.

I think some of Moolticute's settings would alleviate part of this issue, but every time the user needs to tweak the domain to log in to an app, they would have to find a PC and make that change first.

@limpkin
Copy link
Contributor

limpkin commented Nov 14, 2023

oh that's a tricky one... maybe in that case it'd be better to define aliases inside your mini BLE DB no?

@ubergeek77
Copy link
Author

ubergeek77 commented Nov 14, 2023

That could be a potential workaround, but it would require the user to either:

  • Have advance knowledge of the package names of all apps they intend to use with Mooltifill, then add those aliases ahead of time; or:
  • Attempt to log in to an app, see the generated URL, find a PC, add the alias via Moolticute, save, then return to the phone

The first case isn't very user friendly, because discovering the app package name is not always so easy. Most of the time the only quick option is to get it from the Play Store URL in the browser.

For both cases, if I have to manually add an alias into Moolticute on a per-app basis, for a login flow that I won't be using frequently, I am better off just having the Mooltipass type manually. This basically makes the convenience of using Mooltifill mostly irrelevant, sadly.

Also, if I am not mistaken, Moolticute only supports "duplicated" credentials on a subdomain basis, not a domain basis, meaning this approach of creating aliases manually would result in many duplicated credentials on my device.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants