Badly detected username/password form fields

[tanstaafl]

This forum is for reporting username password form fields that are not properly detected by PASSWORDMAKER. Please provide the entire URL when reporting.

Below is the list of already reported URLs:

USAirways & Delta
both reported by Trephin here (password field populated, but not username)

PlanetSave
reported by Rick Bull here (site uses frames for login)

GMail Secondary Login/Auth
PM incorrectly populates the secondary text-on-image field with the username

[Eric H. Jung]

• PlanetSave.com reported here by Rick Bull (site uses frames for login)
• Delta reported by trephin here (password field populated, but not username)
• US Airways reported by trephin here (password field populated, but not username)

[tanstaafl]

GMail Secondary Login/Auth
When logging into GMail, you have to enter your username/password. The first time is no problem.

However, after the *successful* login, you are presented with a SECOND login page, that also contains the text-on-image confirmation field. When populating with PM on this page, the username gets populated into the correct username and password fields, but the username also gets populated into the secondary text-on-image confirmation field.

[quixin]

However, after the *successful* login, you are presented with a SECOND login page,

 I don't know why, but I never get any kind of 'SECOND' login page like your describing.  After I login to the primary page, I'm in.

[tanstaafl]

I was wondering about that, because I don't think I always did, but I'm not sure when it started (sometime around when I started using the GMail Notify extension, many months ago).

Maybe I'll try with a fresh FFox profile...

Thanks for the comment...

[David]

Ah, I finally :) made it to the forums through all the broken links - I'm assuming that's because of https?

Here's the question: PM enters the username twice when logging into a site.

Site asks for:

(1) name
(2) email
(3) password

PM enters the username in the name and the email fields.

As a dev, is there a way to design the form so that this doesn't happen?

Thanks B)

[tanstaafl]

Hey David,

Thats coming very soon - the ability to populate arbitrary fields (not just name, but anything).

This will only be applicable to Custom Accounts though - although Eric may find a way to do this (unreliably) for Accounts using the Defaults.

[David]

Ok, just to be clear, this is something I don't want happening by default--I want PM not to put the username in the email input as it's doing currently.

I've used PM on forms that have multiple inputs--address, phone number, username, password, etc. and (I think!) seen it only fill in username and password when asked to auto-populate the form.

So I was just wondering what was done differently in those forms when compared with this one--why is PM filling in the email with the username?

More generally, perhaps it would be helpful to know what PM uses to decide that a particular input is a username input. Obviously, if the type is password, it's a password field.

Also, Eric, it would be nice to have a way to force PM to fill a certain input with the password. I was on a form the other day where the input had only 'oldtype="password"' (I believe) so PM wouldn't put the password in it. I really needed to have PM do it, and fortunately there was another password input on the same page (for a different password), so I was able to use that and cut and paste into the correct input. But, as I said, that was fortunate :) - can't be counted on to happen in every situation in which the dev does something weird with the password input.

[tanstaafl]

Ok, just to be clear, this is something I don't want happening by default--I want PM not to put the username in the email input as it's doing currently.

So don't put a username in the Account Settings for that Account...

I've used PM on forms that have multiple inputs--address, phone number, username, password, etc. and (I think!) seen it only fill in username and password when asked to auto-populate the form.

