39610 - Bad http authentications not being deleted

Status: VERIFIED FIXED

(Core :: Networking, defect, P3)

Description

[Stephen P. Morse]

Go to a page requiring ftp authentication.
Authentication dialog appears
Enter an invalid password and check the save-password box
Press OK
Hangs on page load
Exit and reenter browser, return to same page
No authentication dialog is presented.
Hangs on page load

There are two problems here.  First, the ftp code should be reporting an error 
to the user which it never does but I presume that is covered in some other bug 
report -- it is not the topic of this report.  Second the ftp code should be 
informing the single-signon code to remove the bad login from the set of saved 
signons and it doesn't do that.  The second item is the topic of this report.

That second problem is very bad because as long as single signon has a saved 
password for this site, it never prompts the user again for a password in any 
return visits.

The same problems will occur for http authentication but it's not as severe -- 
in that case, when the page is revisited the authentication dialog indeed pops 
up but is prefilled with the original bogus values.  Those values would have 
been removed from the set of saved passwords had the http authentication code 
alerted the singon module that the values were bad.

This is a regression.  Such notification of bad values were being made by the 
ftp and http authentication modules at one time but were lost.  That happened 
when ftp and http suddenly stopped using single signon (bug 34725 and 34720) and 
the fix of those bugs did not restore the notification.

Comment 1

[Warren Harris]

I don't think ftp or http ever had any code to remove bad passwords after 
authentication failure. What's the SI API for this?

Comment 2

[Judson Valeski]

ftp never had delete bad auth code.

Comment 3

[Stephen P. Morse]

Both ftp and http authentication had such calls.  The API is

   void SI_RemoveUser(in string key, in wstring userName);

Comment 4

[Warren Harris]

I don't think they ever did, but we need to add them. Gagan, can you handle 
this now?

Comment 5

[Gagan]

I can take care of it for HTTP, jud can help on FTP. 

Comment 6

[Judson Valeski]

this is actually painful for ftp. If we include the user as part of the cached 
connection key, then we have to somehow cat the username (not sure where we 
could get it from) into URL's requested from the webshell/xul.

How's this done in HTTP? If I login into a domain, then I request another URL 
from that domain, does HTTP assume I'm accessing the 2nd url as the user that 
auth'd to the first one?

Comment 7

[Stephen P. Morse]

Sorry, I previously put the nsbeta2 nomination on the summary line instead of 
the keyword line.  No wonder it was never getting reviewed by PDT.

Comment 8

[leger]

Putting on [nsbeta2+] radar for beta2 fix. 

Comment 9

[Judson Valeski]

attatching proposed patch. steve can you please try this one out?

Comment 10

[Judson Valeski]

Attachment: proposed patch (cvs diff -c)

Comment 11

[Stephen P. Morse]

I tried out the patch and it works fine.  You can check it in with r=morse.

Comment 12

[Judson Valeski]

outtaa here!

Comment 13

[Stephen P. Morse]

Slow down!!!!!!!  This bug report covers both ftp and http.  You only fixed the 
problem for ftp as far as I know.

Comment 14

[Judson Valeski]

changing summary and over to gagan.

Comment 15

[Gagan]

Attachment: morse could you verify these as well--

Comment 16

[Stephen P. Morse]

Looks good to me. r=morse

Comment 17

[Gagan]

HTTP fix checked in. 

Comment 18

[Tom Everingham]

verified:
WinNT 2000072108