279360 - HTTP passwords not remembered

Status: RESOLVED FIXED

(Toolkit :: Password Manager, defect)

Description

[Dave Evans]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050110 Firefox/1.0 (Debian package 1.0+dfsg.1-2)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050110 Firefox/1.0 (Debian package 1.0+dfsg.1-2)

Using a fresh install, a fresh $HOME directory and a fresh profile, HTTP "Basic"
authentication details are not always remembered.

Reproducible: Sometimes

Steps to Reproduce:
1. Fresh install, fresh $HOME directory, fresh profile.  Start Firefox.
2. Visit a site which requires HTTP "Basic" auth.  Enter auth details.  Set the
"Remember" tickbox to "on".  Submit dialog.
3. Look in "View Saved Passwords".
Actual Results:  
About 50% of the time (on a sample of about 6 tests) the password was
remembered; it did appear in "Saved passwords", and after closing and restarting
Firefox the auth details were correctly pre-filled on the next visit to that web
page.

The other times it did not appear in "Saved passwords", and after a
close/restart, the details were not pre-filled on when the page was revisited.

Expected Results:  
As long as the "Remember" tickbox is set to "on", then the details should always
be remembered.

Tried just now with nightly Firefox (failed) and nightly Mozilla (passed).

Sorry if this is a dupe - searching for dupes in bugzilla is really hard for
anyone not already familiar with both Mozilla and existing bugs. :-(

Comment 1

[Kevin Brosnan]

Take a look at bug 93776 yahoo.com - Several sites, notably yahoo mail, opt out
of using password manager

Firefox respects the websites request for the browser not to cache usernames and
passwords. Also some specific urls would be helpful.

Comment 2

[Dave Evans]

I don't believe that bug 93776 is relevant - that bug relates to the form
"autocomplete" attribute.  *This* bug report relates solely to HTTP "Basic"
authentication, not forms.

I would give you the URL of the sites in question, but all the ones I can think
of right now are private intranet sites to which outsiders are not allowed
access :-)  I believe that the problem probably affects *any* site which is
protected using HTTP "Basic" authentication.

Comment 3

[Dave Evans]

I have a nagging feeling (hard to prove of course) that this bug happens more
often, i.e. the chance that it will fail is much higher, if the URL being
requested results in a redirect (once the authentication has succeeded).

Comment 4

[Dominique Hazaël-Massieux]

Another case which seems to make the HTTP Basic Auth Passwords fail is when
there is more than one realms for a given site.

For instance, www.w3.org uses several realm (e.g. W3CACL and W3C-Member), and
the password manager seems to only remember one of these - I assume the first
one it encountered.

(I was not sure if this belonged to this bug or if I should create a new one;
I've opted to inform that one for the time being).

Comment 5

[David P James]

Mass edit: Changing QA to default QA Contact

Comment 6

[Stephanie Daugherty [:sdaugherty]]

Anyone able to reproduce on a recent build?

Comment 7

[Dave Evans]

Intermittently, yes.

Using current nightly (firefox-3.0a2pre.en-US.linux-i686.tar.bz2 ; md5sume80f947abe40bc6f3b5980281c1b1446).  Run under a freshly-created user account (this is on Debian).

Tested by visiting various HTTP "basic auth" protected sites (all on private intranet, sorry.  They all run Apache, if that helps).  Entering auth details, clicking the "remember" box.  Checking that the page loads ok (i.e. auth succeeded).  Close firefox; wait for it to exit.  Start firefox.  Try visiting the same site again.

Roughly speaking, about 25%-33% of the time, it fails to remember a password.

Comment 8

[Tracy Walker [:tracy]]

Please provide a reduced test case that is always reproducible.

Comment 9

[Dave Evans]

Always?  No, I can't do that; I've already told you that it's intermittent.

However, I'll endeavour to post a step-by-step guide to reproduce the intermittent flaw.

Comment 10

[Dave Evans]

OK, here's one which is intermittent, for me.

Created a new user ("fftest"); installed ssh keys so I can log in as that user.

tar jxf firefox-3.0a2pre.en-US.linux-i686.tar.bz2
(md5sum is c9a6cf950425506fa067c012eb053f74).

./firefox/firefox

new tab; go to http://djce.org.uk/test/mozilla-bug279360/t.asp

Enter username "davide", password "a01;bcde".  Tab onto the "remember" tick box, press space, press enter.  The page is shown.

Go and look in the "saved passwords" list.  Maybe the user you just entered is there, maybe it isnt.  If not, "rm -rf .mozilla firefox" and go back to the "tar" step and try again.


btw, running on Debian; the installed packages include:
 
ii  firefox                          2.0.0.1+dfsg-2                  Transition package for iceweasel rename
ii  firefox-dom-inspector            2.0.0.1+dfsg-2                  Transition package for iceweasel rename
ii  iceweasel                        2.0.0.1+dfsg-2                  lightweight web browser based on Mozilla
ii  iceweasel-dom-inspector          2.0.0.1+dfsg-2                  tool for inspecting the DOM of pages in Icew
ii  mozilla-firefox                  2.0.0.1+dfsg-2                  Transition package for iceweasel rename
ii  mozilla-firefox-dom-inspector    2.0.0.1+dfsg-2                  Transition package for iceweasel rename

Comment 11

[Dave Evans]

Additional observation:

I just tried much the same test with seamonkey (seamonkey-1.5a.en-US.linux-i686.tar.bz2).  Again, it failed intermittently.

However, when the "seamonkey" directory was owned by a different user (i.e. download and unpack the tar as one user; then run seamonkey as another user) then I could *not* get it to fail.  So maybe one of the preconditions for the bug is that the seamonkey directory (or something therein) is writeable by the user.

If these tests aren't valid - i.e. you want me to re-test using a different build, or with some option set to ensure it doesn't accidentally use bits of my debian-packaged iceweasel etc - please let me know what tests you would find more useful.

Comment 12

[Justin Dolske [:Dolske]]

Are you always successfully logging in when this happens? Bug 379997 fixed an issue where logins were automatically/silently deleted when the browser got a 401 response for a login it provided. Do you still see this happening with recent trunk builds (which would have this fix)?

Comment 13

[Dave Evans]

Having read bug 379997, I don't believe it's relevant in my case.  I was testing (in comments #10 and #11) using a fresh install, with no previously-saved passwords, and I didn't have to try to log in several times (unless the browser did that for me automatically).

I'll try to retest with a recent build, and verify that the server isn't giving any odd responses.

Comment 14

[Justin Dolske [:Dolske]]

Marking INCOMPLETE; I think this is almost certainly 379997, and testing will a recent trunk will likely confirm that.

If you can reproduce this with a recent trunk (Minefield), please reopen.

Comment 15

[Dave Evans]

Although the description of #379997 did not match my situation, I've just re-tested with firefox-3.0a7pre.en-US.linux-i686.tar.bz2 (md5sum ff7ab7f8c17318718c7e9169ba1173e9) and the problem seems to be fixed.
So I'd guess that the fix for #379997 did fix this bug, as well as the one it was intending to fix.

Comment 16

[Justin Dolske [:Dolske]]

Thanks for checking! Glad the issue is fixed, whatever it may have been. :)