193951 - Need to login to bugzilla even when login cookies are present

Status: VERIFIED WORKSFORME

(Core :: Networking: Cookies, defect)

Description

[Warner Young]

Every once in a while, I find that I have to login to Bugzilla again.  When this
happens, I can check Cookie Manager and see that the Bugzilla login cookies are
present, so I don't know why Bugzilla isn't picking this up.

Possibly, related to bug 188850, but a check of cookies.txt shows only 180 lines
or so.

Also possibly bug 179770, but I checked my IP address as directed there, and it
doesn't change from reload to reload.

Comment 1

[[e-mail]]

Reporter: can you generate a cookie log that shows this problem?

Procedure (on windows):
Start a command shell (Start/Run/"cmd"), and do the following:

1) change to your mozilla directory (usually c:\program files\mozilla.org\mozilla)
2) type "set NSPR_LOG_FILE=c:\cookie.log", enter
3) type "set NSPR_LOG_MODULES=cookie:4", enter
4) run mozilla by typing "mozilla", enter.

This will start mozilla with cookie logging enabled - see if you can reproduce
the problem, and then check the cookie log file to make sure it shows up. You're
looking for a line that says something like "=== COOKIE NOT SENT ===" for the
bugzilla cookie.

If you could attach the logfile to the bug, that'd be great.

Comment 2

[Warner Young]

I will attach a cookie log the next time this happens.  Unfortunately, I can't
reproduce it at will.

Comment 3

[R.K.Aa.]

*** Bug 194284 has been marked as a duplicate of this bug. ***

Comment 4

[Warner Young]

Dan, this problem finally happened again, and I captured a cookie log as you
asked.  I do see one "COOKIE NOT SENT", but I don't understand the log format
enough to see if this help.  I'll attach the log file (zipped).

I also double-checked in Cookie Manager, and my Bugzilla_login and
Bugzilla_login_cookie are still listed.

Comment 5

[Warner Young]

Attachment: Zipped copy of cookie.log file

Comment 6

[[e-mail]]

Hmm, the logfile you attached is showing some peculiarities - it's showing
cookie strings which differ from the cookie data that's actually set (they
should both be the same).

Which version did you generate this logfile with? There was a logging anomaly in
1.3b, so if you could reproduce the logfile using a current 1.3 or 1.4 trunk,
that might help. (Preferably a 1.4 trunk, since there were some big cookie
changes in that).

I'm also not seeing any Bugzilla_login or Bugzilla_login_cookie. This is
probably because the logfile is truncating the entries (the buglist portion of
the cookie is long). I suspect the problem is the way Mozilla sends back the
cookies - maybe something's getting mangled.

Can you try using a program to sniff the http headers of the bugzilla
transaction? Something like livehttpheaders might help - visit
http://livehttpheaders.mozdev.org/ and click on 'installation'. Hopefully this
will show a non-truncated version of what Mozilla is sending back to the
bugzilla server, which would show what the problem is.

Procedure to use livehttpheaders:
1) after installing, click on 'tools/web development/live http headers'
2) reproduce the problem
3) click 'save all' to save the log.

Note that your bugzilla login and password will be viewable in the logfile, so
you should do a search/replace for your password. (the http header is more
important than getting a cookie log from a newer trunk build, so if you don't
want to do both, then the http header will be more useful).

Comment 7

[Warner Young]

Dan, I got the log file with today's trunk build (2003 022508).  I'll try
livehttpheaders and see what I come up with.  I backed up the cookie file before
logging back in, so hopefully I can now reproduce the problem at will.

Comment 8

[Warner Young]

Dan, am I looking for actual text that says "password" in the livehttpheader
file, or is it called something else?  I ask because I've captured the header
from problem login, but I don't see anything that might be my bugzilla password
in the file.

Comment 9

[[e-mail]]

That could well be the problem. no password = no login :)

In the test log I did, the password itself was visible. So search for your
actual password...

btw, interesting that your cookie log was from today's trunk. In this case, one
of my recent landings may have horked logging somehow... I'll look into it. When
did you start seeing this login problem?

Comment 10

[Warner Young]

Dan, I think I started seeing this problem about a month ago, maybe a little
more.  I'm sure if I'd seen it much earlier, I would have filed a bug much sooner.

Something else I can do: I have a copy of the "bad" cookies.txt file and a
"good" one.  Although I don't want to share the files themselves (if I really
don't have to), is there anything I can check on this end?  Copying the "bad"
file into my profile directory will automatically trigger this problem, but
whether that's the problem itself or merely a symptom, I don't know.

Comment 11

[[e-mail]]

About the cookie files - it's hard to say what we're looking for. However, given
that you're sure the problem isn't related to bug 188850 (remember, if you have
20 cookies from bugzilla.mozilla.org then that could be the problem), then we
can isolate the problem to just the bugzilla login cookies. So you could edit
the two files and remove everything except those two cookies, delete passwords
etc from the cookie data, and then mail it to me or post it here.

But for now, just the http headers would be great :)

Comment 12

[Warner Young]

Attachment: HTTP header log when problem occurs

HTTP log in ZIP format, captured when login problem occurs.

Comment 13

[Patrick]

Also occurs on Mandrake Linux 9.1 RC1. Setting OS -> ALL

Also occurs on other sites. Perhaps the summary should be changed to reflect that?
In fact, it works with Bugzilla for me, but not with Gamespot.com.

Comment 14

[[e-mail]]

Warner: i haven't had a chance to look into this in more detail yet, sorry. In
the meantime, would it be possible for you to test 1.4a and see if you can
reproduce the problem there? it's possible it may be fixed already, since we had
a lot of cookie work go in recently. thanks!

Comment 15

[Warner Young]

Dan, well, I haven't see this happen in a while, so it MAY be fixed.  I've
switched to using Phoenix now, but I imagine that shouldn't matter for this bug.
 If I still don't see it for the next few weeks, then it's probably fixed.

Comment 16

[Warner Young]

Dan, I haven't seen this bug at all in the last 2 months, so I think it's safe
to say it's fixed.

Comment 17

[[e-mail]]

Great... kinda :/

what version of moz have you been using for these past 2 months?
if it's 1.4-based, i'm happy... if it's the same one you've been using all along
(1.3), i'm not. ;)

Comment 18

[Warner Young]

Dan, sorry, I should've mentioned.  I've generally been using the latest
nightlies, so your worries are over :)

Comment 19

[[e-mail]]

well... okay... i'll reso/worksforme this, but if you see weird stuff along
these lines in future, please reopen ;)

Comment 20

[benc]

VERIFIED/wfm.

Comment 21

[lakshmi]

Attachment: cookies.txt -cookies not sent to server

though this is my requested file..
http://www.superseva.com/products/superticketing.asp
the session is not identified and the  URL:
http://www.superseva.com/scripts/nosession.asp
is accessed ..
this is only in version 1.4 ,1.2..its fine in IE and other Mozilla versions...

Comment 22

[[e-mail]]

i doubt your comment is relevant to this bug... but looking at your log, i
wonder if it's the 'empty path' bug again. we might want to assume "/" if a site
gives an empty "path=" attribute, not the current path like we do at the moment...

Comment 23

[Jean-Michel Reghem]

Cookies are enabled, and there is no restriction or site in exceptions (either
for FB or Mozilla) ...
I will generate a cookie

Comment 24

[David Barratt]

The People that made the shopping cart System is: Secure Shops.
http://www.secure-shops.com/

They don't really give me controll over the cokies that go in and out of the
website.