PasswordMaker Forums

Firefox/SeaMonkey/Mozilla/Netscape/Flock Browser Extension => Bugs => Topic started by: tanstaafl on October 11, 2005, 07:53:42 PM

Title: Badly detected username/password form fields
Post by: tanstaafl on October 11, 2005, 07:53:42 PM
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 (http://www.usairways.com/) & Delta (http://www.delta.com/)
both reported by Trephin here (http://forums.passwordmaker.org/index.php?showtopic=466) (password field populated, but not username)

PlanetSave (http://planet-save.com/)
reported by Rick Bull here (http://forums.passwordmaker.org/index.php?showtopic=382) (site uses frames for login)

GMail Secondary Login/Auth (https://www.google.com/accounts/ServiceLoginAuth)
PM incorrectly populates the secondary text-on-image field with the username
Title: Badly detected username/password form fields
Post by: Eric H. Jung on October 11, 2005, 11:14:26 PM
Title: Badly detected username/password form fields
Post by: tanstaafl on October 12, 2005, 11:26:37 AM
GMail Secondary Login/Auth (https://www.google.com/accounts/ServiceLoginAuth)
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.
Title: Badly detected username/password form fields
Post by: quixin on October 12, 2005, 11:49:32 AM
Quote
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.
Title: Badly detected username/password form fields
Post by: tanstaafl on October 12, 2005, 12:10:32 PM
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...
Title: Badly detected username/password form fields
Post by: David on October 17, 2005, 07:09:25 AM
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)
Title: Badly detected username/password form fields
Post by: tanstaafl on October 17, 2005, 11:19:33 AM
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.
Title: Badly detected username/password form fields
Post by: David on October 17, 2005, 06:51:02 PM
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.
Title: Badly detected username/password form fields
Post by: tanstaafl on October 17, 2005, 08:54:05 PM
Quote
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...

Quote
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-`...

Quote
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.

Quote
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'...

Quote
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.
Title: Badly detected username/password form fields
Post by: David on October 17, 2005, 09:09:25 PM
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 :)
Title: Badly detected username/password form fields
Post by: trephin on October 17, 2005, 09:42:34 PM
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
Title: Badly detected username/password form fields
Post by: Eric H. Jung on October 17, 2005, 09:46:36 PM
tanstaafl,

Quote
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.

Quote
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,

Quote
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.

Quote
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...

Quote
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 current rule to determine username fields:
Quote
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.

Quote
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
Title: Badly detected username/password form fields
Post by: David on October 17, 2005, 10:02:22 PM
Quote
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! :(
Title: Badly detected username/password form fields
Post by: tanstaafl on January 28, 2006, 03:19:19 PM
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 (https://turbotaxweb.intuit.com/open/registration/SignIn.htm)

Reported by alex here (http://forums.passwordmaker.org/index.php?showtopic=708).

Also, I thought  that I had pinned this Topic... oh well, it is now.
Title: Badly detected username/password form fields
Post by: major4579 on January 29, 2006, 09:07:23 PM
Here's another site with autofill problems:

http://www.podiobooks.com/login.php (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!
Title: Badly detected username/password form fields
Post by: tanstaafl on January 29, 2006, 09:18:08 PM
Reported by Alex here (http://forums.passwordmaker.org/index.php?showtopic=708).

"https://turbotaxweb.intuit.com/open/registr...ommain&rotate=1

neither username, nor password gets auto poulated
password field is populated manually with the toolbar button, but not username"
Title: Badly detected username/password form fields
Post by: Eric H. Jung on January 29, 2006, 10:20:16 PM
Hi major4579,

Quote
BTW, I can't say it enough.. thanks Eric for a great program!
Thank you very much.

Quote
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.
This is what I was planning as a solution in the short-term.

Quote
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).
And this is what I was planning longer-term :)  Perhaps these two should be placed in the feature request list for tracking...?
Title: Badly detected username/password form fields
Post by: tanstaafl on January 30, 2006, 08:09:13 PM
Quote
Quote
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.
This is what I was planning as a solution in the short-term.
Ok, this one I don't understand...

The Username is *already* an auto-populated field...

Quote
Quote
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).
And this is what I was planning longer-term. Perhaps these two should be placed in the feature request list for tracking...?
I *think I understand this one, but before I add it...

Are you saying that you want to add two new fields that apply specifically to the username/password fields, that act as - what, alternate 'labels' from the list of officially supported 'field-names' for username and password fields that PWM bases its recognition of these fields on currently?

would it make more sense to simply have a 'Add this field name to PWM's list of username fieldnames'? That might get ugly though...

Awaiting clarification of what precisely these two 'Requests' consist of...
Title: Badly detected username/password form fields
Post by: Eric H. Jung on January 31, 2006, 01:47:38 AM
Quote
Ok, this one I don't understand...
The problem major4579 is trying to address is the one where some sites don't get username and/or password auto-populated. The reason for this problem is because PasswordMaker can only make an educated guess at the username and password fields on a page. It doesn't have a database of websites with their corresponding field names (although breyed hinted at doing something similar to this here (http://forums.passwordmaker.org/index.php?showtopic=583)). For example, the username field is deduced with the following logic:

If a textbox (html "input" tag) exists on the page and has any of the following in its name (case-insensitive):it is assumed to be a username field.

However, plenty of sites (especially non-English ones) have username fields which don't meet this criteria. When this occurs, PasswordMaker is not able to auto-populate them.

The solution proposed here is for the PasswordMaker user to enter data about the field he wants populated. With the new "Automatically populate arbitrary fields" feature, you can choose any field on any webpage to be auto-populated...including these nasty username/password fields which don't fit PasswordMaker's "educated guessing" system.

Quote
Are you saying that you want to add two new fields that apply specifically to the username/password fields, that act as - what, alternate 'labels' from the list of officially supported 'field-names' for username and password fields that PWM bases its recognition of these fields on currently?
Precisely, although the implementation probably won't be two new fields--it can somehow be rolled into the autopopulation tree. TBD.

Quote
would it make more sense to simply have a 'Add this field name to PWM's list of username fieldnames'? That might get ugly though...
This isn't a good idea because the longer the list of possible username/password fields, the longer it takes PasswordMaker to perform the population. It is better to target specifc exceptions to the educated guessing system.

Does that help?
Title: Badly detected username/password form fields
Post by: Eric H. Jung on April 11, 2006, 07:27:10 PM
With the release of 1.5 (auto-populate arbitrary fields), is this thread now irrelevent? If so, let's unpin it.
Title: Badly detected username/password form fields
Post by: tanstaafl on April 11, 2006, 07:34:26 PM
Quote from: Eric H. Jung
With the release of 1.5 (auto-populate arbitrary fields), is this thread now irrelevent? If so, let's unpin it.
Or maybe change the Title to 'Badly Detected Form Fields for Auto-Populate' or some such? There is already the one URL that Lutz reported as a problem here (http://forums.passwordmaker.org/index.php?showtopic=852)...
Title: Badly detected username/password form fields
Post by: Eric H. Jung on April 11, 2006, 08:34:29 PM
My point is that all of these pages should work now, except the one Lutz reported. Since that's the case, this thread might be misleading. We can deal with the site Lutz pointed out in that thread specifically...
Title: Badly detected username/password form fields
Post by: adamspiers on November 08, 2006, 04:43:31 PM
Excuse me for butting in as a newcomer to PWM, but can't we take a leaf out of Firefox's own book here?  I've read this thread and understand about the difficulty of second-guessing fields in badly coded forms, but Firefox's Saved Passwords mechanism works beautifully for me - wouldn't it be possible to figure out how do they do it and copy the technique?

As a newcomer, my first impression of using PWM (other than that this is a really high quality extension with fantastic support) is that there are way too many broken forms out there, and as a result there is a serious usability issue involved with requiring a user to create a new PWM account every time they discover one.  We need something that will learn which (possibly broken) field represents a username the first time the user fills it in, and then automatically remembers it.  There are good reasons for a user wanting multiple usernames across different sites, and Firefox's Saved Passwords automatically learns username field names and values where as PWM doesn't.  As a result of this I am in serious doubt over whether PWM is currently practical for me to use, even though I love the concept, and the implementation seems to be 99% there.

Or is the correct approach/workaround to simply not use PWM's username features at all and rely on Firefox's ability to save form data correctly to remember the correct username for any given site?  This would seem a shame - if PWM has username support it would be great for it to work as well as or better than Firefox's native functionality.

Apologies in advance if I've misunderstood something!
Adam
Title: Badly detected username/password form fields
Post by: Miquel 'Fire' Burns on November 08, 2006, 05:11:08 PM
The username part is partly solved by the advanced auto-populate feature that was added some time ago (1.5 is so long ago)

The issue is that if you want the username to have an effect with the generation of the password, you'll end up having to enter it twice.
Title: Badly detected username/password form fields
Post by: tanstaafl on November 08, 2006, 08:25:30 PM
Quote from: Adam Spiers
Excuse me for butting in as a newcomer to PWM, but can't we take a leaf out of Firefox's own book here?  I've read this thread and understand about the difficulty of second-guessing fields in badly coded forms, but Firefox's Saved Passwords mechanism works beautifully for me - wouldn't it be possible to figure out how do they do it and copy the technique?
I'd be surprised if Eric hasn't already been looking there to create what he already has, but I feel your pain.

Quote
As a newcomer, my first impression of using PWM (other than that this is a really high quality extension with fantastic support) is that there are way too many broken forms out there, and as a result there is a serious usability issue involved with requiring a user to create a new PWM account every time they discover one.
I don't think its quite what I'd call a *serious* usability issue, but I agree that there may be a better way. Sadly, I'm not a programmer, so I'm not in a position to make meaningful suggestions for *how* to improve on it.

To be honest, I'm quite happy with this aspect the way it is.

Quote
We need something that will learn which (possibly broken) field represents a username the first time the user fills it in, and then automatically remembers it.
I'm sure Eric would appreciate any patches, or pointers on how to do this...

Quote
There are good reasons for a user wanting multiple usernames across different sites, and Firefox's Saved Passwords automatically learns username field names and values where as PWM doesn't.
Yes, but what Firefox does and what PWM does are two completely different things. That said, maybe there is something there that Eric could use, but like I said before, I'd be surprised if he hadn't already looked closely at it - Eric?

Quote
As a result of this I am in serious doubt over whether PWM is currently practical for me to use, even though I love the concept, and the implementation seems to be 99% there.
I really can't see how the disadvantage of *occasionally* having to create a new account for a site that has a broken form disqualifies PWM as a whole. The convenience factor, with the added security that can be had from using custom accounts (for financial sites, etc), makes it - for me - by far the most valuable program on my computer - but to each his own...

Quote
Or is the correct approach/workaround to simply not use PWM's username features at all and rely on Firefox's ability to save form data correctly to remember the correct username for any given site?  This would seem a shame - if PWM has username support it would be great for it to work as well as or better than Firefox's native functionality.

Apologies in advance if I've misunderstood something!
Adam
I don't think you've misunderstood anything, I just think you're missing the point... PWM has dramatically simplified my online life so much so that I truly cannot imagine going without it. It would be worse than going back to dial-up (no, I'm not kidding)...

Charles
Title: Badly detected username/password form fields
Post by: Miquel 'Fire' Burns on November 09, 2006, 02:23:12 AM
Hey! I'm stuck on dial-up!
Title: Badly detected username/password form fields
Post by: Eric H. Jung on November 09, 2006, 07:08:25 AM
Auto-populate was added to PasswordMaker late in the game. For better or worse, it wasn't part of the original "core" features--those were centered strictly around password generation with a myriad of options.

So perhaps that explains why auto-populate in PasswordMaker isn't as good as, say, Firefox's native auto-populate.
Title: Re: Badly detected username/password form fields
Post by: Eric H. Jung on August 26, 2007, 09:32:02 PM
Anyone stumbling across this thread: a lot of the sites previously mentioned in this thread now work with PasswordMaker auto-populate (e.g., USAirways and Delta, etc.)