Additional category needed?
Just a suggestion.,.it seems like “App Login” almost needs needs to be a separate category. It doesn’t fit in the “Password” category, which doesn’t have a “Username” field. And it doesn’t fit in “Logins” which go to a site and autofill.
Also, if you put it in “Logins” 1Password won’t find by tapping either of the credential fields in an IOS app.
Comments
-
Hi @LarryMcJ
"Logins" is generally the right spot for most of this kind of stuff. For one, many apps also have a website where the same credentials work (or vice versa). Additionally if saved as a Login then it can be used with Password AutoFill.
Also, if you put it in “Logins” 1Password won’t find by tapping either of the credential fields in an IOS app.
If the app properly defines an "associated domain," and that domain matches their website, then it absolutely should. For apps that use a different domain you would need to add that domain to a website field on the Login item. For apps that don't define an associated domain at all we have no way of knowing which login is appropriate to fill, and so a search box is given. We'd recommend extreme caution in the latter case, as 1Password cannot offer any phishing protection in these cases.
Ben
0 -
While I agree with “most” of this, Ben, more and more apps do not have an associated website login these days...probably they’re trying to minimize support costs. I have several apps, like Kasa, that don’t have a web portal.
I’ve always kept these in the Logins category but without an associated domain the only option is copy/paste. Oh, well...it didn’t hurt to ask 🙂 Thanks for your help.
0 -
I'm not familiar with any apps that have no website whatsoever...but regardless, if they're login credentials a Login item is best. Certainly you can store login credentials in whatever item type you want, but the only way you could potentially ever fill them is using a Login item. And since that's the primary reason most people use 1Password on a daily basis, it's what I'd have to recommend as well. :) Never hurts to ask developers to add support for password autofill though. Saves them support costs from people using weak passwords they have to remember and/or fill them. ;)
0 -
Hey, brenty. These apps obviously have a website, but no place to log in. Kasa is a hugely popular app for controlling TP-Link smart devices but has no login. https://www.tp-link.com/us/kasa-smart/kasa.html
0 -
Ah gotcha. I misunderstood what you were saying. I do find it helpful to save the URL in these cases anyway though, so I can find the website if I need to. And I have on occasion found that filling suddenly worked as a result, thanks to an app update from the developer. Hopefully more will add support for autofill as time goes on. It's a really great feature. Cheers! :)
0 -
To be clear: an 'associated domain' doesn't necessarily mean a website. It is possible to have a domain and no website at all. Either way, I think what this ultimately boils down to... assuming it is true that lots of apps don't have associated domains defined, what benefit would a different category from Logins offer?
Ben
0 -
i would think it could have a username and password field and if I was trying to log into the app I could tap either field to invoke 1Password. Then it would autofill the app login fields, the same as it does now with a site login. 1Password would need a way to know which login to use...that’s where the brilliant folks at Agilebits come in 🙂
0 -
Definitely not. 1Password only fills from Login items, but will not fill from one of those if the URL of the app/website is different from what you have saved in the Login. That's an important phishing protection, as otherwise it would be easy -- especially on a mobile device -- to accidentally tell 1Password to fill your
paypal.comlogin credentials atpaypa1.com.0 -
Actually, I knew 1Password wouldn’t fill if a URL is different. I was hoping there was a way 1Password could authenticate an installed app “if” that app didn’t have a web login. I understand now that can’t happen. Thanks!
0 -
It isn't about having a website. It is about defining an 'associated domain' for the app.
To be clear: an 'associated domain' doesn't necessarily mean a website. It is possible to have a domain and no website at all.
Apple has a (technical) guide for app developers on how to do this here:
From Apple's guide:
It’s important to establish an association between domains and your app if you want to share credentials or if features in your app are based on your website.
(emphasis mine)
All apps that want to work properly with the autofill feature should define an associate domain, and in my experience most do. The majority of the handful I have that don't are ones that haven't been updated in some time (many of which actually do have a website where the same credentials work, which should be even more reason for them to update and add this).
For example, the American Express app (
AMEX) uses the associated domainm.amex. There is no website there (https://m.amex), and as such there is no way to log in there with a web browser. But if you addm.amexto a Login item for American Express we will be able to fill that item in their app. If you save a Login from within their app using the autofill feature we'll add it automagically for you.Does that help?
Ben
0 -
Perfect. BTW, I do understand the difference between a website and domain, I own several of each. I just misstated website for domain. Regardless, your explanation cleared things up completely.
So now I’ll identify the apps I use that won’t autofill and ask the developers to please associate a domain with it (in accordance with Apple’s guidance) to facilitate autofill with 1Password. Probably won’t do any good, but I’ll have tried 🙂
0
