1PW7 Windows beta user ID capture logged incorrect user IDs
So when I started testing 1PW7 beta for windows, I noticed that this new version of 1PW took away the ability to reclassify webform fields from X to user ID / password. In my usage, 1PW often captures the wrong web field as the user ID or password. I had been using the ability to delete random crap from janky webforms and modify fields to the right category in 1PW4 to fix these websites' entries. Unfortunately, can't do that in 1PW7 beta for Windows. On that side of the AB forum, they asked for me to report problems here.
1PW7 did not capture website user ID correctly for subsequent log on for these sites:
comet.ml: 1PW7 captured screen display name as log in user ID, when email address should be captured instead
grubhub.com: 1PW7 captured a really random string of numbers as user ID, when email address should be captured instead
forum.inoreader.com: 1PW7 captured email address as user ID, when screen name should be captured instead (edit: actually this one may be old enough to have been originally captured with 1PW4)
FYR @MikeT the frequency of this kind of issue is why having control over the field classification in 1PW4 has been so useful in keeping the vault tidy with functional auto-fill login.
1Password Version: 1Password7 Windows beta
Extension Version: 4.7.0.90
OS Version: Win8.1
Sync Type: Dropbox
Comments
-
Thank you for reporting the various pages. With comet.ml I suspect we'll need to build up a specific rule for the site. Even just viewing the registration page I would assume that logging in would require the username and password rather than the email address. I haven't been able to reproduce what you've found on grubhub.com just yet. What I tested was their registration page, similar to how I approached comet.ml. If I should be looking at a different page please let me know. This leaves forum.inoreader.com. I did half expect 1Password to focus on the email address but in the test Login item I just tried saving it selected the username field for the username which seems to be the desired outcome. Like the others the save was made on the registration form based on the belief that this is where you were saving the items as well.
Can you confirm if you can reproduce the issue with grubhub and inoreader for me please. Obviously I don't expect you to create new accounts, that would a pretty ridiculous request to ask of you but if you fill the various fields and then manually save a new Login item (our page How to save a Login manually in your browser can help with this) do you see the same undesirable result?
You're right, the ability to correct 1Password when it gets it wrong is useful as expecting no mistakes at all over all websites is a goal but one almost impossible to reach. As these examples have shown, the right fields often differ and aren't always obvious until you reach the sign-in form.
0 -
@littlebobbytables Yes I have 1PW save logins when I'm doing the initial registration. I think you recommend people not doing this but I just worry that my bad typing will create a situation where I can't log back in a second time for capture. I tend to use different user IDs per website. Prefer the initial set up data captured so that I can fix up 1PW as needed to get the auto-log in working correctly. If I can't manually fix the entry, I'll simply delete the website out of the 1PW entry, and then manually log in again (copying the data out of the dud entry) to trigger the auto-save.
With grubhub, I remember having a bad initial log in experience. If I recall correctly, I was deep into picking a restaurant and selecting food before I was prompted to actually create a user account. And yes, I recreated the experience and the bad data capture with this work flow > set zip code > pick restaurant > pick food > start check out process > add email > provide more specific address > enter password. Doing this created the web form details to be captured, see attachments.
With forum.inoreader.com I wasn't able to recreate the way the account initially was captured.
I've suggested for the 1PW7 beta windows team to switch the 1PW7 beta entries webform section a bit. I don't care what the website is labeling their fields, what I care about is how 1PW classifies a particular field. I would recommend dropping the webform field labels, and instead show only the 1PW7 data classification. Also allow for 1PW7 data classification to be modifiable. My 2 cents...
0 -
Thank you for that fantastic detail on grubhub. I wasn't aware of this alternative route but given what 1Password seems to have saved I suspect it picked what it did as a last ditch effort having found nothing better to grasp onto. It sounds like the page that contained what would have been your username was quite divorced from where you entered the password. My gut feeling is we'll probably never do a great job there as the user would need to be thinking far enough in advance to save a Login item using the steps outlined on our support page Sign in to websites with username and password split across multiple pages which also doesn't seem that reasonable to expect. I'll try to see if I can reach the same point but as I'm based in the UK I may not be able to provide sufficient details to appease any checks they have.
Given that @MikeT suggested you post here I'm confident he's been taking your suggestions on board. On the Mac side we can alter the designated field for the username or password so it is almost guaranteed to be just a matter of time before 1Password 7 for Windows does as well. They've got such a long to-do list that they have to routinely make hard decisions about priorities but I have no reason to believe they won't address this as soon as they can.
0 -
@littlebobbytables yeah, I was hungry and not thinking clearly when I did that. Couldn't figure out to undo it without clearing the browser cache. Thanks as always!
0 -
I think I can place myself in your shoes. You seem to be so close and all the site wants to do is throw hurdles in your way. What surprises me a little is you would think maintaining a single registration flow would be better and then point to it in all the right places. Should they need to address something now there are at least two places code would need changing.
Let me know if you find any other sites, all of this helps.
0
