21813 - Logging on to slashdot userprofile doesn't work

Status: VERIFIED WORKSFORME

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

Description

[seer-snively]

This is one of the first times I've been able to type in the user and passwd

field on slashdot and click on the sumbit button (before, the entry fields have

jumped out of the way or been impossible to click on) but after I submit, it

doesn't "take".  It just reloads after a quick redirect.



Also, I've noticed that it's hard to tell when you have selected a feild to type

in.  It looks just the same and often "moved" the entry field to where it was

before you scrolled down far enough to type in it.



Related to this, I can't tab between fields at www.linux.org/cgi-bin/giveaway.html.

Comment 1

[Paul MacQuiddy]

this worksforme on 12/15 build, I think it may have gotten fixed yesterday

the tabbing and selection problems are well known :-)

Comment 2

[Paul MacQuiddy]

please grab a 12/15 build and see if it works for you, thanks!

Comment 3

[jspayne]

I am able to log on to the Slashdot main page, but when I click on "Read More"
my logged on status isn't passed to the next page.

Comment 4

[leger]

paulmac, try the step above with latest build.

seer-snively - please read 
http://www.mozilla.org/quality/bug-writing-guidelines.html
Please, you need to tell us which build on which version of Linux you are using. 
We support Redhat Linux 6.0, the current build is at:
http://www.mozilla.org/projects/seamonkey/release-notes/
Please let us know if your bug happens with the latest build.  Thanks!

Comment 5

[jspayne]

More comments - I reproduced this using NT, and found that If I logged in to the
article page, the login stuck.  The problem is really that logging into the main
page doesn't seem to count for the child pages.

Comment 6

[David Hallowell]

Tried on M13 and recent nightly builds (9 Feb 2000) under both Windows NT 4.0
and Linux Slackware 7 and the bug is not reproducable. If the problem still
seems to persist are you behind a caching proxy server. If you visit
http://slashdot.org/ and you've not logged in (i.e. no login cookie) the links
to the articles will be to the static versions of the articles (comments updated
only every few minutes). If you're behind a proxy then you may be getting dealt
the static version of the page which will make it appear that you're not logged
in. Even if you don't think you're behind a proxy remember that some ISP's
automatically redirect all web traffic through a proxy. Marking WORKSFORME.

Comment 7

[Joseph Elwell]

Although "[e-mail]" assertion is correct - I may be behind a 
caching proxy, I'm not certain this is working anyways. I have a feeling that 
cookies are acting peculiar. If I load http://www.slashdot.org/ I am logged in. 
If I load http://slashdot.org/ I am not logged in. The "Read More" links that 
people are clicking on and is causing them to log out are of the form 
"http://slashdot.org/blah" notice no www. Although if I check my cookies I have 
one for www.slashdot.org. But none for slashdot.org. Are cookies being sent only 
to the strict originating server? I have "accept all cookies" set and I wiped my 
profile today.

I suspect that this is true because although I might be behind a web caching 
proxy N4.61 shows me as logged in to both slashdot.org and www.slashdot.org

Steps I propose as a test:
1)Wipe your cookies.
2)Load www.slashdot.org
3)login
4)notice you're logged in.
5)load http://slashdot.org/index.pl
6)notice you're not logged in.

Comment 8

[jspayne]

I was able to reproduce this with M14/NT4.0SP5 by just creating a new profile:
1) Connect to www.slashdot.org
2) Log on and confirm
3) Connect to slashdot.org
4) Confirm no longer logged on

Comment 9

[leger]

Updating QA Contact.

Comment 10

[Stephen P. Morse]

This bug has morphed and that is a very bad thing.  Because now I don't know how 
to treat it.  I am therefore re-establishing the original summary line ("Logging 
on to slashdot userprofile doesn't work") rather than the morphed summary 
line ("cookie not recognizing www.slashdot.org as the same as slashdot.org") and 
closing it out as works-for-me per paulmac's and davidhallowell's comments in 
this report that said that it is working.

Now if you feel there is an additional cookie problem, please reopen as a 
separate bug.  However consider the following before doing so.  There are two 
kinds of cookies -- host cookies and domain cookies.  The type of cookie is 
established when the server originally sets the cookie -- the set-cookie header 
for a domain cookie contains a "domain=" atribute whereas a host cookie does 
not.  The difference between these two types of cookies is that a host cookie 
gets sent back only to the host that set the cookie whereas a domain cookie gets 
sent back to any host in the specified domain (of course the browser will not 
allow a host to set a cookie for a domain in which it itself is not a member).

Now if the site orignally set a host cookie, then the behavior as you described 
is correct behavior and not a bug.  You can verify this by trying the with a 4.x 
browser and see it it behaves the same way.  Furthermore, from seamonkey you can 
determine which kind of cookie you have as follows: go to the cookie viewer 
(accessible from the advanced pref panel under cookies) and look at the field 
name of the third entry of the cookie properties -- if it is "host" then you 
have a host cookie and if it is "domain" then you have a domain cookie.  You can 
also tell which type of cookie you have by looking at the cookies.txt file (this 
works for 4.x as well as seamonkey) -- domain cookies have a TRUE in the first 
entry on the line whereas host cookies have FALSE.

(Note: Had I not unmorphed this bug, then I would have had to close this out as 
invalid whereas the original bug report was probably perfectly valid.  That is 
why morphing bugs is bad.)

Comment 11

[Joseph Elwell]

I don't think this bug morphed, it just got progressively clearer what was 
happening to the reporter. Clearly this bug was poorly written - it has 3 
different bugs reported! Anyways, I filed a new bug - taking into account the 
cookie information that morse mentions - as bug 31401.

Comment 12

[leger]

This problem no longer occurs with 2000-03-22-06 builds.  Marking Verified.