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)

x86
All
defect

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.
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
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

I just got the same crash as above by doing something entirely different.  
Opened a separate bug on that crash (bug 136434).
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
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla1.1beta
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
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
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
Should this be an evangelism issue?
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 → ---
-> 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
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 :)
Summary: Password manager deletes password when logging out → ssl.dyndns.dk - Password manager deletes password when logging out
euro west non .com open bugs owned by tristan to other
Assignee: nitot → other
Component: Europe: West → Other
QA Contact: brantgurganus2001 → other
move to new danish component
Component: Other → Danish
404, invalid
Status: NEW → RESOLVED
Closed: 22 years ago20 years ago
Resolution: --- → INVALID
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.