58261 - [net6] Problems logging into groups via Netscape 6, Per Scopus #519899

Status: VERIFIED WORKSFORME

(Core :: DOM: Core & HTML, defect, P3)

Description

[matthew flansburg]

Per Scopus #519899
This is a major problem.  This is probably a Netscape 6 issue.  Component 
category of this bug probably not accurate.

Launch Netscape 6 version 27 October 2000
Go to http://groups.aol.com
Enter screen name field and incorrect password.
Receive "Authentication failed" message, re-sign in with correct screenname and 
   password.  Submit.
Taken to blank page:  https://groups.aol.com:443/_cqr/group_validate.adp

-apparently Mozilla does not recognize page?-

Log in problems seem only to occur when an incorrect password is initially 
given, or when you click on "forgot your password".  These problems do not occur 
on other versions of Netscape.

Comment 1

[Asa Dotzler [:asa]]

over to form submission.

Comment 2

[Asa Dotzler [:asa]]

forgot to reassign

Comment 3

[gerardok]

Confirmed failure on Win NT. I've saved the page from 
https://groups.aol.com:443/_cqr/group_validate.adp into a (unsecure) local 
server and it displays fine, but it fails to display when opened from aol 
website.

Comment 4

[matthew flansburg]

-Per Martin Lawyer

According to the log of the bug that is in scopus, it appears that Mozilla 
engineers are being misled by the fact that a "View
Page Source" in Netscape 6, for some unknown reason, attempts to reload the URL 
displayed in the location bar instead of
dumping the actual contents of the page it is trying to render from memory.  For 
an application such as Groups where pages
are generated dynamically, and especially in the middle of the login process 
(where Netscape 6 is hanging), this is completely
useless for debugging. 

By trial and error, I have been able to narrow the problem down somewhat from 
the webserver perspective.  During the
login process, there is a cookie set whose value is an encrypted string of 
varying length, but generally in the range of 80
characters.  If I remove the code that sets that cookie, the page begins to 
render properly in Netscape 6.  I was able to
determine that when the length of the cookie value is 31 characters or less, the 
page always renders.  At 32 characters, the
page occasionally doesn't render.  As I keep increasing the length of that 
cookie value, the page will render less and less
frequently, until finally it never renders at all.  Also, there are occasional 
errors where the HTTP headers will display onto the
screen, or the browser will attempt to save a file of unknown type.  In both of 
these instances, the HTTP header strings that
the browser displays look corrupted. 

In my opinion, there would seem to be a string overflow happening somewhere in 
the Netscape 6 cookie parsing code, and
some combination of events with Groups is triggering it.  I know that the 
webauth cookie is much longer than the one we are
trying to set, so I doubt it is a simple case of our cookie itself being too 
long.  There is no doubt much more to the story than
I can determine from the webserver side, but I was consistently able to 
reproduce/eliminate the page rendering problem by
changing the length of one cookie value.  And when the page doesn't render, I 
can go to the NS6 Cookie Manager and find
pieces of the HTTP headers inside some of the cookies. 

Unfortunately, I don't see an easy workaround at this point.  I tried breaking 
up the cookie in question into smaller pieces,
but it didn't help. 

I should point out that all of the Groups code in question (and the cookies it 
sets) will be going away with the changeover to
Magic Carpet. 

Comment 5

[Tom Everingham]

cc'ing Steve - cookie engineer type guy

Comment 6

[Stephen P. Morse]

If there is a string overflow problem, I doubt that it is in the cookie module.  
I have just observed a similar behavior in bug 51363 and I believe that this is 
probably a dup of that bug.  In that bug the cookie module didn't even get 
called.  In that bug I observed a curroption of the http response headers and I 
concluded that the problem might be a transmission one.

I am not able to reproduce this bug -- when I tried it on my winnt box it worked 
fine.  But I did notice some very big cookies in the traffic -- MR_DATA in 
particular which looks close to 1K.  

Comment 7

[Stephen P. Morse]

As I mentioned above, I'm pretty sure that this is a dup of bug 51363.  I just 
attached a patch for that bug to its report.

Since I cannot reproduce this bug, I am unable to test to see if the patch fixes 
this problem as well.  Can someone who can reproduce it please apply the patch 
and let me know if it fixes the problem.  Thanks.

Comment 8

[rods (gone)]

reassiging

Comment 9

[Chris Nalls]

Works for me using RTM on Win98 machine.
Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001108 Netscape6/6.0

Comment 10

[Marek Z. Jeziorek]

resolving as WORKSFORME per Chris Nalls comment.

Comment 11

[matthew flansburg]

I just confirmed and I can now log in to groups using my screen name.  Wow, that 
was a long path.  Good work everyone!