User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 Similar to bug 223469 Creating a site using JBoss/Tomcat 4.0.2 that requires making changes to the JSESSIONID cookie for failover and session management. Rather than replacing the value a duplicate cookie is created. Worse yet the cookies can't be expired either properly either. It appears that all cookies are held regardless of updates from the server until the session ends (closing the browser) This poses major issues for site designers since there should only be one cookie from the same domain, cookie path and ID. Most session cookies by sites are only written once but this could pose a security issue, since when a user logs out of a site the cookie should be deleted but in this case cookie isn't removed until after the browser is closed. For most home users not a big issue but for those working in other situations this could expose information. Reproducible: Always Steps to Reproduce: 1.go to a site that sets cookie 2.go to a jsp/servlet page that changes the cookie value 3. Actual Results: Duplicate cookies created with the same ID. Expected Results: One cookie updated.
Assignee: nobody → darin
Component: General → Networking: Cookies
Product: Firefox → Core
QA Contact: general → networking.cookies
Version: unspecified → 1.7 Branch
This doesn't need to be security sensitive (but thanks for erring on the side of caution). This is not similar to bug 223469, this *is* bug 223469. Just as that was WFM so will this unless you can provide more details on how to reproduce it. An example site? By specifying a jsp server app I assume you're talking about setting the cookies using HTTP headers. If you can't find a public site that exhibits this problem (I assume you're not going to let us poke at the server you're building or you'd have given us the address) please capture some logging data for us. http://bclary.com/2004/04/10/web-site-qa#nspr http://www.mozilla.org/projects/netlib/http/http-debugging.html Probably logging just the cookie data might be enough to start, or cookie and nsHttp:3 By any chance does your page set document.domain? that might be confusing things... (It shouldn't, but I'd like to rule it out or explicitly check into it if you're using it).
Reporter, can you answer the questions in comment 1?
I can reproduce this problem but the URL I cannot put here. Because it's not global web site(bugzilla). I could see two cookies that names are same. But these third field name(caption?) on the cookie viewer on Fx1.6a were different that are 'domain' and 'host'.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Er.. domain and host cookies are different things. So what you see is correct. If that's all there is to this bug, it's invalid.
(In reply to comment #5) > Er.. domain and host cookies are different things. So what you see is correct. > If that's all there is to this bug, it's invalid. But by this duplicated, the bugzilla cannot manage user log-in session. I deleted the cookie that has 'host', and I log-in to the bugzilla, another cookie that has 'domain' are overwritten to 'host' by the bugzilla...
If you are having problems with a particular Bugzilla installation setting the wrong kind of cookies, please seek help with the configuration, or file a bug within the Bugzilla product providing the relevant configuration information and details on exactly what cookies are being set, etc..
Umm... I don't have enough knowledge for cookie spec... I'll check cookie spec and check netwerk/cookie code. If I found bugzilla's bug, I'll report. thanks,
Well, this got confirmed for no reason, there's no response from reporter... Marking invalid until someone has some hard data actually showing a problem in Mozilla.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.