Last Comment Bug 436275 - wrong password filled in when same login is used for different forms (with different form fields names) within one site
: wrong password filled in when same login is used for different forms (with di...
Status: RESOLVED WONTFIX
:
Product: Toolkit
Classification: Components
Component: Password Manager (show other bugs)
: 1.9.0 Branch
: x86 Linux
: -- normal with 2 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-29 05:14 PDT by Tomasz Pala
Modified: 2010-11-19 05:49 PST (History)
2 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
POF patch for FF 3.0.x (8.56 KB, patch)
2009-07-19 06:00 PDT, Tomasz Pala
no flags Details | Diff | Splinter Review
POF patch for FF 3.5 (9.55 KB, patch)
2009-07-19 06:08 PDT, Tomasz Pala
no flags Details | Diff | Splinter Review
POF patch for Fx 3.6 (7.04 KB, patch)
2010-08-15 12:12 PDT, Tomasz Pala
no flags Details | Diff | Splinter Review

Description Tomasz Pala 2008-05-29 05:14:44 PDT
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.9) Gecko/2008051202 Firefox/3.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.9) Gecko/2008051202 Firefox/3.0

At first - it looks like a duplicate of <span class="bz_closed"><a href="show_bug.cgi?id=263387" title="RESOLVED WONTFIX - passwords should be stored for host+path and not just host">bug 263387</a></span>, but it is not. It refers to different form fields not path, however the effect is similar.

According to <a href="http://kb.mozillazine.org/Signons3.txt">signons3.txt description</a> there is a place for HTML user name and password fields. I've got two different services and my signons3.txt contains:

---
.
https://my.site
loginUsername
[encrypted login]
*loginPassword
[encrypted pass]
https://my.site
---
stqser
[encrypted login]
*spass
[encrypted pass]
https://my.site
---

Now when I try to login to either of services FF 3.0 (tried b5 and rc1) fills in the first password regardless name of form field. I didn't have this problem in 1.5 or 2.0 series - passwords were not mixed. I've just checked on 2.0.0.13 and it works as expected - password filled in is the one connected with actual login (connected via fields names) according to signons2.txt. Moreover - in 2.0 password manager doesn't even suggest login which 'belongs' to other login field name, but in 3.0 breakage I have to choose from all the logins remembered for a site.
In conclusion: pre-3.0 password manager used both site name and form fields names and it was good. 3.0 password manager looks ONLY at site name, which is bad and makes 2 lines of signons3.txt file completely needless.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Comment 1 Justin Dolske [:Dolske] 2008-05-29 10:42:36 PDT
Form field names are not used any more, but if you have 2 logins that are only differ in username/password, then it generally shouldn't be autofilling anything (although there are exceptions).

Enable debugging per http://wiki.mozilla.org/Firefox:Password_Manager_Debugging, and paste the output from loading the page here? Also a snippet of the form HTML from the login page?
Comment 2 Tomasz Pala 2008-05-31 08:14:22 PDT
> Form field names are not used any more,

How can I bring it back? Or could you point me out some add-on or piece of code that has been changed so I can revert the change and rebuild FF for myself?

I've got even more than 2 logins that differ in password only. Opening a page:

Login Manager: onStateChange accepted: req = https://XXX/X.php, flags = 0x30004
Login Manager: domEventListener: got event DOMContentLoaded
Login Manager: Counting logins matching host: https://XXX, formSubmitURL: , httpRealm: null
Login Manager: fillDocument processing 1 forms on https://XXX/X.php
Login Manager: Searching for logins matching host: https://XXX, formSubmitURL: https://XXX, httpRealm: null
Login Manager: form[0]: found 5 matching logins.
Login Manager: attaching autocomplete stuff
Login Manager: Multiple logins for form, so not filling any.

choosing one of the logins from list containing 5 entries (4 of them are 'gotar' as imported from signons2.txt from FF 2.0):

Login Manager: AutoCompleteSearch invoked. Search is: 
Login Manager: Creating new autocomplete search result.
Login Manager: Searching for logins matching host: https://XXX, formSubmitURL: https://XXX, httpRealm: null
Login Manager: 5 autocomplete logins avail.
Login Manager: domEventListener: got event DOMAutoComplete
Login Manager: fillPassword autocomplete username: gotar
Login Manager: Searching for logins matching host: https://XXX, formSubmitURL: https://XXX, httpRealm: null
Login Manager: Found a matching login, filling in password.
Login Manager: domEventListener: got event blur
Login Manager: fillPassword autocomplete username: gotar
Login Manager: Searching for logins matching host: https://XXX, formSubmitURL: https://XXX, httpRealm: null
Login Manager: Found a matching login, filling in password.

