Weird cookie behavior on Slashdot

VERIFIED INVALID

Status

()

Core
Networking: Cache
P3
normal
VERIFIED INVALID
18 years ago
17 years ago

People

(Reporter: Matthew Cline, Assigned: neeti)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

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

18 years ago
The bug description is too abstract.  Please give a more detailed sequence of 
steps for reproducing the problem.
(Reporter)

Comment 2

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

Comment 3

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

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 4

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

Comment 5

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

Comment 6

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

Updated

18 years ago
Summary: Weird cookie behavior with Slashdot → Weird cookie behavior with Slashdot (linux only)

Comment 7

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

Comment 8

18 years ago
Also take a look at bug 46514.

Updated

18 years ago
Keywords: nsbeta3

Comment 9

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

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

Comment 11

18 years ago
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.
Assignee: morse → neeti
Status: ASSIGNED → NEW
Component: Cookies → Networking: Cache
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

18 years ago
Target Milestone: --- → M18

Comment 12

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

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

Comment 14

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

Comment 15

18 years ago
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=matt@nightrealms.com; 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.
Summary: Weird cookie behavior with Slashdot (linux only) → Cookie service created AFTER 1st HTTP request if component.reg missing (linux only)

Comment 16

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

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

Comment 18

18 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → INVALID
Summary: Cookie service created AFTER 1st HTTP request if component.reg missing (linux only) → Weird cookie behavior on Slashdot

Comment 19

17 years ago
vrfy invalid
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.