That's how it behaves if you have the 'Auto-populate...' unchecked for that Account. Then it only populates when you hit 'ALT-`...

So I was just wondering what was done differently in those forms when compared with this one--why is PM filling in the email with the username?

It must be a poorly designed form.

Once the 'Populate arbitrary fields' (this does not seem to be in the Feature Request List - I think becuase this was Erics own idea and was never discussed/suggested in the forums) stuff is done, you will be able to have the entire form filled out precisely how you want for each Account - but I'm sure you will have to train it the first time.

More generally, perhaps it would be helpful to know what PM uses to decide that a particular input is a username input. Obviously, if the type is password, it's a password field.

The problem is, there are umpteen diferrent ways to do it, and Eric cannot account for every possible variation - so, for problem accounts, he came up with the brilliant idea of 'Populate Arbitrary fields'...

Also, Eric, it would be nice to have a way to force PM to fill a certain input with the password. I was on a form the other day where the input had only 'oldtype="password"' (I believe) so PM wouldn't put the password in it. I really needed to have PM do it, and fortunately there was another password input on the same page (for a different password), so I was able to use that and cut and paste into the correct input. But, as I said, that was fortunate smile.gif - can't be counted on to happen in every situation in which the dev does something weird with the password input.

Ahem...

'Populate Arbitrary Fields' is what you want. Eric will have to tell you when to expect it.

[David]

tanstaafl,

I don't think you're understanding me, and I'm not sure why.

(1) Not putting a username in the account settings is just ignoring the problem, which is that PM is filling in fields that it shoudn't be.
(2) 'Auto-populate' vs. 'Alt-'' has, I believe, nothing to do with it--again, the problem is that when populating with either, PM is doing so incorrectly on this form.
(3) The design of the form is the question.
(4) "The problem is, there are umpteen diferrent ways to do it,..." I'm not asking how one might do it or PM will do it in the future--I'm asking, how does PM do it now. If this is known, the exact problem with the form (that is, [3]) should be fairly obvious.

Populate arbitrary fields sounds good for forcing the password to be entered--thanks :)

[trephin]

tanstaafl did answer your question

the form author identifies each field by some tag ... since every single field in use is not standardized, PM cannot identify them all... hence the problem

and yes, this means that sometimes, a field matches one in PM but it isnt the field you want to have information entered

currently, PM cannot identify every field correctly... as such, Eric will be implementing a feature - "Populate Arbitrary Fields" or something - which will allow you to have the username entered without having to code individual names of tags into PM


do a search and you will see there is at least one other thread on the topic

[Eric H. Jung]

tanstaafl,

However, after the *successful* login, you are presented with a SECOND login page, that also contains the text-on-image confirmation field. When populating with PM on this page, the username gets populated into the correct username and password fields, but the username also gets populated into the secondary text-on-image confirmation field

I don't use gmail regularly, but if it's anything like yahoo, I periodically -- seemingly randomly -- get this kind of thing with them. Clearly it's some sort of security measure, and by introducing its presence randomly, google is trying to guarantee that whatever is logging in is a real person, not a script.

but the username also gets populated into the secondary text-on-image confirmation field.

You'll be able to prevent this with Populate Arbitrary Fields.

David,

I want PM not to put the username in the email input as it's doing currently.

As pointed out by tanstaafl, you'll be able to do this with Populate Arbitrary Fields. For now you'll either have to endure the annoyance or copy-paste things manually from the main passwordmaker dialog.

So I was just wondering what was done differently in those forms when compared with this one--why is PM filling in the email with the username?

As you surmised, this depends on the form itself. See next for more...

More generally, perhaps it would be helpful to know what PM uses to decide that a particular input is a username input. Obviously, if the type is password, it's a password field.

The current rule to determine password fields:

• The html <input/> box has a type attribute of password or
  
• The html <input/> box has a type attribute of text and its name attribute matches the regular expression match(/pass|word|pw/i)

The current rule to determine username fields:

• The html <input/> box has a type attribute of text and its name attribute matches the regular expression match(/ID|un|name|user|usr|log|email|mail|acct/i). Prior to 0.9, acct was not in the match list. This was added for delta.com.

Also, Eric, it would be nice to have a way to force PM to fill a certain input with the password.

As pointed out by tanstaafl, you'll be able to do this with Populate Arbitrary Fields.

I really needed to have PM do it, and fortunately there was another password input on the same page (for a different password), so I was able to use that and cut and paste into the correct input. But, as I said, that was fortunate - can't be counted on to happen in every situation in which the dev does something weird with the password input.

As a last resort, you can always open the passwordmaker dialog to get your passwords, and use the copy/paste button there or even jot it down manually if you must.

-Eric

[David]

The current rule to determine username fields:

• The html <input/> box has a type attribute of text and its name attribute matches the regular expression match(/ID|un|name|user|usr|log|email|mail|acct/i). Prior to 0.9, acct was not in the match list. This was added for delta.com.

Thanks Eric, that's what I was looking for! I was trying to ask a simple question, but I guess I obfuscate things to the point of incomprehensibility-I'm sorry! :(

[tanstaafl]

Another one where the username is not populated correctly. The password seems to be, but might as well check that too...

https://turbotaxweb.intuit.com/open/registration/SignIn.htm

Reported by alex here.

Also, I thought  that I had pinned this Topic... oh well, it is now.

[major4579]

Here's another site with autofill problems:

http://www.podiobooks.com/login.php

The password gets entered, but the username does not. It's no wonder when you look at the code:

<tr>
 <td align="right">
 <label for="Text1">Login Name:</label>
 </td>
 <td>
 <input class="formtextbox" type="text" name="handle" value="" id="Text1" />
 </td>
 </tr>

The field name is "handle"
The field id is "Text1"

Now I know there is no way that PWM can catch and fill all the various names that are used to label the Username and Password fields.

Three approaches come to mind:

Since the next version is going to have auto-populated fields, and it looks like the decision is to require the MPW first - this could be used to get around these problems. Just enter the Username field as an auto-poulated field.

Alternatively, in individual accounts, the username and password field names could be manually entered, if needed. (I.e., use the PWM built-in field names unless something was entered in the username and password field name fields).

Finally, if possible, a Learn Button could be added - go to a login page, manually fill-in all fields - maybe having some special keywords like **PW** to signify the password field - and click on the Learn button. This could add the webpage as a new account (if needed) then record all the fields with their filled-in values, reserving the special fields. Maybe this is too complicated for some - don't know.

Just some thoughts though.

BTW, I can't say it enough.. thanks Eric for a great program!

Also, 1.4.4.b1 has been working fine!