Suggestion: Save Website URL Top Level and Sub-Domains Only
When saving a new website login, 1Password saves the entire URL of the current page. Often this is not ideal because the page is usually the website account registration page. So if I want to use 1Password to open and fill a website login, it takes me back to the registration page and autofills the user ID and password, thereby attempting to create a new account. Since the account already exists, it results in an error. For example, when I saved the login for the 1Password Support Forum, it saved the URL https://discussions.agilebits.com/entry/register?Target=entry/signin.
My suggestion is this: wouldn't it be better to save only the top-level domain and sub-domain, if there is one? E.g., https://discussions.agilebits.com? That way I only have to click the Sign In or Log In button, and usually 1Password proceeds to autofill the login details for me.
Absent this, I have to edit every single saved login item to delete the specific page address. Another benefit of this suggestion is that users wouldn't have to edit URLs when they inevitably change. Specific page addresses often change, but TLDs and sub-domains usually don't.
1Password Version: 7.3.1
Extension Version: 4.7.5.90
OS Version: macOS 10.14.5
Sync Type: Not Provided
Referrer: forum-search:Saving Website URLs
Comments
-
Greetings @riegelstamm,
We store the full URL for open-and-fill but for that to work it does mean either the Login item is saved on the sign-in page or the item is edited after saving. My own routine is to use the password generator when registering for a new site which creates a Password item. I sign out and then sign back in using the Password item. That way the Login item saved not only records the URL for the sign-in page, assuming it is a dedicated URL that can always be loaded e.g. Amazon but also that 1Password understands what to expect from the sign-in page if there are other fields that might otherwise act as noise.
0 -
@littlebobbytables, That's a good workflow, but it doesn't account for URLs that change. My suggestion should account for ~95% of websites, since FQDNs don't usually change, but the path to even the login page can change, as in the apple.com example on my other posting.
0 -
Greetings @riegelstamm,
You're right, over time URLs can change but at least in my personal experience this isn't something that happens a lot. Not storing the path will break open-and-fill for a lot of sites while the impact of old URLs isn't that high, in some of my older Login items where the site has reworked the site I can see they've placed a redirect from the old path to the new one, likely to ensure bookmarks still work. The trouble you had with your Apple Login item would still have occurred had we only stored the FQDN as the only time we use the path is with open-and-fill - it isn't part of matching.
0 -
@littlebobbytables, so you have a sample size of 2 (you and I), plus you assume most people use the same workflow as you, which is highly unlikely. I suggest taking a survey with a larger sample size to see what other people's experience with link rot is. Or use existing data. Better yet, just make it a preference option either to save URLs with or without the full path.
By the way, open-and-fill can still partially work with just the FQDN, even if it doesn't have the login form on that page. All I have to do is click on the login link, and as soon as I hit that page, 1Password fills in the login info.
0 -
Hello @riegelstamm,
When it comes to how frequently URL paths change in terms of sign-in pages I can only talk for myself. When it comes to whether users rely on open-and-fill and expect it to just work I have a much larger pool to draw upon. Through my time with 1Password I know we have numerous users that basically don't interact with 1Password mini at all - they don't even know its a thing. They click on a URL in a Login item and expect 1Password to handle the rest. That works best when the full URL is recorded.
We don't like to say never, who knows what the future will bring and in what ways 1Password may need to adapt but I believe it is unlikely that we're going to start dropping paths or add more preferences. If we simply added a preference for everything 1Password would rapidly become a minefield to configure and there are numerous examples out there to speak of this. I've seen applications with preferences spread over three different locations making finding an option you know exists a pain and nightmare for the uninitiated. We know there's already a learning curve with 1Password and we want to lessen that if at all possible so we're very cautious about adding preferences, we've even removed some where possible.
We would definitely like to better learn how our users use 1Password but that is itself a very sensitive process. Given the kind of data we all entrust to 1Password we have to be careful about what gets logged and we don't perform any metrics - even an opt-in system could create an uproar. We have certainly made mistakes in the past in terms of not understanding how 1Password is used and I'm sure all of the designers would love to learn what is and what isn't working but we would have to tread so very carefully that so far it isn't something we've felt comfortable doing.
One of the positive aspects of a public support forum like this is if others agree with you and want to chip in they can. It's far from a large data set but the forum has shaped 1Password and I'm sure will continue to do so from what we learn here :smile:
0
