45468 - Weird cookie behavior on Slashdot

Status: VERIFIED INVALID

(Core :: Networking: Cache, defect, P3)

Description

[Matthew Cline]

Whenever I install a new nightly build on Linux, Slashdot responds in
a strange manner.  The very first time I start up Mozilla from the
latest install, it acts like I'm not logged into Slashdot (when, in fact,
I am).  If I exit from Mozilla and start up again, everything is fine.

However, if instead of exiting from Mozilla, I try to login to Slashdot,
Sladhot returns me to index.pl like I succeeded, but I still get the
default page rather than my customized page, like the Slashdot cookie
wasn't geting set.

I've seen this behavior for a while, and it's still there with
build 2000071308.

Comment 1

[Stephen P. Morse]

The bug description is too abstract.  Please give a more detailed sequence of 
steps for reproducing the problem.

Comment 2

[Matthew Cline]

Steps to reproduce:

1) Get an account on Slashdot.
2) Using Mozilla, log into that Slashdot account.
3) Customize the account's frontpage options to the point where it's
   the front page while logged in is obviously different from th
   front page while logged out.
4) Exit from Mozilla.
5) Download and install a new Mozilla nightly build.
6) Start up the just installed Mozilla and vist Slashdot.  The front page
   will be like you aren't logged in, although you have a slashdot cookie
   that has your login information.

Now, you can either:

1) Exit Mozilla, restart it, and visit Slashdot again.  Now everything will
   be fine.

or

2) Enter your username and password into the approriate text fields and click
   on the "login" button.  You'll be returned to the Slashdot front page,
   but it will still look like you aren't logged in.

Comment 3

[Matthew Cline]

Alright, I've simplified the test case a little.  The new steps are:

4) Exit from Mozilla.
5) Delete the file component.reg, wherever it might be.
6) Start up Mozilla and visit Slashdot.  The front page will be like you
   aren't logged in, although you have a Slashdot cookie.
   that has your login information.

Comment 4

[Stephen P. Morse]

Unable to reproduce using win32.  Of course the sequence of steps is still not 
detailed enough -- in particular I have no idea how to "customize the account's 
front page."  But it is recognizable when I'm logged in as it says:

    This page was generated by a Group of Random Geese for <username>

I created the account using 4.x.  I ran mozilla, went to the page and logged in.  
The above message was displayed.  I closed the browser, deleted the two copies 
of component.reg (one in bin and one in bin/psm) and restarted.  Went back to 
the page.  Without any explicity login I saw the above message indicating the I 
was logged in.

Could this be a linux-only problem?  Have you tested using win32 to see if you 
can reproduce the problem there?

Comment 5

[Matthew Cline]

Right, the "This page was generated by <sillyness> for <username>" is
enough to show that you're logged in.

I will attempt to reproduce with Win32.

Comment 6

[Matthew Cline]

Unable to reproduce on Win32 with the latest build.  Looks like a Linux
only problem.

Also, as an addition to the recipe, Slashdot should be the homepage while
testing, and the browser should start up on the homepage.

Comment 7

[Stephen P. Morse]

Take a look at 40449.  These two bugs sure seem to be related.

Comment 8

[Stephen P. Morse]

Also take a look at bug 46514.

Comment 9

[gabriel]

I've also noticed this with the Linux nightlies, most recently 2000072408. When
I get a new build, I generally set Slashdot to be my home page. I have to log in
*twice* before my logged in page comes up.

This is my method of reproducing this bug:
(Assuming you have an account on Slashdot, and a new build)

1) Set your homepage to Slashdot. Exit mozilla.

2) Start up mozilla, log in. (Doesn't seem to matter whether you store the form
details or not).
3) Page which is shown is non-logged in page.
4) Log in again.
5) This time you get the logged in page.

Comment 10

[WD]

I also notice the problem with having to log in twice on Win32 machines, too.

Comment 11

[Stephen P. Morse]

Although I haven't investigated this particular case, it is probably another 
example of a cache problem (similar to 46514) rather than a cookie problem.  
Reassigning to Neeti.  If I'm wrong, then assign it back to me and I'll 
investigate further.

Comment 12