And of course the password filled in is incorrect - this particular one was remembered for loginUsername and *loginPassword, while the page I've opened has stqser and *spass (stripped non-form elements):

<form action='?act=login' method='POST'>
<input type='submit' value='Login:'/>
<input name='stqser'/>
<input name='spass' type='password'/>
</form>

After I've cleaned these 5 passwords from password manager, FF3 saves only one per site-login, so any time I've got only 1 pass instead of 4 saved. It's pretty annoying to type-in password every time I want to use different service on this site.
Comment 3 Tomasz Pala 2008-05-31 16:35:34 PDT
According to:
http://wiki.mozilla.org/Firefox:3.0_Password_Manager#Robustness_to_Site_Changes
FF3 should use field names. What's rationale in not using them anyway?
Comment 4 Justin Dolske [:Dolske] 2008-06-10 12:02:51 PDT
(In reply to comment #2)

> I've got even more than 2 logins that differ in password only.

Multiple logins with the same username but different passwords are not supported.

This is WONTFIX, because this use case is exceptionally uncommon. Fixing this would cause problems with the normal use case, where people are changing their password (or enter a wrong password) for an account, and we don't want to save all those as multiple logins.
Comment 5 Tomasz Pala 2008-06-10 12:32:31 PDT
(In reply to comment #4)

Apparently you didn't read or don't understand.

> This is WONTFIX, because this use case is exceptionally uncommon.

1. it's not about different passwords with same login only. Consider:

FORM A - user joe
FORM B - user henry

and I repeat - different FORM on same site, not URL. FF 2.x did the right thing autofilling these names according to form fields names, while 3.0 pops up both logins on both forms. And it's obvious for me, that field names in signonsX.txt are for some reason, not for decoration.

> Fixing this would cause problems with the normal use case,

Yep, you didn't read - are you saying that all FF 2.x users have problems now? Because, let me repeat, that is the way current FF behaves. And it works well.

> where people are changing their
> password (or enter a wrong password) for an account, and we don't want to save
> all those as multiple logins.

Yep, you don't understand at all... If I change or mistype a password for a SINGLE FORM, SINGLE pass was saved. We are talking here about different FORM FIELDS NAMES. Have a look at signonsX.txt file format and justify 2 lines containing them.

Anyway I've resolved this problem by switching to Seamonkey. It's not broken and it's fast.
Comment 6 Tomasz Pala 2009-07-19 06:00:50 PDT
Created attachment 389365 [details] [diff] [review]
POF patch for FF 3.0.x

Just for the record, as I've resolved this on my own. This patch probably isn't complete, but it works for me and could be a good point for anyone having this problem.
Comment 7 Tomasz Pala 2009-07-19 06:08:04 PDT
Created attachment 389366 [details] [diff] [review]
POF patch for FF 3.5

Previous patch adapted to SQLite storage used in FF 3.5. Again - it's just prove of concept, but it's useful for me, so I share.
Comment 8 Tomasz Pala 2009-07-19 06:13:48 PDT
I forgot to mention the most important part: these can be applied to compiled and installed version, and reverted the same simple way, as they alter only some js code. That's why findLogins function in storages splits hostname from usernameField passed as single argument.
So in short: anyone can patch and revert in place (e.g. if some extensions broke).
Comment 9 Zibi Braniecki [:gandalf][:zibi] 2010-07-11 21:54:51 PDT
Justin, would you be willing to revisit your decision wrt. this bug? It seems that reporter is referring to combination of url+formname which should not carry the risk you were writing about in your previous comment.

The patch needs some cleanups, but it seems that Tomasz, with a little bit of feedback, can work on it.
Comment 10 Justin Dolske [:Dolske] 2010-07-14 13:18:40 PDT
Not really, making the password manager rely on field names isn't something I want to do.
Comment 11 Tomasz Pala 2010-08-15 12:12:49 PDT
Created attachment 466157 [details] [diff] [review]
POF patch for Fx 3.6

For all those people ignored by devs, having multiple login/pass pairs within single host, exposed to senseless, illogical and misleading credentials autocompletion; updated patch allows you to both, supress redundant login hints (not appropriate for current form) and save different passwords for same login (with regard for opened form) comfortably.
Comment 12 Daniel Marschall 2010-11-19 05:49:12 PST
I have exactly the same problem. Different forms at different URLs store the passwords wrong because they change each other password. Usernames are also different.

Now, I am enforced to change all behavior of my PHP websites and rewrite URLs to different VirtualHosts just make it work for FF users.

It is a shame that developers ignore this issue. And this is one reason, why I stop using Firefox and change to browser manufactures who care about feedback.

Note You need to log in before you can comment on or make changes to this bug.