Using 1Password to sign in to Families

Jacob

This discussion was created from comments split from: Just signed up - a couple of comments about the proces. The discussion has been moved to the **Saving and Filling in Browsers** forum to work on the specific issue.

machale

@penderworth At first, manually saving a new login didn't help. It's weird, sometimes the Account Key wouldn't autofill, sometimes the Master Password wouldn't autofill, but it was always just one of them. I was unable to find a pattern. I was initially working entirely in Firefox.

After much hullabaloo, it seems to be working for me now (except the Sign In button is not auto-clicked in Firefox). So, I'm all set.

The remainder of this post is to pass on to your engineers in case they decide they want to look into this further. There may be an issue with creating a Login item for family-name.1password.com in Firefox. But I can't prove it, and I do not have a simple reproducer for you. So feel free to chuck the rest of this if you wish. :)

OK, so I had manually created the Login using Firefox. To show you my manually-created Login here, I used 1P to right-click-duplicate it. I then minimally modified the username and website fields in that duplicate login so I could show you a screenshot on this open forum. Here it is:

It kept not working, always failing to autofill either the Account Key or the Master Password. I tried using the same manually-created Login item in Safari on the same machine. In Safari, it consistently failed to autofill the Master Password field, and the Account Key field always worked fine.

Since the behavior was slightly different, I tried manually creating a Login using Safari. It appeared to work fine in Safari! So I went back to Firefox and tried to use the Login I manually created in Safari and discovered something very odd: the Login manually created in Safari actually had a bunch of bullet characters stored in the Account Key field! (Just like what is displayed in the browser when logging in - the first few characters followed by bullets.) I confirmed this by copying from 1P and pasting into a text editor and sure enough, they really were bullets. So, I assume when logging in on Safari the Account Key field was being populated by a cookie, or 1P mini, instead.

So I then edited the Account Key in the Login created manually in Safari. Once I fixed that Account Key, the made-in-Safari Login worked fine in Firefox! The only glitch in Firefox at this point is that the Sign In button is not auto-activated after the 3 fields are filled in, but the cursor is left in the Master Password field, so it's easy to press Enter to login. Not perfect, but good enough for me.

So, going back and thinking about how things looked, I think cookies may have come into play here, but I can't prove it. I rarely use Safari, so it's set up to handle cookies however it's set up by default. I have Firefox set to forget cookies after each browser session, except for several exceptions that I have specified to "Allow" in Firefox Preferences (meaning, keep the cookies for those web sites across browser sessions). 1password.com was not originally in there. While experimenting, I set Firefox to "Allow" 1password.com cookies to survive across browser sessions, but at this point I no longer have 1password.com set to "Allow" and everything is working fine.

Mac OS X Yosemite 10.10.5 (14F1713) with 1Password 6 Version 6.2.1 (621002) AgileBits Store and extension 4.5.5.
Firefox (45.0.2) and Safari Version 9.1 (10601.5.17.4)

I know the above is confusing. If it's of value to your engineers, cool. If not, that's cool too. 8-) Thanks.

rr0ss0rr

Account Key is not filled in for me .. Mac Beta, Opera Beta .. This has been happening from the beginning .. I manually saved the login again just to make sure ..

littlebobbytables

Hi @rr0ss0rr and @machale,

Not filling the account key is a deliberate move on our part. Normally we record all fields in the web form details section and use this information to fill the web page when you instruct 1Password to do so. With our own Teams/Families login page we made the conscious decision to store the account key in a custom field within the Login item when you create it which can be seen in the image machale posted. It's a design decision, one where my understand is we wanted the account key visible so people knew it was stored but there was the concern that if it was visible like it is people might mistakenly believe that editing it in the custom field would be reflected in the web form details which is what gets used to fill. After all, this is exactly what happens when you edit either your username or password. We alter the visible fields that you can see and any change there is reflected in the fields in the web form details that are linked to those two fields. All of this was designed a long time ago when most pages consisted of just a username and password.

I'm not sold on the current design. I preferred it when saving a new Login item saved everything in the web form details and all I needed to do is use ⌘\. Of course I'm not the target audience. What we expect most people will do is have their browser remember their account key for them and if the browser does this then all that is required the next time you visit your sign-in page is the Master Password which 1Password will fill.

I've seen two reports now though where there are specific instances where we would expect 1Password to fill a password and it isn't. One is the confirmation page for Amazon where you're logged in but Amazon are asking for the password again anyway and I've seen references to our own site where the user has been logged about and the Master Password won't fill. We will be investigating the possibility that there is a bug in the extension that needs to be addressed.