[Req] Add OTP field to main credentials section
First let me say a big thanks to the AgileBits team. I'm sure you don't receive enough props for what you have accomplished. I've been a happy customer for many years, promoting 1P often including proudly wear my "⌘/ is my password" tshirt.
I'd like to ask about getting 1P to include a field to the credentials section (username and password) for a One-Time Password.
I've enabled 2 factor auth for many logins including Google but 1P isn't currently able to enter the 6 digit OTP code on the Verify screen.
My Google Login Item includes a line with the name matching the web form field (Pin), the TOTP URI, and the type is set properly to One-Time Password. This works and generates the OTP code properly every 30 seconds but when I press ⌘/ at the Verify page, it enters my username again.
It would be wonderful if 1P detected a OTP line is added to the Login Item entry and if so, add/move it to the top credentials section and to the lower Web Form Details section (so that we can set the field name and type properly); or some other awesome method you come up with.
Currently the Web Form Details section doesn't have a OTP type so if you save a Verify page submission, the code is saved as a Telephone type with the name of Pin; which makes sense based on the HTML code stating it is a telephone type. (They do that so on a mobile, the keyboard is shown as a number keypad)
<input type="tel" pattern="[0-9 ]*" id="totpPin" name="Pin" dir="ltr" autocomplete="off" placeholder="Enter 6-digit code" autofocus="" class="Xxfqnf">
Thanks for listening and I hope this feature is added quickly as it sucks to 
1Password Version: 5.3.2 AWS
Extension Version: Not Provided
OS Version: OS X 10.10.5
Sync Type: Not Provided
Comments
-
Hi @Smudge,
Thank you so much for the kind words! We truly love to hear things like that from our customers, and I'll make sure to pass that along to the others here. We wouldn't be where we are today without awesome users like yourself, so thank you for cheering us on! :)
Thanks also for your suggestion/request for being able to fill a TOTP with the 1Password extension. The reason it cannot currently do that is because the extension doesn't support filling custom fields (so the same is true for any other custom field you might add to a Login item in 1Password). But other customers have also asked about that and we would definitely love to make it easier to fill a TOTP on a web form. We have an open feature request for that, and I'll be more than happy to add your comments to it in order to let our developers know.
In the meantime, you can simply click on the one-time password field in 1Password to copy it, and then paste it into a website. That works in the main app as well as 1Password mini or the browser extension. I know it's not quite as easy as using a quick keyboard shortcut, but hopefully that makes it a bit easier.
Thank you again for taking the time to send us your thoughts on how you'd like that feature to work, we really appreciate it! As always, we're here for you if you need anything else. :)
ref: OPX-758
0 -
@Drew_AG Sorry to dig up an old thread but any idea when the ability to use custom fields to fill in forms will be a reality?
The method to copy then paste is how I've been doing it and it works but as you said, not as convenient. I love that 1P even supports OTP.
When (and please make it a 'when' and not an 'if') your developers are able to add the ability to fill in custom fields, please don't limit it to just this OTP request. I have quite a few 1P Items that I would love to be able to designate a custom value to be filled out on a web form.
Thanks
0 -
@Smudge: It's definitely still an "if". Though a filling option for TOTP is something we'll likely find a solution for, it really isn't feasible for 1Password to fill any custom field, since they can be for anything. The user would have to wire up a field to a particular form element somehow, otherwise 1Password won't know their intent. It may be more feasible to have a handful of predefined matches like this...but that kind of kills the "custom" part doesn't it? How would you anticipate something like that working?
0 -
I would like to see something like this.
Ability to add fields to the top authentication section
I would add a custom field, like a TOTP
Just like the username and password fields, it would need to be linked to one of the web form elements. Instead of using the dark icons for the association, change it to use the name of the auth field.
Basically, I would like to be able to associate any captured form element entry to a custom auth field.
Another perfect example is your own 1password.com login page. It captures the form elements and associates the email address as the username and the master password as the password.
Due to the custom data attributes for the account key element, it didn't add that text element to the web form elements list but instead created a custom section with proper names. Now that is very cool but it doesn't put the account key in when filling out the form.
Since 1P breaks if you change the form element list (add or remove or change the type), the user should probably not be allowed to do that (bug?). After all, 1P captures the element name, type, and values from the web site and the user might not know the proper name or type if they added new element entries. The custom auth fields should only be able to be created and associated to existing form elements. Using the 1password.com entry for example, username/password was working as captured/shown in the image above. I added a new form field named "account-key", set the value, and it was already set as a "text" type. This matches the HTML attributes of that input element. When I used 1P to fill in the form, it completely failed and didn't fill in a single field! I deleted the account-key entry but it still failed to fill out the form so to get it working again, I would have to create a new login item again.
So I hope that is enough and you understand what I (and many others) are looking for with this feature request. If you need any more details or have questions, please ask.
0 -
Here is a different way for your developers to consider (and probably a better way than what I described above)
One of the primary functions of 1P is fill in web forms with data from a 1P entry, right? Problem is that the web form details section is the master and it references only username and password values from the authentication section.
This request is for 1P to reference in the other direction. The authentication section is master and references the web form details section for the id/name and type of a form element. This would allow the user to decide which item value is put into a specific web form element without having to edit the hidden web form details section.
When a form is added to 1P, it would still capture all the form elements and values but by default only detect and associate the username and password fields. This way it would continue to work the same as it does now.
If the user needed any other fields from that form to always be inserted, they would enter Edit mode and on the new field line choose an unused form element. In the picture, the popup menu shows the unassociated elements (with the element name if available and the element ID). The user picks an available element and it is added to the authentication section.
The label would be set to the element name; falling back to the element ID if the name was not captured. The value would be set to the captured value. Of course the user can then change these as they wish. Some sanity checks would have to be done like to not allow the user to enter a value that doesn't match the element type. ie Alpha characters would not be allowed for a "number" or "tel" element type.
I can see where this would be a considerable developmental change but I hope your developers are open to consider this. I think that this way opens up 1P to be a lot more flexible in its ability to enter form data. With the web constantly changing, 1P needs to be able to adapt. For example, many new element types were added with HTML5 and 1P doesn't support them all but I'll leave that for another feedback report ;)
0 -
I can see where this would be a considerable developmental change but I hope your developers are open to consider this.
@Smudge: You're exactly right, and I think some of your suggestions go a bit too far when it comes to user-facing complexity...but the fundamental idea is pretty awesome. The hard part, as you say, is making it happen, and perhaps more importantly making it easy to use. But it's totally worth doing, if we can enable TOTP filling, and perhaps other custom fields of certain types could follow. Thanks so much for sharing your thoughts — and the images helped me to appreciate the ambition and utility of your proposal. :)
ref: OPM-3930
0 -
+1 for TOTP filling.
Also the option the add in directly in the password field. some logins require you to fill in the password and add the token at the and in the same field, like:mypassword1234560
