Closed
Bug 135668
Opened 22 years ago
Closed 20 years ago
ssl.dyndns.dk - Password manager deletes password when logging out
Categories
(Tech Evangelism Graveyard :: Danish, defect, P2)
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: allan, Unassigned)
References
()
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:0.9.9+) Gecko/20020404 BuildID: 2002040409 On https://ssl.dyndns.dk/domain/ password manager can store the password used, and this works fine. When I use the logout function on the page, password manager deletes the password again. Reproducible: Always Steps to Reproduce: 1. go to https://ssl.dyndns.dk/domain/ 2. log in as username: test and password: test 3. logout using the link at the buttom on the page. Actual Results: Password is deleted from passwordmanager. Expected Results: Passwords shouldn't get deleted. Passwords didn't get deleted with Mozilla 0.9.9 milestone, or prior releases. I noticed this behavior in nighty 20020320; but maybee it started before.
Comment 1•22 years ago
|
||
This is a really weird bug, I sign in and then when I sign out it keeps asking for my password and then when I'm exhausted trying that over and over, I go back to stop the dialog from coming up and then the password is no longer saved in password manager win XP build 2002040403
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•22 years ago
|
||
I just tried this on n4 and it appears that I need a username/password for http authentication. So how can I reproduce the bug without such. I tried on n6 and gave a phoney login. It asked me again and I repeated this a few times. Finally I just said cancel, and then got a crash. It was reproducible -- stack trace shown below. In any event, the crash is probably a separate bug. So what do I need in order to be able to reproduce this bug? Do I need to know a valid username/password? Terri, how were you able to reproduce it? nsCOMPtr<nsIEventQueue>::assign_with_AddRef(nsISupports * 0x046ae3d0) line 913 + 9 bytes nsCOMPtr<nsIEventQueue>::operator=(nsIEventQueue * 0x046ae3d0) line 585 nsEventQueueImpl::GetYoungestActive(nsEventQueueImpl * const 0x046ae3d4, nsIEventQueue * * 0x01f9fe5c) line 569 nsEventQueueImpl::GetYoungestActive(nsEventQueueImpl * const 0x00c5e304, nsIEventQueue * * 0x01f9fe94) line 565 + 42 bytes nsEventQueueServiceImpl::GetYoungestEventQueue(nsIEventQueue * 0x00c5e300, nsIEventQueue * * 0x01f9fec8) line 247 + 47 bytes nsEventQueueServiceImpl::GetThreadEventQueue(nsEventQueueServiceImpl * const 0x00c67028, PRThread * 0x008d2e50, nsIEventQueue * * 0x01f9ff14) line 386 + 41 bytes nsTimerImpl::Fire() line 428 + 57 bytes TimerThread::Run(TimerThread * const 0x013a5d30) line 225 nsThread::Main(void * 0x0138ff98) line 120 + 26 bytes _PR_NativeRunThread(void * 0x013bac10) line 433 + 13 bytes _threadstartex(void * 0x013baeb8) line 212 + 13 bytes KERNEL
Comment 3•22 years ago
|
||
I just got the same crash as above by doing something entirely different. Opened a separate bug on that crash (bug 136434).
Comment 4•22 years ago
|
||
Log in using username:test pass:test and you will be logged in (password is saved in password manager) then click the link to logout, dialog keeps coming up even when you use this same username and password and when you get sick of that and click cancel, password is not saved in password manager
Updated•22 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla1.1beta
Comment 5•22 years ago
|
||
I'm able to reproduce and I just stepped through it. It's the http auth module calling password manager to delete the user when the logout occurs. So that's why it is getting removed from password manager's list. Reassigning to http auth. Here's the stack trace. nsPasswordManager::RemoveUser(nsPasswordManager * const 0x03d543d0, const nsACString & {...}, const nsAString & {...}) line 188 nsHttpChannel::ClearPasswordManagerEntry(const char * 0x03b66130, int 0x000001bb, const char * 0x0012fb68, const unsigned short * 0x03c4e708) line 3217 + 41 bytes nsHttpChannel::GetCredentials(const char * 0x03addbc0, int 0x00000000, nsAFlatCString & {...}) line 1714 nsHttpChannel::ProcessAuthentication(unsigned int 0x00000191) line 1599 + 20 bytes nsHttpChannel::ProcessResponse() line 571 + 12 bytes nsHttpChannel::OnStartRequest(nsHttpChannel * const 0x038bd36c, nsIRequest * 0x03e54a3c, nsISupports * 0x00000000) line 2838 + 11 bytes nsOnStartRequestEvent::HandleEvent() line 161 + 53 bytes nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x047d3d34) line 116 PL_HandleEvent(PLEvent * 0x047d3d34) line 596 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00c50d18) line 526 + 9 bytes _md_EventReceiverProc(HWND__ * 0x004b0532, unsigned int 0x0000c143, unsigned int 0x00000000, long 0x00c50d18) line 1077 + 9 bytes USER32! 77e71268() 00c50d18()
Assignee: morse → darin
Status: ASSIGNED → NEW
Component: Password Manager → Networking: HTTP
QA Contact: tpreston → tever
Comment 6•22 years ago
|
||
necko calls nsIPasswordManager::RemoveUser when it believes that the username:password is no longer valid. that is, when it receives a 401/407 in response to a request sent with the username:password. so, this bug is very strange. hmm... i'll have to examine the testcase to see what's really going on.
Status: NEW → ASSIGNED
Comment 7•22 years ago
|
||
actually, it seems that upon loading /domain/logout/, mozilla provides the Authorization header; however, the website then sends mozilla a 401 response. as a result mozilla discards the username:password (both in it's http auth cache as well as in the password manager). since mozilla received a 401, it prompts the user for their username and password. entering a valid username and password however results in another 401 since the user has "logged out." the user must cancel the login dialog in order to leave the site. seems like a very odd design for a website. i'm not really sure what the website designers had in mind. perhaps they wanted to flush the browsers auth cache... i don't know. http auth was not designed with sessions in mind. i think this bug report is invalid. mozilla is doing the right thing. see bug 91968 which added the call to RemoveUser.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
Comment 8•22 years ago
|
||
Should this be an evangelism issue?
Comment 9•22 years ago
|
||
not sure... mozilla's behavior is identical to that of 4.x (except that 4.x doesn't have a password manager). perhaps we should let the TE team decide. reopening so i can reassign to TE.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Comment 10•22 years ago
|
||
-> TE
Assignee: darin → nitot
Status: REOPENED → NEW
Component: Networking: HTTP → Europe: West
Product: Browser → Tech Evangelism
QA Contact: tever → brantgurganus2001
Target Milestone: mozilla1.1beta → ---
Version: other → unspecified
Comment 11•21 years ago
|
||
passwords shout DEFINITELY not be deleted. if you got several logins for the same page (like different databases and phpMyAdmin ...) you NEED to log out to be able to get into the other database ... only way not to loose the password is currently to completely close browser and open again ... password manager remembers different passwords for the same page correctly and displays a selection what login to use, thus it should not delete password on logout :)
Updated•21 years ago
|
Summary: Password manager deletes password when logging out → ssl.dyndns.dk - Password manager deletes password when logging out
Comment 12•21 years ago
|
||
euro west non .com open bugs owned by tristan to other
Assignee: nitot → other
Component: Europe: West → Other
QA Contact: brantgurganus2001 → other
Comment 14•20 years ago
|
||
404, invalid
Status: NEW → RESOLVED
Closed: 22 years ago → 20 years ago
Resolution: --- → INVALID
Updated•9 years ago
|
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•