220022 - Password manager forgets site basic auth password upon each subsequent 401 Unauthorized

Status: RESOLVED DUPLICATE of bug 379997

(Core :: Networking: HTTP, defect)

Description

[Erik Rosenthal]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030916
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030916

If I do web mail from home at the University of New Haven using Outlook in a
Mozilla window, the password will be forgotten under this very precise
circumstance: After reading mail, I log out but do not close Mozilla.  If I try
to log back in, the password will be forgotten.  However, if I close Mozilla and
then start again, it will remember the password.

Reproducible: Always

Steps to Reproduce:
1.  Check mail at a remote site using Outlook in a Mozilla window.
2.  Log out from the remote site but do not close the browser.
3.  Log back in to the remote site.

Actual Results:  
Password is forgotten.

Expected Results:  
Remembered the password.

Comment 1

[dolphinling]

Is this a password stored using the Mozilla Password Manager or a cookie? (If
it's a cookie) are you sure that logging out doesn't intentionally remove the
password? Try logging out, closing the browser, reopening the browser, and then
attempting to log back in.

Comment 2

[Erik Rosenthal]

This is a stored password -- it's listed among the stored passwords.  Also,
deleting cookies does not have any effect on this password.

Note that the problem did not exist with earlier versions of Mozilla (at least
not in Mozilla 1.3 and earlier).

Logging out and closing the browser does solve the problem, but, again, this
problem did not exist before.

Comment 3

[Nitin (vfwlkr)]

Attachment: prompt.jpg screenshot

Adding screenshot prompt.jpg

Comment 4

[Nitin (vfwlkr)]

I can confirm this bug on:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031002
and
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925 Firebird/0.7

Steps to reproduce:
- Go to any site that uses a http authentication prompt.
(see attachement prompt.jpg)
- Login with username and password. Check the "remember my password" box
- Go to Tools->Options->View Saved Passwords (on Firebird)
The password is shown as saved
- Logout 
The password is still shown as saved
- attempt to login again
I get the prompt.jpg prompt, with no prefill
- Cancel and go to Tools->Options->View saved passwords
The saved password is lost!

Comment 5

[Rune Skaug]

Are you guys using a proxy?

Comment 6

[Erik Rosenthal]

I am not using a proxy.

Comment 7

[Nitin (vfwlkr)]

Confirming (using my new canconfirm permissions)

Can someone modify summary from:
Password forgotten when using web mail after logging out without closing browser.
to:
Password manager forgets password when logging out from a site that uses a http
authentication prompt

Comment 8

[Jon Henry]

Updating summary as requested

Comment 9

[Nitin (vfwlkr)]

possibly related, bug 227632
(http auth, new password-mgr)

Comment 10

[Erik Rosenthal]

Firebird 0.7 has the same bug.

Comment 11

[Nitin (vfwlkr)]

same bug for firebird: bug 233989

Comment 12

[Brian Ryner (not reading)]

*** Bug 233989 has been marked as a duplicate of this bug. ***

Comment 13

[David Balažic]

How does the site "cancel" the login ?
AFAIK, there is no state remembered at the server side, but the client resends
the auth info with every request.

My wild theory is that when you click a "logout" link on the site, the server
temporarily changes the password, refuses the auth data from the browser and by
that causes the browser to forget(!) the remembered auth data, which lead to the
password being not saved anymore ( this bug ). A look at the HTTP traffic might
give some hints.

Excuse me, if what i said is nonsense ;-)

Comment 14

[chris hofmann]

cc'ing darin.   

dan, does it look like you will get a crack at this for 1.0?

Comment 15

[chris hofmann]

sounds like this should go to darin....   sounds more like feature work for a
future release.  if that is not the case, renominate

Comment 16

[Daniel Veditz [:dveditz]]

How do you "log out" of http auth? We've got bugs begging us to implement it.
Can someone capture an http header log of such a session?

http://www.mozilla.org/projects/netlib/http/http-debugging.html

Before attaching the output to the bug look it over and replace your password
with XXXXXXXXXXX (or be prepared to change it after everyone here sees it :-) )

Please try to keep the logging session as brief as possible to limit the output.

Comment 17

[Nitin (vfwlkr)]

Attachment: compressed http log of logout session

