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

RESOLVED DUPLICATE of bug 379997

Status

()

Core
Networking: HTTP
--
major
RESOLVED DUPLICATE of bug 379997
14 years ago
10 years ago

People

(Reporter: Erik Rosenthal, Unassigned)

Tracking

({dataloss, regression})

Trunk
dataloss, regression
Points:
---
Bug Flags:
blocking-aviary1.0 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

14 years ago
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

14 years ago
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.
(Reporter)

Comment 2

14 years ago
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

14 years ago
Created attachment 132535 [details]
prompt.jpg screenshot

Adding screenshot prompt.jpg

Comment 4

14 years ago
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

14 years ago
Are you guys using a proxy?
(Reporter)

Comment 6

14 years ago
I am not using a proxy.

Updated

14 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 7

14 years ago
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

14 years ago
Updating summary as requested
Summary: Password forgotten when using web mail after logging out without closing browser. → Password manager forgets password when logging out from a site that uses a http authentication prompt

Comment 9

14 years ago
possibly related, bug 227632
(http auth, new password-mgr)
(Reporter)

Comment 10

14 years ago
Firebird 0.7 has the same bug.

Comment 11

14 years ago
same bug for firebird: bug 233989
*** Bug 233989 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Flags: blocking-aviary1.0?

Comment 13

13 years ago
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

13 years ago
cc'ing darin.   

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

Comment 15

13 years ago
sounds like this should go to darin....   sounds more like feature work for a
future release.  if that is not the case, renominate
Assignee: dveditz → darin
Flags: blocking-aviary1.0? → blocking-aviary1.0-
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

13 years ago
Created attachment 160698 [details]
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

13 years ago
Forgot to mention, this worked in 0.6 (Moz 1.3) and has been broken since 0.7
(Moz 1.4)
Keywords: regression
(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

13 years ago
*** Bug 253795 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
*** Bug 209910 has been marked as a duplicate of this bug. ***
*** Bug 209180 has been marked as a duplicate of this bug. ***
*** Bug 288163 has been marked as a duplicate of this bug. ***
*** Bug 233989 has been marked as a duplicate of this bug. ***
*** Bug 171035 has been marked as a duplicate of this bug. ***
*** Bug 229544 has been marked as a duplicate of this bug. ***

Comment 27

11 years ago
Changing application name to firefox as the ones duplicated against this one were about firefox.
Component: Password Manager → Password Manager
Product: Mozilla Application Suite → Firefox
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.
*** Bug 263626 has been marked as a duplicate of this bug. ***
*** Bug 198326 has been marked as a duplicate of this bug. ***
Component: Password Manager → Networking: HTTP
Product: Firefox → Core
QA Contact: tpreston → networking.http
Summary: Password manager forgets password when logging out from a site that uses a http authentication prompt → Password manager forgets site basic auth password upon each subseequent 401 Unauthorized
Created attachment 225836 [details]
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.
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.
Severity: normal → major
Summary: Password manager forgets site basic auth password upon each subseequent 401 Unauthorized → Password manager forgets site basic auth password upon each subsequent 401 Unauthorized

Comment 33

11 years ago
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.

Updated

11 years ago
Assignee: darin → nobody
Keywords: dataloss

Comment 34

11 years ago
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

11 years ago
*** Bug 357361 has been marked as a duplicate of this bug. ***
> 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.
OS: Windows XP → All
Hardware: PC → All

Comment 37

11 years ago
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

11 years ago
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

11 years ago
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

10 years ago
add me to cc

Updated

10 years ago
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 379997
You need to log in before you can comment on or make changes to this bug.