Getting web form details to submit all fields in three-field logins

ThomasK
ThomasK
Community Member
edited April 2016 in 1Password in the Browser

Could someone explain how to get auto-submission working in the situation where there are three required fields? A good example of such a site is 1Password's very own 1Password for Teams login -- [team-name].1password.com. The login page requires the filling out of three boxes:

  • "Email" expects a username in the form of an email address
  • "Master Password" expects a regular password
  • "Account Key" expects a software license-like string[1] that AgileBits provides when you register for the Teams service.

I've gone as far as manually creating the entry from scratch, using the usual instructions (set up all fields ready for submission, bring up the browser extension, click wee gear icon, etc etc). Most of that seems to work at least in part, but I cannot get it to then submit the Account Key with the other two fields.

As I say, the manual creation process gets some things right. It catches the email-username, and the password, and it places those into the main username and password fields at the top of the 1PW entry. It also puts them into the "web form details", correctly identifying them there with the wee head'n'shoulder "this is the username" icon, and the key "this is the password" icon. It does not give the field names for either, but I figured (to begin with) it knows what it's doing and so I didn't interfere.

With the Account Key, it also manages to grab it, and even seems to know something about it. It creates a new section in the 1PW entry, called "Security", and enters the key there. It also labels it correctly (i.e. as "Account Key"), and even marks it as being of type "Password". However, it does not add it to the "web form details" section.

To begin with I figured it should all Just Work since, as I said, 1PW created all the bits and pieces itself. However, although it entered the username ("Email") and password ("Master Password") correctly, it would not enter the Account Key information, even though it had managed to snarf it correctly during the creation of the 1PW entry.

So, then I tried various mods to the 1PW entry:

  1. I added the Account Key to the "web form details" section. I followed what 1PW itself had done when it inserted both the email-surname and password fields into the "web form details" areas and I provided only the Account Key itself as the new field's data, i.e. without providing "Account Key" as the label. And I gave it type "Password" (same as 1PW had given it up in that new "Security" section it created). That didn't work; still no submission of the Account Key.
  2. I added "Account Key" as the label in the "web form details". Still didn't work.
  3. I tried 1 and 2 again, but this time changing the the type of Account Key (in the "web form details" section), from "Password" to "Text". Still no auto-entry of Account Key.
  4. For grins, I even tried taking the wee head'n'shoulder "this is the username" icon in the "web form details" away from the email-username field, and giving it to Account Key field, (1PW won't let it be on more than one field at a time). Still failed. All that happened was that "Email" box on the login screen now got filled with the Account Key instead of the actual email. And I still got nothing at all in the "Account Key" box

So, automatic entry of the password into the "Master Password" box, and the email into the "Email" box are both fine. (I know the email is good because I can see it, and I know the password is good because if I manually enter the Account Key, and click "Sign In", I do get logged in fine). But no matter what I try, I cannot get anything to be entered automatically into the "Account Key" box.

Final point: this is not the only three-field login where I've seen this problem, so it's not some weird feature peculiar to xxxxx.1password.com

Any ideas?

thanks for any help.

[1] It's about 34-ish alphanumeric characters plus dashes. I don't know if it is strictly a username or password. When entered it appears fully in plaintext like a username, but when re-presented by the browser for repeated login (unless that's disabled by checking a "This is a public or shared computer" box at login) it is displayed with only its leading characters in plaintext and the rest starred out, kinda like a password. That's just FYI -- I don't think it's relevant to my problem.

P.S. FWIW, Safari version is 9.1 (11601.5.17.1) But the problem also appears on Chrome 49.0.2623.110 (64-bit) with the 4.5.5.90 extension

1Password Version: 6.2 (620011) Mac App Store
Extension Version: 4.5.5
OS Version: OS X 10.11.4
Sync Type: DropBox

Comments

  • jxpx777
    jxpx777
    1Password Alumni

    Hi, @ThomasK. I'm very sorry for the confusion. The behavior you're seeing with the account key is actually the correct behavior.[^1]

    The way that you see the account key field saved in 1Password is a custom field section rather than part of the web form itself. This is a subtle distinction (Perhaps too subtle?) but an important one. We capture the account key in this sign-in form, which didn't previously show the account key at all times like it does now, and also in the initial sign-up flow where you create your account, save your account key, and then sign in for the first time. During the last step of that initial sign-in process, only your master password is entered. Many people ended up with 1Password items that contained only their master password and forgot to save their account key after this step.

    To get around this, we added some code that allows the page to include some custom attributes to tell 1Password about other fields. The username field is the easiest. The account key is much more challenging. Pages that use multiple fields for logging in are honestly pretty fragile with 1Password. If the page where the item is filling doesn't look like the page where it was originally saved, then 1Password falls back to other filling strategies that only use the username and password. So, a Login saved from the initial sign-in screen could never be filled in the subsequent log in page that asked for the email, password, and account key.

    When the sign in form for a returning user was redesigned to always show the account key, we had a few of our beta users that were confused because the account key was saved in two places, the custom section you see and also the web form details. As they tested things especially with Account Recovery, we found that they would update the account key in the custom section but the web form details remained unchanged, so filling was still using the old value. To get around this, we removed the account key from the web form details and kept it only in the Security section.

    No decision is permanent and we may revisit this in the future, but for now, please know this is actually working as intended. If you have any other questions or feedback, please let us know.

    [1]: If you have other sites that are behaving badly with multiple login fields, please let us know the URLs, but they're going to be unrelated to this problem unless someone has dived into our code on the Teams/Families sites and see some custom work we've done there.

    --
    Jamie Phelps
    Code Wrangler @ AgileBits

This discussion has been closed.