Closed Bug 193951 Opened 23 years ago Closed 23 years ago

Need to login to bugzilla even when login cookies are present

Categories

(Core :: Networking: Cookies, defect)

Product:
Core
Component:
Networking: Cookies
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED WORKSFORME

People

(Reporter: nnbugzilla, Assigned: darin.moz)

References

Details

Attachments

(3 files)

Zipped copy of cookie.log file
1.16 KB, application/x-zip-compressed
Details
HTTP header log when problem occurs
1.45 KB, application/x-zip-compressed
Details
cookies.txt -cookies not sent to server
5.72 KB, text/plain
Details
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.
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.
I will attach a cookie log the next time this happens. Unfortunately, I can't reproduce it at will.
*** Bug 194284 has been marked as a duplicate of this bug. ***
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.
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).
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.
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.
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?
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.
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 :)
HTTP log in ZIP format, captured when login problem occurs.
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.
OS: Windows 98 → All
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!
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.
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.
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. ;)
Dan, sorry, I should've mentioned. I've generally been using the latest nightlies, so your worries are over :)
well... okay... i'll reso/worksforme this, but if you see weird stuff along these lines in future, please reopen ;)
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
VERIFIED/wfm.
Status: RESOLVED → VERIFIED
QA Contact: tever → cookieqa
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...
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...
Cookies are enabled, and there is no restriction or site in exceptions (either for FB or Mozilla) ... I will generate a cookie
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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: