Bad http authentications not being deleted

VERIFIED FIXED

Status

()

Core
Networking
P3
normal
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: Stephen P. Morse, Assigned: Gagan)

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta2+], URL)

Attachments

(2 attachments)

(Reporter)

Description

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

Updated

18 years ago
Whiteboard: nsbeta2

Comment 1

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

18 years ago
ftp never had delete bad auth code.
(Reporter)

Comment 3

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

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

Comment 4

18 years ago
I don't think they ever did, but we need to add them. Gagan, can you handle 
this now?
Assignee: warren → gagan
(Assignee)

Comment 5

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

Comment 6

18 years ago
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?
(Reporter)

Comment 7

18 years ago
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.
Keywords: nsbeta2
Whiteboard: nsbeta2

Comment 8

18 years ago
Putting on [nsbeta2+] radar for beta2 fix. 
Whiteboard: [nsbeta2+]

Comment 9

18 years ago
attatching proposed patch. steve can you please try this one out?
Assignee: gagan → valeski

Comment 10

18 years ago
Created attachment 9158 [details] [diff] [review]
proposed patch (cvs diff -c)
(Reporter)

Comment 11

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

Comment 12

18 years ago
outtaa here!
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Reporter)

Comment 13

18 years ago
Slow down!!!!!!!  This bug report covers both ftp and http.  You only fixed the 
problem for ftp as far as I know.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 14

18 years ago
changing summary and over to gagan.
Assignee: valeski → gagan
Status: REOPENED → NEW
Summary: Bad ftp authentications not being deleted, hangs on all future loads → Bad http authentications not being deleted
(Assignee)

Comment 15

18 years ago
Created attachment 11387 [details] [diff] [review]
morse could you verify these as well--
(Reporter)

Comment 16

18 years ago
Looks good to me. r=morse
(Assignee)

Comment 17

18 years ago
HTTP fix checked in. 
Status: NEW → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 18

18 years ago
verified:
WinNT 2000072108
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.