49168 - Log-in failure

Status: VERIFIED FIXED

(Core :: Networking, defect, P3)

Description

[Matthias Versen [:Matti]]

Using : Mozilla 2000081008

When i try to enter these german Broker Page, I must enter a username and
a password.

If I do this, the password window appears a second time.
If I enter the name and password again, something happend but the
page will not load.

Works in : NS4.73, IE4
Expected result : The page will load and the password window appears only 1 time.

I have opend an account for testing.
Username : Mozilla
Password : Mozilla

Comment 1

[Doron Rosenberg (IBM)]

asas, can you reproduce this? I am having problems with it.

Comment 2

[Asa Dotzler [:asa]]

I've seen this at a couple of other sites.  will try to find the original
report.  this is likely a duplicate

Comment 3

[Matthias Versen [:Matti]]

I don't know, if this bug is a dupe but I can reproduce it everytime since
M16 (or before it).

[The Username/password are case sensitive, if you enter a wrong password you
most close Mozilla before you can try it again]

Mozilla try to load the page and you can see at the "status border" :
"Sending request to informer2.comdirekt.de" and after 1 second "Connecting to
imformer2.comdirekt.de" and Mozilla make a loop with this 2 "status messages"
I can see network traffic but Mozilla never loads the page.

Comment 4

[Asa Dotzler [:asa]]

updating component and seting default owner.  Confirmed with 082208 mozilla 
build on NT

Comment 5

[Gagan]

known dup. 

*** This bug has been marked as a duplicate of 32335 ***

Comment 6

[Dan Nunn]

vrfy dupe

Comment 7

[Darin Fisher]

This bug is actually a different problem.  The fix to bug 32335
eliminates the second dialog box, but it does nothing to fix the
latter symptom.  The page not reloading is a separate issue.

In this case, the initial page request returns a 401 response,
indicating that the request requires authentication.  We then
prompt the user for authentication (or if this page has been
authenticated previously) we automatically reply with the
necessary authentication.  The result is a 301 redirection to
/de/my/homepage/main.html.  We then request that page; however,
for that page the server responds with a 301 back to the original
page.  The result is that mozilla bounces between the two pages
and never stops.

4.x does not have this problem because it promotes the authentiation
header to the new request (in response to the first 301).  This seems
like a potential security hole, but basic auth is plain text anyways,
so maybe we should follow 4.x in this?  I'll have to take a close
look at the spec to see what it says about this case.

I'm also attaching a sample 4.x HTTP transaction for this site.  Notice
that that the authentication header is re-used.

Comment 8

[Darin Fisher]

Attachment: Netscape 4.X HTTP transaction log

Comment 9

[Darin Fisher]

Just one more point.  My understanding of the HTTP standard is that if
authentication is _ever_ required, then the server should respond with
a 401 "authentication required" error.  The fact that the server responds
with 301 violates this assumption.

If this assumption is true, then one thing we could do is place a limit on
the number of redirects and abort if the limit is ever exceeded.

Comment 10

[Gagan]

Hmmm... after looking at the logs me and darin agreed that this was a problem
with the way nsAuth compared the directories. In this case the last slash in the
path clearly is not the dir to compare. The correct fix for this is to cast the
nsIURI to an nsIURL in nsAuthEngine.cpp and get the directory part thru the
nsIURL interface. I have explained this fix to darin and am assigning this to
him, but I doubt this will make it for 6.0.

Comment 11

[Darin Fisher]

Attachment: Patch that can be applied to the trunk.

Comment 12

[Gagan]

r=gagan

Comment 13

[Scott MacGregor]

sr=mscott

Comment 14

[selmer (gone)]

rtm++

Comment 15

[Darin Fisher]

I landed this fix on the trunk, and the tinderbox didn't
complain.  Now, I'm waiting for my branch build to finish,
and then I'll land it there as well.

Comment 16

[Darin Fisher]

Ok, this fix is now on the branch as well.

Comment 17

[Blake Ross]

So can this be marked fixed...?

Comment 18

[Darin Fisher]

Yes!

Comment 19

[Tom Everingham]

verified branch:
Win98 1024

needs verified on trunk

Comment 20

[Rodney Velasco]

verified on trunk builds..
Oct. 24 RH7 Linux
Oct. 24 Winnt
Oct. 23 Mac OS9
Marking bug verified and removing vtrunk keyword