URL address for logins: best practice?

jimthing

Is there a recommended practice for which level of a URL would be best to store for Logins, given URL's can be formatted so many ways?

eg. Which of these would be best?
...............................................................................................................................................................

website.com
www.website.com
https://website.com
https://www.website.com

website.com/loginpage
www.website.com/loginpage
https://website.com/loginpage
https://www.website.com/loginpage

website.com/loginpage-skdjnba/kdjn/askdnas/djklasdjbnsadjndkasdnkjsdnjasjdnaskd
www.website.com/loginpage-skdjnba/kdjn/askdnas/djklasdjbnsadjndkasdnkjsdnjasjdnaskd
https://website.com/loginpage-skdjnba/kdjn/askdnas/djklasdjbnsadjndkasdnkjsdnjasjdnaskd
https://www.website.com/loginpage-skdjnba/kdjn/askdnas/djklasdjbnsadjndkasdnkjsdnjasjdnaskd

...............................................................................................................................................................
Obviously you could save all/some of them in 1P, but would the 1P login be recognised for all of them if you just stored, say website.com (or perhaps www.website.com would be better?)?

Presumably the non-www would be the best as the vanilla website.com is the TLD...? And https bit can be cut off as 1P presumably automatically enters this secure version, so is redundant?

To confuse things further, some sites allow both the www & non-www to be used, others use one or the other?! It's just messy to have multiple variants of the same URL if you don't need to, hence me asking.

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

Lars

@jimthing - the recommended practice is to allow whatever URL 1Password's capture grabs when you save a new Login item. The big exception to that is when a site has a different page for registration than for login. In such cases, I usually skip 1Password's offer to save the login on the registration page, finish my initial sign-up, then sign OUT and visit the site's dedicated sign-in page that contains only my username/password, paste in the password I just generated, and then allow 1Password to save whatever format of URL it captures. And yes, it can vary from site to site. If you ever really have trouble with a site, the go-to solution is the instructions to manually save a login. I'd recommend all of that over trying to manually edit your login item URLs to conform to any one of the previous standards. If you forced me to choose, I'd say the HTTPS options, since most sites will (at least semi-) gracefully fail over to plain-vanilla HTTP if they don't have TLS sign-in pages, but here again, not every site uses the www subdomain, so making all your Login items use that might result in some broken ones. In general, let 1Password do the decision-making, since it's capturing this information directly. If it doesn't work at a given site, well, that's what we're here for -- let us know and we'll try to address it.

jimthing

@Lars - Thanks for the response.
.................................................................
re. exact URL address to use:

On thinking about it, I presume users want 1P to capture the exact login page address(es) the website uses, so that if they do the "open and fill" option, the exact login page opens and fills correctly?

So you don't want, say www.microsoft.com but you want the exact page, say www.microsoft.com/login

And presumably for large companies (like Microsoft), you want to capture each login page you use on their site(s), eg:

www.microsoft.com/login
live.microsoft.com/login
shop.microsoft.com/login
...etc...

.................................................................
re. TLS or not (https vs. http):

I guess most sites would use the secure version by now, especially for logins (one hopes!).

So users could either:

a) Save it as the plain www.microsoft.com/login (or microsoft.com/login, if the site doesn't use the www subdomain) letting 1P automatically add the https for you, and only save http to those (hopefully few!) sites that use an insecure login page.

b) Save one or the other for each login, depending on which they use. Save the URL with https for sites with that, and http for the few that don't.

(...and lastly, for any login that uses a non-http/s, use that!)
.................................................................
Is this analysis right?

Ben

On thinking about it, I presume users want 1P to capture the exact login page address(es) the website uses, so that if they do the "open and fill" option, the exact login page opens and fills correctly?

Exactly. :)

And presumably for large companies (like Microsoft), you want to capture each login page you use on their site(s), eg:

In a case like that you may, yes.

I guess most sites would use the secure version by now, especially for logins (one hopes!).

Definitely. If they don't I'd suggest considering if you really want to do business with them.

Is this analysis right?

Sounds about right, yes. :+1:

Ben

jimthing

@Ben - Thanks.

Looks like I'll be going through all mine and replacing the plain URL with the exact login URL then, lol!

Funny how I've never thought about this issue until recently. :)

Ben

Funny how I've never thought about this issue until recently. :)

If you're not making extensive use of the "Go & Fill" feature there may not be much cause to do so.

Thanks.

You're welcome. :)

Ben

rudy

@jimthing

As one of the developers that has worked on the URL parsing code, all of those examples you typed look fine to me and should all work with the fill/go and fill functionality.

If you don’t specify the scheme then it will default to https. Many comparable domains have transforms to match, so hotmail, live, Skype and Microsoft will all show up for each visited site from that list since they have single sign on across their sites.