Session description:
- set variables
- start firefox
- visit my website cpanel (replaced in the log with http://www.mysite.net:2082)

- Press enter to accept the stored password
- let the page load
- click on the logout button
- click on the link "click here to login again"
- re-prompted without password prefill
- press cancel
- close firefox

Here's what seems a relevant portion of the attached log.. it says its clearing
bad auth cache entry:

0[274530]: nsHttpChannel::OnStartRequest [this=1f78f78 request=1fb9350
status=0]
0[274530]: nsHttpChannel::ProcessResponse [this=1f78f78 httpStatus=401]
0[274530]: nsHttpHandler::NotifyObservers [chan=1f78f78
event="http-on-examine-response"]
0[274530]: nsHttpChannel::ProcessAuthentication [this=1f78f78 code=401]
0[274530]: nsHttpChannel::ParseChallenge [this=1f78f78]
0[274530]: nsHttpChannel::GetCredentialsForChallenge [this=1f78f78 proxyAuth=0
challenges=Basic realm="cPanel"]
0[274530]: nsHttpAuthCache::GetAuthEntryForDomain
[key=http://www.mysite.net:2082 realm=cPanel]
0[274530]:   clearing bad auth cache entry
528[1089b70]: nsHttpConnectionMgr::OnMsgReclaimConnection [conn=1b8ab50]
528[1089b70]:	connection cannot be reused; closing connection
528[1089b70]: nsHttpConnection::Close [this=1b8ab50 reason=80004004]
528[1089b70]: nsSocketInputStream::CloseWithStatus [this=1fa0d34
reason=80004004]
528[1089b70]: nsSocketTransport::OnMsgInputClosed [this=1fa0ca0
reason=80004004]
528[1089b70]: nsSocketOutputStream::CloseWithStatus [this=1fa0d50
reason=80004004]
528[1089b70]: nsSocketTransport::OnMsgOutputClosed [this=1fa0ca0
reason=80004004]
528[1089b70]: nsHttpConnectionMgr::OnMsgProcessPendingQ
[ci=..www.mysite.net:2082]
528[1089b70]: nsHttpConnectionMgr::ProcessPendingQForEntry
[ci=..www.mysite.net:2082]
528[1089b70]: nsHttpConnectionMgr::ProcessPendingQForEntry
[ci=..www.mysite.net:2082]
528[1089b70]: Destroying nsHttpConnection @1b8ab50

Comment 18

[Nitin (vfwlkr)]

Forgot to mention, this worked in 0.6 (Moz 1.3) and has been broken since 0.7
(Moz 1.4)

Comment 19

[Robert Accettura [:raccettura]]

(In reply to comment #16)
> How do you "log out" of http auth? We've got bugs begging us to implement it.
> Can someone capture an http header log of such a session?
> 

From http://webdeveloper.mozdev.org/
---------------
// Clears the HTTP authentication 	 
 function webdeveloper_clearHTTPAuthentication() 	 
 { 	 
     const authenticationManager =
Components.classes["@mozilla.org/network/http-auth-manager;1"].getService(Components.interfaces.nsIHttpAuthManager);
	 
     const stringBundle          =
document.getElementById("webdeveloper-string-bundle"); 	 
  	 
     authenticationManager.clearAll(); 	 
     alert(stringBundle.getString("webdeveloper_clearHTTPAuthenticationResult")); 	 
 }
---------------

The trick I've always known for http logout is what yaroukh at email dot cz
discribes in the php documentation (see yaroukh at email dot cz in the comments
area):
http://us2.php.net/features.http-auth

Comment 20

[Nitin (vfwlkr)]

*** Bug 253795 has been marked as a duplicate of this bug. ***

Comment 21

[Nelson Bolyard (seldom reads bugmail)]

*** Bug 209910 has been marked as a duplicate of this bug. ***

Comment 22

[Nelson Bolyard (seldom reads bugmail)]

*** Bug 209180 has been marked as a duplicate of this bug. ***

Comment 23

[Nelson Bolyard (seldom reads bugmail)]

*** Bug 288163 has been marked as a duplicate of this bug. ***

Comment 24

[Nelson Bolyard (seldom reads bugmail)]

*** Bug 233989 has been marked as a duplicate of this bug. ***

Comment 25

[Nelson Bolyard (seldom reads bugmail)]

*** Bug 171035 has been marked as a duplicate of this bug. ***

Comment 26

[Nelson Bolyard (seldom reads bugmail)]

*** Bug 229544 has been marked as a duplicate of this bug. ***

Comment 27

[Nitin (vfwlkr)]

Changing application name to firefox as the ones duplicated against this one were about firefox.

Comment 28

[Nelson Bolyard (seldom reads bugmail)]

It appears that anytime an http server asks for http basic auth AGAIN,
after it has already asked for and received authentication once,
this causes the password manger to forget the user name and password
that it had previously stored for that server.  

I can reproduce this 100% at will.  
I have resorted to changing the permissions on my password file to read-only.
That keeps password manager from deleteing it from the file, but does not
prevent password manager from forgetting the passwords in the process.
So each time password manager forgets my password, I just have to restart the
browser, and it remembers them again.  :)

The problem is seen in both FireFox and Seamonkey.

Comment 29

[Nelson Bolyard (seldom reads bugmail)]

*** Bug 263626 has been marked as a duplicate of this bug. ***

Comment 30

[Nelson Bolyard (seldom reads bugmail)]

*** Bug 198326 has been marked as a duplicate of this bug. ***

Comment 31

[Nelson Bolyard (seldom reads bugmail)]

Attachment: log of http requests and responses leading to forgotten password

This log of HTTP requests and responses shows the first authentication to 
the server.  The first request gets a "401 Unauthorized", which displays
a basic auth dialog, filled with the user name and password from the 
browser's store of saved passwords.  This info gets sent in in base64
encoded form with the basic auth header with the resent request, and it 
works, the first time.

Then after a 10 minute delay, another attempt is made to contact the server.
The request includes the same base64 encoded auth, but this time the server
responds with another "401 Unauthorized".  That causes the password manager
to forget the previously stored user name and password, and present me with
a blank basic auth dialog.  At that point, the previously save user name
and password are completely lost, no longer stored among the saved passwords.

Comment 32

[Nelson Bolyard (seldom reads bugmail)]

I think we can call this failure of the password manager "major" in light of 
all the duplicate bugs.

BTW, mailnews has the same problem for NNTP servers.  See bug 286628.

Comment 33

[Jerry Baker]

I would like to add just in case anyone isn't sure, the problem isn't that the user is prompted again when a HTTP 401 is received, but that saved username:password combinations are permanently removed from the password manager. In my case I usually save passwords that have minimal security ramifications, but I forget them pretty soon afterwards. Whenever this bug happens I have to go through procedures to reset my password because I don't remember what it is and Firefox has deleted it.

Comment 34

[Ted Anderson]

We should change OS to all because this has been plaguing me since 2003 on Linux as well. Definitely not FF as it occurs on all Mozilla-based browsers.

Odd that bugs opened before this one with helpful info have been marked dupes of this bug, but I guess you needed to choose one as the master.

3 years already! Wouldn't it be nice to close this out someday?

Comment 35

[Ted Anderson]

*** Bug 357361 has been marked as a duplicate of this bug. ***

Comment 36

[Nelson Bolyard (seldom reads bugmail)]

> We should change OS to all because this has been plaguing me on Linux as well.
Done.

> Definitely not FF as it occurs on all Mozilla-based browsers.
Yes, but FF bugs get worked on, others don't.
Notice how the assignee became "nobody" when this became a "core" bug.

Comment 37

[!Mike]

Thanks for all your work - but I'm no longer interested in having my old bugreport from 2002 tracked. (or dupe-linked to a newer id once in a while)
Never mind, I just live with it.

Comment 38

[stephen vermeulen]

I have confirmed the same problem with SeaMonkey 1.0.4 and Firefox 1.5.0.9.

I encountered this problem with a site that uses the HTTP digest authentication system (rather than BASIC authentication) that I have written. The cause of this is my desire to be able to put a "logout" link or button on a web page, so the user can see to click on this to logout. Once the user clicks on the logout link I have the server reset its state so that when the user later clicks on something that takes him into the site again the server will restart the digest authentication challenge. Doing this confuses both Firefox and Seamonkey (but IE and older Mozilla handle it fine). 

I have noticed that in Seamonkey there is a Tools / Password Manager / Log out menu item, and if the user selects this then Seamonkey internally logs him off and then the site will rechallenge him correctly and Seamonkey will resupply the user name and password (it will even allow you to switch between multiple accounts on the same site which is handy for testing).  However, there does not seem to be an equivalent browser log off function in Firefox, so I can't ask users to do that.

Comment 39

[Ingo Schmidt]

Since this seems to be the major bugreport on this problem, I will repeat my thoughts on it, hoping that this bug is finally cleared out:


It needs deliberate action by the user to put a password into the password manager. So it needs deliberate action to remove it from there.

So the current behaviour is indeed a bug (in contrast to the opinion that this is "by design", an opinion I had to fight against...)

Besides that, no other browser in the world behaves that way.

Is it really that hard to fix this bug? Every user with a router, where you can login and logout must have come across this problem!

So please, someone fix it. So many dupes about it. Thank you.

Comment 40

[Quan Lin]

add me to cc