[WD]

Note:    If your cookies aren't set already, you need to log in *twice* whether
you are using Mozilla, Netscape, or IE....    all platforms, too!

It would appear that something is flawed with the login / cookie setting on
Slashdot.    I believe it started happening a couple of months ago when Slashdot
switched servers, and it hasn't been corrected since.    Because the default
action is to save the cookie, it just was probably overlooked.

Comment 13

[Stephen P. Morse]

Based on wdormann's last comment, I would conclude that this is certainly a 
server problem and not a browser one.  Especially if it is happening on netscape 
4.x and on IE as well.  So we probably should close this out as invalid but I'll 
leave that to neeti to decide.  In any case, it no longer seems to be a cache 
problem.

An obvious suggestion is for someone to notify the site.  But from past 
experience, I have found that to be an excercise in futility.

Comment 14

[Matthew Cline]

This (might) be two seperate problems: having to log in twice, and not
being logged in at all if you start up Mozilla with no component.reg file.
Unless the two problems are basically the same, I don't think that this
bug should be closed.

Comment 15

[Matthew Cline]

Alright, I've got some more information on this.  By putting debugging
statements into the latest CVS build, I've found that the cookie
service is only created *after* the first HTTP connection is
completed, if the component.reg file is not present when Mozilla
starts up.  Thus, if you're homepage uses cookies, its not going to
get them until you go to some other page, then back to your homepage.

As an example, here are the HTTP request headers as sent from Mozilla
when it was started up with no component.reg file:

=============================
Slashdot (homepage, first page loaded):
GET / HTTP/1.1
Host: www.slashdot.org
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14 i686; en-US; m18) Gecko/20000528
Accept: */*
Accept-Language: en
Accept-Encoding: gzip,deflate,compress,identity
Keep-Alive: 300
Connection: keep-alive

Bugzilla (viewed after slashdot):
GET / HTTP/1.1
Cookie: Bugzilla_login=[e-mail]; Bugzilla_logincookie=64197;
LASTORDER=bugs.bug_id; COLUMNLIST=opendate severity platform status resolution
summary; SPLITHEADER=0; PLATFORM=Browser; VERSION-mozilla.org=other;
VERSION-Browser=other; VERSION-MailNews=other; VERSION-Webtools=other
Host: bugzilla.mozilla.org
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14 i686; en-US; m18) Gecko/20000528
Accept: */*
Accept-Language: en
Accept-Encoding: gzip,deflate,compress,identity
Keep-Alive: 300
Connection: keep-alive

Slashdot (homepage, viewed after Bugzilla):
GET / HTTP/1.1
Cookie: user=[deleted; I'm not telling anyone my Slashdot cookie :-) ]
Host: www.slashdot.org
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14 i686; en-US; m18) Gecko/20000528
Accept: */*
Accept-Language: en
Accept-Encoding: gzip,deflate,compress,identity
Keep-Alive: 300
Connection: keep-alive

==============================

The same behavior happened if I made Bugzilla my homepage: Mozilla
didn't send any cookie until I visited some other page, then went
back to Bugzilla.

Comment 16

[gabriel]

I've just noticed that the 'double login' problem occurs with NS4 as well. I
agree with Morse that it's a server problem, and therefore this part of the bug
is invalid.

Comment 17

[Stephen P. Morse]

This bug has been morphed and is now difficult for people to understand 
(there's a lot of non-relevant comments that they have to read through).  I 
suggest that the original summary line be restored (referring to the double 
login) and this bug then be closed out as invalid because it is a server issue.  
Then a fresh bug be opened on the new symptoms as you have described them along 
with your understanding of why it is happening.

Also, you seem to have a very good grasp on what the problem is from the 
debugging that you've already done.  Do you have a suggested patch to fix the 
problem?

Comment 18

[Matthew Cline]

Marking this bug as invalid, since the two-login problem with Slashdot
is Slashdot's problem.  The other portion of the cookie bug has been
reincarnated in bug 46989.

And Morse: I have no idea of how to fix this thing.  I only know that
the cookie service is created too late; I have no idea why this is happening,
though.

Comment 19

[Blake Ross]

vrfy invalid