DO NOT REPLY [Bug 35606] New: - Problem with Session cookies and multiple webapps on different ports or subdomains
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35606. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35606 Summary: Problem with Session cookies and multiple webapps on different ports or subdomains Product: Tomcat 5 Version: 5.0.27 Platform: Other OS/Version: other Status: NEW Severity: major Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] When i run two instances of tomcat on different ports and access the first webapp, a session is created. when i access the second webapp, a new session is created. but this overwrites the session cookie of the first webapp. The same happens when i have a webapp on a domain (e.g. test.com) and a second webapp on a subdomain (other.test.com), but not in all cases (i think it depends on which domain i call first). The problem could be solved if the cookie name could be changed but this will violate the specs afaik. In Bug 16822 is a description how the problem could be solved otherwise: tomcat should use a session id supplied by the client when this is not already in use. in this case both applications would use the same session id (which should case no problems because they have different classloaders). Michael. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34349] - cookies=false with request mit session cookie
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34349. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34349 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-05-03 16:10 --- Dietmar, please use the tomcat-user and tomcat-dev mailing lists to solicit clarification, rather than reopening Bugzilla issues. Thank you. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34669] New: - Cookies are not always parsed on simultaneous request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34669. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34669 Summary: Cookies are not always parsed on simultaneous request Product: Tomcat 5 Version: 5.0.28 Platform: PC OS/Version: Windows XP Status: NEW Severity: major Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I find that despite there being an incoming JSESSIONID cookie, sometimes this doesn't make it into the requests Cookies. I've confirmed this by trapping the case in my servlet filter, and then examining the request. In this case I can see the cookie header, but the cookies are empty. Some specifics - I'm using JBoss 4.0.1sp1, which has Tomcat 5.0 embedded. The use of the session is in a servlet filter for security. I store a JAAS subject on the session in my login form, and I test the existence in the filter. The pages generated by the application then make many other requests. IE correctly sends the cookie in the requests, but sometimes, perhaps one in five or one in ten requests, the cookie is ignored as stated in the first paragraph. I access the sessions using synchronized blocks to avoid multiple simul updates. I tried adding a sync on the doFilter method on the off chance that there was a session issue (although, as noted above, the issue appears to be due to the cookies). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34669] - Cookies are not always parsed on simultaneous request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34669. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34669 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-04-28 18:07 --- I am sorry, but I simply do not believe you. Objects used for reading and parsing the requests are per thread, and as a result are fully independent (this includes headers and cookies). If you believe there's an issue, you'll have to investigate it yourself, and submit a fix (or at least find out what goes wrong inside the Tomcat code, and where). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34669] - Cookies are not always parsed on simultaneous request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34669. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34669 --- Additional Comments From [EMAIL PROTECTED] 2005-04-28 18:22 --- I will do more investigation. But I don't believe you isn't a particularly reasonable response. It may be the fault is outside of Tomcat, but it really is hard to argue with what I saw in the debugger. If I had a dollar for every time I thought that, and later found the problem I could probably retire. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34669] - Cookies are not always parsed on simultaneous request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34669. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34669 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2005-04-28 20:00 --- OK, I've done more investigation. I believe what's happening is that the unprocessed flag in the cookies object is getting set to false before the headers are all available. Here's why: I put a breakpoint in my servlet filter just before I get the session. I ask for the cookies and I break if cookies returns null. Then I go into the data structure and look at the CoyoteRequest object. The Cookies object has unprocessed=false and no cookies, but the headers include a cookie header. I reset unprocessed to true, then I reaccess Cookies and the JSESSIONID cookie appears. More data: I put a breakpoint in the cookie parser and it never failed to find the header. So what I'm wondering is if there is a case where parsing might be bypassed? For example, it looks like the cookies are normally processed on object creation and then if recycle is called. Could the headers sometimes be getting set without calling recycle? The other bug I'm seeing is that sometimes the scheme isn't set on the request. request.getScheme returns null (which breaks redirect). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34669] - Cookies are not always parsed on simultaneous request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34669. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34669 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-04-28 20:13 --- This does not make any sense at all, especially: (In reply to comment #3) unprocessed flag in the cookies object is getting set to false before the headers are all available The first thing which occurs is parsing the headers. If cookie parsing is done before, then you are looking at improper access to the container objects. Try to enable the security manager to get some NPEs to reveal them. I don't know where your problem is, but all I know is that it is not in Tomcat. Please do not reopen the report. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34413] New: - Cookies disappear when displaying error-page
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34413. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34413 Summary: Cookies disappear when displaying error-page Product: Tomcat 4 Version: 4.1.31 Platform: HP OS/Version: Windows 2000 Status: NEW Severity: minor Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I have an error-page configured to display exceptions. My servlet creates a cookie using Response.addCookie(...). If the exception is thrown after the cookie is added, the cookie does not appear in the response headers when the error page is displayed. I would like this cookie to be set irrespective of whether the request succeeded or not. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34413] - Cookies disappear when displaying error-page
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34413. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34413 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-04-12 21:22 --- Bugzilla is NOT a support forum. Please ask questions like this on the tomcta-user mailing list. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34349] - cookies=false with request mit session cookie
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34349. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34349 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2005-04-08 08:12 --- Sorry Remy for the reopen, but I think this is not well defined! What happend, when the cookie contain an old or an invalid sessionid? When I send a request with a cookie like: Set-Cookie: JSESSIONID=1234567890 then urlRewrite don't rewrite, because we work with cookies. An other valid session cookie can't set because in context cookies = false ??? regards Dietmar -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34349] New: - cookies=false with request mit session cookie
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34349. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34349 Summary: cookies=false with request mit session cookie Product: Tomcat 5 Version: 5.5.7 Platform: All OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I set in my context.xml cookies=false and send a request with a cookie jsessionid and urlEncode don't encode my links! the testcode looks like URL url = new URL (http://myServer/foo/foo;); HttpURLConnection conn = (HttpURLConnection)url.openConnection(); conn.setUseCaches(false); conn.setRequestProperty(Cookie,JSESSIONID=foo); regards Dietmar -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34349] - cookies=false with request mit session cookie
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34349. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34349 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-04-07 17:08 --- If a cookie is submitted, Tomcat will use it. Please don't reopen the report. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33961] - session cookies for context containing '~' do not work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33961. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33961 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-03-24 18:20 --- Fixed. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33961] New: - session cookies for context containing '~' do not work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33961. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33961 Summary: session cookies for context containing '~' do not work Product: Tomcat 5 Version: 5.5.7 Platform: All URL: http://www.hostingjava.it OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] I you create an application containing '~' character cookies do non work properly, because the url set in the cookie encodes the ~ character in urlencoded format. For example if your context name is /~luigi The cookies send back to the client are with a path: /%74luigi This makes the server unable to recognize the sessionid, like cookies were disabled. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15555] - Setting cookie=false appears to still use cookies.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=1. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=1 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2005-03-07 23:05 --- (In reply to comment #5) IMHO each single context should be able to have its own cookies-setting, independent from DefaultContext - so I consider this being a bug. This is by design and as per the documentation. You need to look at the override parameter of the context element. Closing this (again) as works for me as my previous testing showed no difference between documented and actual behaviour. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17178] - if user-agent sends cookies that add up more than 4K SocketInputStream throws an exception
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=17178. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=17178 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-03-01 21:56 --- The HTTP connector has been deprecated. Use the Coyote connector instead. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31232] - response.encodeURL() not encoding URL when mix of cookies and URL rewriting
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31232. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31232 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-02-16 10:09 --- I do not agree with this patch in the general case. If a cookie is submitted, we'll use it. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31232] - response.encodeURL() not encoding URL when mix of cookies and URL rewriting
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31232. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31232 --- Additional Comments From [EMAIL PROTECTED] 2005-02-16 19:01 --- (In reply to comment #10) I do not agree with this patch in the general case. If a cookie is submitted, we'll use it. I agree with that with one exception. This is not a general case, it's a use case where the (sub) context disables cookies and is expecting to use URL rewriting. The presence of the (ROOT) cookie forces a new session on each request since the URL rewriting is always overriden by the cookie, thus making the (sub) context unusable. Mixing cookies and URL rewriting is okay when the ROOT context doesn't use cookies (ie: /subA uses cookies, and /subB uses URL rewrite). Thought it would be easier to make the patch since this use case seems like a bug. See my comment #3 for additional reference. More workarounds that I thought of are: * create a host listening on a separate port. However this port may get blocked by firewalls since it's not port 80. * setting up a separate domain and use URL rewriting just in that domain. * don't use cookies at all. Not my favorite. I just don't want other people to experience the trouble that I had. If the decision is still a WONTFIX, then please add a note in the docs for the cookies attribute for Context that URL rewriting won't work for sub contexts if the ROOT context uses cookies. thanks. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31232] - response.encodeURL() not encoding URL when mix of cookies and URL rewriting
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31232. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31232 --- Additional Comments From [EMAIL PROTECTED] 2005-02-16 02:24 --- Created an attachment (id=14294) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14294action=view) Patch for issue Hey Yoav, I've got a patch for this. Finally got some time to track it down. Currently the cookie session ID always overrides the URL session ID, regardless if the context enables cookies or not. This patch will check to see if the context enables cookies first. If it does then the cookie session ID overrides the session ID from the URL. If it does not then the parseSessionCookieId is skipped completely. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31232] - response.encodeURL() not encoding URL when mix of cookies and URL rewriting
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31232. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31232 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31232] - response.encodeURL() not encoding URL when mix of cookies and URL rewriting
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31232. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31232 --- Additional Comments From [EMAIL PROTECTED] 2005-01-20 14:54 --- (In reply to comment #6) If you want this fixed, submit a patch for it. I'll be glad to evaluate and commit it as needed. As evidenced by the length of time (nearly 2 months) since you submitted this issue, no committers care about it enough to spend time investigating/resolving it. I don't see how commiters are the one that decide in which direction the code evolves, where it is being fixed or not It should be driven by someone, or a group of people, acting as 'drivers', based on how critical are bugs and users requests This is the only way for the apache group to keep users confidence ! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29745] - cookies overwrite url session encoding
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29745. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29745 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-01-07 19:58 --- Bugzilla is NOT a support forum. This is a question for the tomcat-user mailing list. Had you asked this question on the mailing list, someone would have pointed you in the direction of the context override parameter and probably would have replied faster too. I have just run a quick test with a two very basic web apps and the cookies parameter behaves as expected once the override=true is added to the context. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31232] - response.encodeURL() not encoding URL when mix of cookies and URL rewriting
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31232. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31232 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-11-17 18:21 --- Hmm, two weeks since patch request, two months since initial issue. Please reopen this if/when you have a patch ready. I'll be glad to evaluate and commit it then. Thanks. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15555] - Setting cookie=false appears to still use cookies.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=1. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=1 Setting cookie=false appears to still use cookies. [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | --- Additional Comments From [EMAIL PROTECTED] 2004-11-10 14:51 --- We're running tomcat 4.1.30/sun jdk1.4.2/SuSE Linux and having the same problem with disabling cookies and problems reproducing this behaviour too. I noticed the following: Having a DefaultContext defining cookies=true was overwriting the coookies-setting (cookies=false) of any other context in the same host. Using the admin-application I found out that this obviously happens at tomcat runtime - the setting shown in tomcat-admin and in server.xml were differing. IMHO each single context should be able to have its own cookies-setting, independent from DefaultContext - so I consider this being a bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15555] - Setting cookie=false appears to still use cookies.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=1. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=1 Setting cookie=false appears to still use cookies. --- Additional Comments From [EMAIL PROTECTED] 2004-11-10 14:53 --- FYI, you're wasting your time. Tomcat 4.x is not being actively maintained and this is not likely to be addressed as it's not a significant issue. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31232] - response.encodeURL() not encoding URL when mix of cookies and URL rewriting
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31232. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31232 response.encodeURL() not encoding URL when mix of cookies and URL rewriting --- Additional Comments From [EMAIL PROTECTED] 2004-11-03 17:16 --- If you want this fixed, submit a patch for it. I'll be glad to evaluate and commit it as needed. As evidenced by the length of time (nearly 2 months) since you submitted this issue, no committers care about it enough to spend time investigating/resolving it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31232] - response.encodeURL() not encoding URL when mix of cookies and URL rewriting
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31232. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31232 response.encodeURL() not encoding URL when mix of cookies and URL rewriting --- Additional Comments From [EMAIL PROTECTED] 2004-09-21 19:18 --- I knew we never should have added the option to disable cookies ;) The Servlet Spec doesn't require containers to provide this option, and it seems to be it just leads to bad stuff ;) But now that we provide it, we have to maintain it I suppose. sigh / - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31232] - response.encodeURL() not encoding URL when mix of cookies and URL rewriting
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31232. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31232 response.encodeURL() not encoding URL when mix of cookies and URL rewriting --- Additional Comments From [EMAIL PROTECTED] 2004-09-20 18:11 --- This seems contrived... What's the use-case for it? I'm just curious, not closing this issue at this point. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31232] - response.encodeURL() not encoding URL when mix of cookies and URL rewriting
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31232. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31232 response.encodeURL() not encoding URL when mix of cookies and URL rewriting --- Additional Comments From [EMAIL PROTECTED] 2004-09-20 21:02 --- Our use case is that our system is half web-based and half applet based. The applets communicate with our servlets, setup sessions, redirect users to various web pages. All this has to be done through URL rewriting because the cookie caches aren't shared between broswer and the applet. This is in the /sub context. Now we have a members section that is cookie based on the root context. We tried linking some features of the members section into the applet so it's accessible in the applet. But whenever the user goes to the member section all access to the /sub is screwed up like how I mentioned before: the URL rewriting in the sub context doesn't take because of the cookie at the root context. Lets see workaround for us... 1) rewrite our site to use URL rewriting instead of cookies. 2) move members ares to a separate /sub2 context. Can't do that because they still access pages from / But use case aside, it just seems like a bug: I specify that the /sub context is not to use cookies (force URL rewriting) and it's not using the session ID given on the URL because the root context uses cookies. I would it expect it use URL rewriting instead of not being able to use anything. I don't know if there is a spec covering URL-rewriting so I can't refer to anything other than it being vendor specific. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31232] - response.encodeURL() not encoding URL when mix of cookies and URL rewriting
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31232. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31232 response.encodeURL() not encoding URL when mix of cookies and URL rewriting --- Additional Comments From [EMAIL PROTECTED] 2004-09-20 21:26 --- forgot to mention that for the workaround of forcing users to use URL rewriting for the members section that this goes back to the usual debate of URL rewriting vs. cookies where if the user navigates away from the site and comes back then the URL rewritten session is gone. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31232] New: - response.encodeURL() not encoding URL when mix of cookies and URL rewriting
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31232. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31232 response.encodeURL() not encoding URL when mix of cookies and URL rewriting Summary: response.encodeURL() not encoding URL when mix of cookies and URL rewriting Product: Tomcat 5 Version: 5.0.28 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Setup: ~~ I have two contexts. The root context allows cookies and the sub context does URL rewriting. ie: Context path= docBase=sub reloadable=true privileged=false/ Context path=/sub docBase=sub cookies=false reloadable=true privileged=false/ In the docBase is only an index.jsp which justs print out the session and cookie info and does encodeURL() for the link to the sub context. If I do: 1) goto http://localhost:8080/index.jsp (uses cookies) 2) goto http://localhost:8080/sub/index.jsp (uses URL rewrite) 3) click on the link which is response.encodeURL(/sub/index.jsp) Issue: ~~ I find that the root context's cookie is passed onto the sub context. Because of this the encodeURL() doesn't encode the URL for rewriting in the sub context. Each time I click on the response.encodeURL(/sub/index.jsp) link a new session id is generated each time. Example: Request URI = /sub/index.jsp Session ID = 80A6E1BEC167333A8E05E3588EA0C3A8 Is New = true Is Valid = false From Cookie = true From URL = false Cookie[0] (from /index.jsp) getComment() = null getDomain() = null getMaxAge() = -1 getName() = JSESSIONID getPath() = null getSecure() = false getValue() = F436A1045778EC9E794449A0192BD406 getVersion() = 0 - Because request.isRequestedSessionIdFromCookie() returns true (since the root's cookie is passed to the sub context) the URL is not encoded with the sub context's session id. I've tried this on Windows Linux, and with IE Firefox...all produced the same results. I've attached example of this issue. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31232] - response.encodeURL() not encoding URL when mix of cookies and URL rewriting
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31232. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31232 response.encodeURL() not encoding URL when mix of cookies and URL rewriting --- Additional Comments From [EMAIL PROTECTED] 2004-09-15 01:17 --- Created an attachment (id=12736) example tomcat instance of this issue. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30748] - Apache2/Tomcat + IE - cookies problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30748. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30748 Apache2/Tomcat + IE - cookies problem [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2004-08-29 00:39 --- If it works for Moz and Opera - it probably means that IE is rejecting the cookie or its not sending the cookies correctly. (There are other reports about IE being broken) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 30748] New: - Apache2/Tomcat + IE - cookies problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=30748. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=30748 Apache2/Tomcat + IE - cookies problem Summary: Apache2/Tomcat + IE - cookies problem Product: Tomcat 5 Version: 5.0.19 Platform: Other OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I am using Apache 2.0.20 and Apache Tomcat 5.0.19. I got the following problem : IE6 (I don't know if the problem exists in previous versions) doesn't see the cookies which were sent by servlet's. This problem doesn't exists for Opera and Netscape. Here is my configuration : httpd.conf : LoadModule jk2_module modules/mod_jk2.so JkSet config.file /usr/local/apache2/conf/workers2.properties workers2.properties : # Example socket channel, override port and host. [channel.socket:localhost:8009] port=8009 host=localhost # define the worker [ajp13:localhost:8009] channel=channel.socket:localhost:8009 [uri:/ecr/] info=ECR index servlet worker=ajp13:localhost:8009 server.xml : Host name=localhost Connector port=8080 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false redirectPort=8443 acceptCount=100 debug=0 connectionTimeout=2 disableUploadTimeout=true/ /Host Connector className=org.apache.coyote.tomcat5.CoyoteConnector port=8009 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 acceptCount=10 debug=0 connectionTimeout=20 useURIValidationHack=false protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler/ Engine name=Catalina defaultHost=localhost debug=0 Logger className=org.apache.catalina.logger.FileLogger prefix=catalina_log. suffix=.txt timestamp=true/ Realm className=org.apache.catalina.realm.UserDatabaseRealm debug=0 resourceName=UserDatabase/ Host name=localhost debug=0 appBase=webapps unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false Context path=/ecr docBase=ecr debug=0 reloadable=true Logger className=org.apache.catalina.logger.FileLogger directory=logs prefix=localhost_ecr_log. suffix=.txt timestamp=true/ /Context /Host /Engine web.xml : web-app servlet servlet-nameindex/servlet-name servlet-classecr.index/servlet-class /servlet servlet-mapping servlet-nameindex/servlet-name url-pattern//url-pattern /servlet-mapping /web-app - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29745] New: - cookies overwrite url session encoding
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29745. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29745 cookies overwrite url session encoding Summary: cookies overwrite url session encoding Product: Tomcat 4 Version: 4.1.24 Platform: PC OS/Version: Windows XP Status: NEW Severity: Normal Priority: Other Component: Webapps:Manager AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi, I have two application: XXX and Axis on Tomcat 4.1.24. XXX has context tag setting cookies=false, while Axis runs with default. Once both applications are running, if I make some changes in Axis and restart Tomcat, cookies become default even for XXX. Then I make some changes in XXX and restart Tomcat, everything works as intended. Is it a Tomcat problem? Any feedback? Thanks Dev Goyal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28971] New: - problems if root-context and application-context sets cookies
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28971. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28971 problems if root-context and application-context sets cookies Summary: problems if root-context and application-context sets cookies Product: Tomcat 5 Version: 5.0.24 Platform: Other OS/Version: Other Status: NEW Severity: Critical Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I am not sure if this is a new bug (i have used tomcat4 for now and the .24 release is my first try to move to tomcat5). Tomcat (now) sets two cookies - one for the root-context and one for the application context - say (/opsjs). Now on every request two cookies are sent to tomcat - one session-id for the root context and one for the application-context. But it looks like tomcat cant handle this case - maybe only the first cookie is processed and this do not match to the cookie-list for the application-context (just an idea) - so a new session is started and a new cookie sent to the browser. I have had to disable the cookies on the root context. Context path= docBase=ROOT debug=0 cookies=false/ Then the application works like expected - only one cookie is sent. The definition of the application context is: Context path=/opsjs docBase=/u/opsj crossContext=false debug=0 reloadable=false trusted=false ... Since another user experienced the same problem i decided to enter this (new) behaviour as critical. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28971] - problems if root-context and application-context sets cookies
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28971. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28971 problems if root-context and application-context sets cookies [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-05-14 11:20 --- This is now fixed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28971] - problems if root-context and application-context sets cookies
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=28971.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=28971
problems if root-context and application-context sets cookies
--- Additional Comments From [EMAIL PROTECTED] 2004-05-14 11:22 ---
Index: CoyoteAdapter.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteAdapter.java,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- CoyoteAdapter.java28 Apr 2004 22:05:10 - 1.25
+++ CoyoteAdapter.java14 May 2004 11:00:25 - 1.26
@@ -295,6 +295,9 @@
return false;
}
+// Parse session Id
+parseSessionCookiesId(req, request);
+
return true;
}
@@ -352,6 +355,14 @@
request.setRequestedSessionId(null);
request.setRequestedSessionURL(false);
}
+
+}
+
+
+/**
+ * Parse session id in URL.
+ */
+protected void parseSessionCookiesId(Request req, CoyoteRequest request) {
// Parse session id from cookies
Cookies serverCookies = req.getCookies();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28971] - problems if root-context and application-context sets cookies
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28971. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28971 problems if root-context and application-context sets cookies --- Additional Comments From [EMAIL PROTECTED] 2004-05-14 14:43 --- Created an attachment (id=11548) Extract the package in the Tomcat installation folder - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28971] - problems if root-context and application-context sets cookies
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28971. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28971 problems if root-context and application-context sets cookies --- Additional Comments From [EMAIL PROTECTED] 2004-05-14 14:44 --- Created an attachment (id=11549) Extract the package in the Tomcat installation folder (zip format) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 28780] New: - Need non-secure JSESSIONID cookies
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=28780. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=28780 Need non-secure JSESSIONID cookies Summary: Need non-secure JSESSIONID cookies Product: Tomcat 4 Version: Unknown Platform: All OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When the first request to a webapp is to a secure (HTTPS) page, the JSESSIONID cookie that gets sent is marked as Secure. If a following request is to a non- secure page then the client will not send the session cookie back, effectively causing the session to be lost. I understand that in many cases this is sensible behaviour, however it is causing us (and I believe others) problems. Could we please make this behaviour configurable, preferably on a per- application basis? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25092] - Bug with cookies=false
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=25092. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=25092 Bug with cookies=false --- Additional Comments From [EMAIL PROTECTED] 2004-04-20 11:14 --- I have a problem much like this with my webapplication as well. This only appears on Tomcat 5.0.19. My webapplication is a servlet 2.3/jsp 1.2 application, which I would like to move to Tomcat 5.0.19, but I am unable to because of this problem. What happens is that if the session cookie is blocked by browser security settings as with P3P on IE6 then a new session is created instead of the old one being reused and this even happens with JSESSIONID written into the URL. I've tracked this using a HttpSessionListener. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25092] - Bug with cookies=false
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=25092. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=25092 Bug with cookies=false [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-04-20 13:29 --- I really doubt there's a bug with that. Please don't reopen the report. As for the admin, I think it's fair enough to require cookies, so I'll resolve this bug (since apparently it won't be addressed). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10419] - Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419 Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-02-08 10:43 --- Cookies will override URL session Ids. This is done on purpose and will ot be fixed. Now, there was an issue where Tomcat would only consider the first session id cookie. Now, if there are multiple ones, Tomcat will look until one of them is valid (the first one should be, as per Craig comments, but I've added more lenient code in the TC 5 CVS, since it doesn't hurt much). Please do not reopen this report, it will not be fixed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10419] - Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419 Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions --- Additional Comments From [EMAIL PROTECTED] 2004-02-08 14:15 --- Quote: Now, if there are multiple ones, Tomcat will look until one of them is valid Cool, thats all I suggested. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10419] - Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419 Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions --- Additional Comments From [EMAIL PROTECTED] 2004-02-08 14:35 --- Actually, no. If there's a cookie and the URL is encoded, whatever is read from the URL will be overridden (having multiple cookies was another possibility). But this is a case which shouldn't happen (as long as 10418 is also a won't fix, there is a consistent effort to favor cookies, which is better for end users anyway). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10419] - Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419 Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions --- Additional Comments From [EMAIL PROTECTED] 2004-02-08 15:38 --- I agree, that when we can use cookies, session IDs from cookies should be preferred. Preferring URL rewritten session IDs over cookies has only be a potential point of discussion (see first comment). But IMHO if all session IDs read from cookies are bogus and the session ID from the URL is a valid one, then tomcat should go for the valid one. So its not a matter of 'use cookies' or 'use URL-rewriting' but 'use a valid session id gotten from the client while valid session cookies override session IDs from the URL'. If you do the check as pointed out in your message from 2004-02-08 10:43, this is almost it as I understand it.. ..If you do not override a valid session ID with an invalid one from a cookie. Be lenient with what you consume, be pedantic and accurate with what you create. -- Jon Postel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 7588] - Session cannot be established if there are multiple session cookies
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7588. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7588 Session cannot be established if there are multiple session cookies [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2004-02-07 14:43 --- *** This bug has been marked as a duplicate of 10419 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10419] - Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419 Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2004-02-07 14:43 --- *** Bug 7588 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10419] - Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419 Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions [EMAIL PROTECTED] changed: What|Removed |Added URL|http://www.freiheit.com/user|http://vicdor.org/~hzeller/S |s/hzeller/SessionBugDemonstr|essionBugDemonstration.java |ation.java | --- Additional Comments From [EMAIL PROTECTED] 2004-02-07 20:16 --- Since the URL to the original demonstration servlet of this issue wasn't reachable anymore (this bug is now open for 1.5 years..), I've moved it to a new location. You can find it at http://vicdor.org/~hzeller/SessionBugDemonstration.java now. While re-reading the comments after a while I noticed that referencing the bugs 1 and 2 in my first comment is a bit misleading since bugzilla tries to link to the literal number. They actually stand for the two bugs I've committed regarding two related aspects of faulty session handling in tomcat, namely Bug #10418 and this Bug #10419. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25092] - Bug with cookies=false
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25092. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25092 Bug with cookies=false [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2004-01-29 13:15 --- *** Bug 26516 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cookies attribute on context element
All, Help. I am somewhat confused. All the docs and the comments in the code, AFAICT, indicate that the cookies attribute is for enabling/disabling session tracking via cookies. However, Remy's comments on http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1 would appear to contradict this. Before I start to tackle the handful of open bugs on this issue I would be grateful for a definitive explanation. Thanks in advance for any help. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cookies attribute on context element
Mark Thomas wrote: All, Help. I am somewhat confused. All the docs and the comments in the code, AFAICT, indicate that the cookies attribute is for enabling/disabling session tracking via cookies. However, Remy's comments on http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1 would appear to contradict this. Before I start to tackle the handful of open bugs on this issue I would be grateful for a definitive explanation. Tomcat will not set the session cookie if the flag is set to false. If the client somehow sends back a cookie, then Tomcat isn't completely stupid and will read it. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cookies attribute on context element
Remy, Forgive me if I am being really stupid but does this mean that your comment on bug 1 ...the setting is for disabling persistent cookies. Session cookies are not persistent, and Tomcat will switch between URL encoding and session cookies according to what the client does. is not correct? Mark -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Monday, January 19, 2004 10:18 PM To: Tomcat Developers List Subject: Re: cookies attribute on context element Mark Thomas wrote: All, Help. I am somewhat confused. All the docs and the comments in the code, AFAICT, indicate that the cookies attribute is for enabling/disabling session tracking via cookies. However, Remy's comments on http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1 would appear to contradict this. Before I start to tackle the handful of open bugs on this issue I would be grateful for a definitive explanation. Tomcat will not set the session cookie if the flag is set to false. If the client somehow sends back a cookie, then Tomcat isn't completely stupid and will read it. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cookies attribute on context element
cookies are on the client side, not on the server side :) I think this was to disable session persistance Filip -Original Message- From: Mark Thomas [mailto:[EMAIL PROTECTED] Sent: Monday, January 19, 2004 2:45 PM To: 'Tomcat Developers List' Subject: RE: cookies attribute on context element Remy, Forgive me if I am being really stupid but does this mean that your comment on bug 1 ...the setting is for disabling persistent cookies. Session cookies are not persistent, and Tomcat will switch between URL encoding and session cookies according to what the client does. is not correct? Mark -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: Monday, January 19, 2004 10:18 PM To: Tomcat Developers List Subject: Re: cookies attribute on context element Mark Thomas wrote: All, Help. I am somewhat confused. All the docs and the comments in the code, AFAICT, indicate that the cookies attribute is for enabling/disabling session tracking via cookies. However, Remy's comments on http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1 would appear to contradict this. Before I start to tackle the handful of open bugs on this issue I would be grateful for a definitive explanation. Tomcat will not set the session cookie if the flag is set to false. If the client somehow sends back a cookie, then Tomcat isn't completely stupid and will read it. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15555] - Setting cookie=false appears to still use cookies.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1 Setting cookie=false appears to still use cookies. [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2004-01-19 23:54 --- I have just tested this with a simple test web app with the latest tomact source from cvs and it is working as per the documentation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15555] - Setting cookie=false appears to still use cookies.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1 Setting cookie=false appears to still use cookies. [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2003-12-20 22:19 --- Yes, I read your request to not reopen the bug. But please take a look at the current documentation of attribute cookies: This is from Tomcat4/Tomcat 5 documentation: 'Set to true if you want cookies to be used for session identifier communication if supported by the client (this is the default). Set to false if you want to disable the use of cookies for session identifier communication, and rely only on URL rewriting by the application.' IMO the documentation doesn't let any room for interpretation. Either it is a bug in tomcat or the documentation is completely misleading. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25092] New: - Bug with cookies=false
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25092. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25092 Bug with cookies=false Summary: Bug with cookies=false Product: Tomcat 5 Version: 5.0.15 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Webapps:Administration AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If the cookies attribute of an admin context is set as false, when the Commit Changes button is pushed, it will be returned to a login screen. Settings are not saved at this time. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24739] - Control of secure flag when establishing sessions through https using cookies
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24739. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24739 Control of secure flag when establishing sessions through https using cookies [EMAIL PROTECTED] changed: What|Removed |Added Severity|Minor |Enhancement --- Additional Comments From [EMAIL PROTECTED] 2003-11-25 00:41 --- Tomcat 4 (and 5) work this way to protect sessions created in SSL from being at risk of session hijacking if transferred back to http. That being said, there have been a number of requests for this type of functionality on tomcat- user. As this is not strictly a bug, I am setting it to an enhancement request. Until such time as a patch is written, using something similar to the following in your jsp will provide a work-around. A HREF=http://localhost:8080/bug24739/display.jsp;jsessionid=%=session.getId ()%display session cookie(http)/A Obviously, you will need to replace http://localhost:8080/bug24739/display.jsp; with something appropriate to your environment. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24739] New: - Control of secure flag when establishing sessions through https using cookies
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24739. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24739 Control of secure flag when establishing sessions through https using cookies Summary: Control of secure flag when establishing sessions through https using cookies Product: Tomcat 4 Version: 4.1.29 Platform: Macintosh OS/Version: MacOS X Status: NEW Severity: Minor Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Because the secure flag is always set to yes when a session is created through an https connection, these session are lost when a user visits a non-secured page. The reverse is NOT true -- if the first page is a non-secure page, the cookie will work on both secured and un-secured connections. Developers should have explicit control over whether the secure flag is set to yes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24455] - allow to override 'cookies=false' on a per user/session basis.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24455. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24455 allow to override 'cookies=false' on a per user/session basis. [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|struts- |tomcat- |[EMAIL PROTECTED] |[EMAIL PROTECTED] Status|REOPENED|NEW Summary|allow to override |allow to override |'cookies=false' on a per |'cookies=false' on a per |session basis. |user/session basis. --- Additional Comments From [EMAIL PROTECTED] 2003-11-06 15:50 --- As per http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1, cookies=false appears to apply only to persistent cookies. Thus the use-case would be slightly different from my initial description, but still a valid one, I hope ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24140] New: - Cookies not added to response during jsp include
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24140. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24140 Cookies not added to response during jsp include Summary: Cookies not added to response during jsp include Product: Tomcat 5 Version: 5.0.12 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If I have my browser visit index.jsp and index.jsp has code to add a test cookie to the response, I get the cookie as expected. If I move that same code to an included JSP, the cookie is not added to the response. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24140] - Cookies not added to response during jsp include
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24140. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24140 Cookies not added to response during jsp include [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-10-27 03:06 --- The JSP spec is very clear that included pages are not allowed to modify or add Response headers. This includes adding Cookies. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 6630] - Cookies in the HttpServletRequest are not URL decoded when using the JK/AJP Connector
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6630. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6630 Cookies in the HttpServletRequest are not URL decoded when using the JK/AJP Connector [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|tomcat- |[EMAIL PROTECTED] |[EMAIL PROTECTED] | Status|RESOLVED|NEW - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 234] - Can't set multiple cookies in servlet response headers through Ajp13 BugRat Report#371
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=234. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=234 Can't set multiple cookies in servlet response headers through Ajp13 BugRat Report#371 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-08-28 21:49 --- Closing bug as FIXED on the basis of Michael van Rooyen's previous post. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15555] - Setting cookie=false appears to still use cookies.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1 Setting cookie=false appears to still use cookies. --- Additional Comments From [EMAIL PROTECTED] 2003-07-28 11:13 --- I can confirm this with Tomcat 4.1.24. Even if I disable cookies in the context, they are processed if sent by the browser. IMO this is a bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10419] - Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419 Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions --- Additional Comments From [EMAIL PROTECTED] 2003-07-28 11:26 --- Bug #1 is related to this. I actually have a use case: - Admin installs $WEBAPPLICATION - forgets to disable cookies in Context; $WEBAPPLICATION always encodes sessions in URL - users start using $WEBAPPLICATION - Admin remembers after a week - lots of users have cookies hanging around in their browsers and cannot log in any more because there is always a stale JSESSIONID cookie being sent by the browser and examined by Tomcat We have been bitten by this bug several times. Bye, Tino. PS: Tested with Tomcat 4.1.24 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15555] - Setting cookie=false appears to still use cookies.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1 Setting cookie=false appears to still use cookies. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-07-28 11:31 --- This is wrong: the setting is for disabling persistent cookies. Session cookies are not persistent, and Tomcat will switch between URL encoding and session cookies according to what the client does. This bug will not be addressed, please do not reopen it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21172] - Problem setting cookies on coyote connector
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21172. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21172 Problem setting cookies on coyote connector [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-07-19 08:50 --- I haven't re-checked, but this may have been due to my using an older version of mod_jk2.so that I was using on the apache side. See my comments on bug 234. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 234] - Can't set multiple cookies in servlet response headers through Ajp13 BugRat Report#371
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=234. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=234 Can't set multiple cookies in servlet response headers through Ajp13 BugRat Report#371 --- Additional Comments From [EMAIL PROTECTED] 2003-07-13 19:10 --- I was using mod_jk2-2.0.43.so (jk2 v2.0.1) downloaded from the jakarta site, and it appears that the problem is related to this library. I downloaded jakarta-tomcat-connectors-4.1.24-src (jk2 v2.0.2), rebuilt the library, and the cookies now get through. Unfortunately for some reason, only solaris and win32 binaries are available from the jakarta site for v2.0.2, so linux users will have to build their own... This bug should probably be closed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21172] New: - Problem setting cookies on coyote connector
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21172.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21172
Problem setting cookies on coyote connector
Summary: Problem setting cookies on coyote connector
Product: Tomcat 4
Version: 4.1.24
Platform: Other
OS/Version: Linux
Status: NEW
Severity: Major
Priority: Other
Component: Connector:Coyote JK 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I am using tomcat 4.1.24 and apache 2.0.43 with mod_jk2. I have been using
ajp13 as a connector because initially there were problems with isSecure() on
the coyote connector that have now been fixed. I tried the coyote connector
again recently, and there seems to be a problem where addCookie blasts any
cookie that has previously been set. In my case, my code looked something
like:
doGet(...)
{
...
if (session.isNew())
response.addCookie(myCookie);
...
}
This caused the session tracking to go astray, and the JSESSIONID cookie not to
be sent to the client. Without the addCookie(), session tracking worked
again.
This bug is similar to http://nagoya.apache.org/bugzilla/show_bug.cgi?id=234,
except it's worse (ajp13 seems to allow 2 cookies per response, while coyote
allows only 1). Using the ajp13 connector, the above code does not break the
session tracking.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 234] - Can't set multiple cookies in servlet response headers through Ajp13 BugRat Report#371
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=234. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=234 Can't set multiple cookies in servlet response headers through Ajp13 BugRat Report#371 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |NEW everconfirmed|0 |1 --- Additional Comments From [EMAIL PROTECTED] 2003-06-26 09:56 --- I am using tomcat 4.1.24, jk2 and apache 2.0.43, and I have the same problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 234] - Can't set multiple cookies in servlet response headers through Ajp13 BugRat Report#371
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=234. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=234 Can't set multiple cookies in servlet response headers through Ajp13 BugRat Report#371 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2003-06-16 16:14 --- I am currently testing tomcat 4.1.24 (apache 2.0.40 JK2 2.0.1) and have found this bug re-appear. The last cookie set is the only one that successfully sets. The same code on our live web server works which is tomcat 3.2.2 (apache 1.3.19 jk) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 9590] - cookies stop sending to browser after nested loop
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9590. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9590 cookies stop sending to browser after nested loop [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-06-03 01:24 --- Closing based on last comment. reopen if a test case can be made (and attached to this report) against 4.1.24 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: domain-wide session cookies?
On Thu, 20 Mar 2003, Aditya wrote: Date: Thu, 20 Mar 2003 21:40:20 -0800 From: Aditya [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: domain-wide session cookies? Under Tomcat-4 it looks like the session cookie is set in: org/apache/catalina/connector/HttpResponseBase.java and the code that sets it uses the default domain (which is equal to the request hostname.domain.tld) when it sets the session cookie. I need to set the cookie to be domain-wide, ie. .domain.tld however it seems silly to hardcode it in the above class. Before I tackle this: 0) is there a better way to do it? 1) if not, is this the right place to do it? 2) what is the best place (ie. where in server.xml) to put an option to enable this? I personally prefer option 3 -- don't change anything. Exposing session id cookies to a broader audience than just the webapp that created them is a security vulnerability. If you need to share stuff across webapps, use some other cookie, not the container-managed one. Thanks, Adi Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: domain-wide session cookies?
On Mon, 24 Mar 2003 11:44:04 -0800 (PST), Craig R. McClanahan [EMAIL PROTECTED] said: Under Tomcat-4 it looks like the session cookie is set in: org/apache/catalina/connector/HttpResponseBase.java and the code that sets it uses the default domain (which is equal to the request hostname.domain.tld) when it sets the session cookie. I need to set the cookie to be domain-wide, ie. .domain.tld however it seems silly to hardcode it in the above class. Before I tackle this: 0) is there a better way to do it? 1) if not, is this the right place to do it? 2) what is the best place (ie. where in server.xml) to put an option to enable this? I personally prefer option 3 -- don't change anything. Exposing session id cookies to a broader audience than just the webapp that created them is a security vulnerability. If you need to share stuff across webapps, use some other cookie, not the container-managed one. It's a little more wierd and esoteric than that -- we have multiple virtual hosts (all in the same second-level domain) pointing at a single webapp/context (with Apache/mod_jk) and we need to have sessions shared across the virtual hosts. I started by reimplementing a parallel session manager that wrote a domain cookie, but that seemed silly, so I've written a filter that writes a copy of the session cookie valid for the entire domain when the session.isNew(). Of course, this isn't perfect since Tomcat insists on writing the default host session cookie *after* all filters are evaluated...which might be construed as a bug/feature. After all, shouldn't filters have the ability to manipulate the entire HTTP response? If anyone has a suggestion on how to deal with that, I would welcome any hints. Thanks, Adi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: domain-wide session cookies?
On Mon, 24 Mar 2003, Aditya wrote: Date: Mon, 24 Mar 2003 13:34:57 -0800 From: Aditya [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: domain-wide session cookies? On Mon, 24 Mar 2003 11:44:04 -0800 (PST), Craig R. McClanahan [EMAIL PROTECTED] said: Under Tomcat-4 it looks like the session cookie is set in: org/apache/catalina/connector/HttpResponseBase.java and the code that sets it uses the default domain (which is equal to the request hostname.domain.tld) when it sets the session cookie. I need to set the cookie to be domain-wide, ie. .domain.tld however it seems silly to hardcode it in the above class. Before I tackle this: 0) is there a better way to do it? 1) if not, is this the right place to do it? 2) what is the best place (ie. where in server.xml) to put an option to enable this? I personally prefer option 3 -- don't change anything. Exposing session id cookies to a broader audience than just the webapp that created them is a security vulnerability. If you need to share stuff across webapps, use some other cookie, not the container-managed one. It's a little more wierd and esoteric than that -- we have multiple virtual hosts (all in the same second-level domain) pointing at a single webapp/context (with Apache/mod_jk) and we need to have sessions shared across the virtual hosts. I started by reimplementing a parallel session manager that wrote a domain cookie, but that seemed silly, so I've written a filter that writes a copy of the session cookie valid for the entire domain when the session.isNew(). Of course, this isn't perfect since Tomcat insists on writing the default host session cookie *after* all filters are evaluated...which might be construed as a bug/feature. After all, shouldn't filters have the ability to manipulate the entire HTTP response? If anyone has a suggestion on how to deal with that, I would welcome any hints. Consider that the initial access to your shared app was on virtual host A. If all of the other accesses to that app, for a particular session, also used virtual host A in their URLs, you wouldn't have a problem, right? The session cookie would include virtual host A as the domain, so the cookie would always be returned on those subsequent requests. (The simplest way to accomplish this would be to always use relative URLs for intra-application hyperlinks). Sharing a session across virtual hosts violates the Servlet spec (Section 7.3 - HttpSession objects must be scoped at the application (or servlet context) level and Section 3.6 - Servlet contexts can not be shared across virtual hosts), so you should not really be surprised to find the logic for setting up a session cookie be hard coded in the manner you describe. Thanks, Adi Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 7588] - Session cannot be established if there are multiple session cookies
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7588. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7588 Session cannot be established if there are multiple session cookies --- Additional Comments From [EMAIL PROTECTED] 2003-03-21 20:14 --- Yes, this is a BUG, and it seems that it is a serious bug, because probably at 1% of sessions are lost with IE, when the session for some circumstances is invalidated but cookie is left non-expired, and after that the new session is generated and IE(6 and 5 for me) _ALWAYS_ sends two cookies JSESSIONID; but the first cookie is for invalid session, so tomcat treats that the session is new, although the second cookie contains the actual session id. Also, I have read in Netscape Standard for Cookies (http://wp.netscape.com/newsref/std/cookie_spec.html for your reference): -- Instances of the same path and name will overwrite each other, with the latest instance taking precedence. Instances of the same path but different names will add additional mappings. -- Well, I suppose this document is pretty old, but nor later RFCs (2109,2965) nor Servlet 2.3 Specification does not contain any information about cookie priority, so it is a good thing to think about. And I am very frustrated that this bug remains NEW for about a year - isn't it a buglist?? Yes, I know that Mr.Maucherat in a similar bug 10419 (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419) resolved this as WONTFIX, saying that he doesn't see any real use cases. Please, reconsider about this or at least say something. Cinecerly, Peter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10419] - Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419 Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2003-03-21 20:15 --- Yes, this is a BUG, and it seems that it is a serious bug, because probably at 1% of sessions are lost with IE, when the session for some circumstances is invalidated but cookie is left non-expired, and after that the new session is generated and IE(6 and 5 for me) _ALWAYS_ sends two cookies JSESSIONID; but the first cookie is for invalid session, so tomcat treats that the session is new, although the second cookie contains the actual session id. Also, I have read in Netscape Standard for Cookies (http://wp.netscape.com/newsref/std/cookie_spec.html for your reference): -- Instances of the same path and name will overwrite each other, with the latest instance taking precedence. Instances of the same path but different names will add additional mappings. -- Well, I suppose this document is pretty old, but nor later RFCs (2109,2965) nor Servlet 2.3 Specification does not contain any information about cookie priority, so it is a good thing to think about. And I am very frustrated that this bug remains NEW for about a year - isn't it a buglist?? Yes, I know that Mr.Maucherat in a similar bug 10419 (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419) resolved this as WONTFIX, saying that he doesn't see any real use cases. Please, reconsider about this or at least say something. Cinecerly, Peter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: domain-wide session cookies?
For those who care, I've answered my own questions: On Thu, 20 Mar 2003 21:40:20 -0800, Aditya [EMAIL PROTECTED] said: Under Tomcat-4 it looks like the session cookie is set in: org/apache/catalina/connector/HttpResponseBase.java and the code that sets it uses the default domain (which is equal to the request hostname.domain.tld) when it sets the session cookie. I need to set the cookie to be domain-wide, ie. .domain.tld however it seems silly to hardcode it in the above class. Before I tackle this: 0) is there a better way to do it? Yup, do it in a filter. Using a filter to manipulate cookies is trivial and using session.isNew() guarantees that we just do this once. If anyone wants any more detail about this strange, slightly yucky hack, please ask. Adi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
domain-wide session cookies?
Under Tomcat-4 it looks like the session cookie is set in: org/apache/catalina/connector/HttpResponseBase.java and the code that sets it uses the default domain (which is equal to the request hostname.domain.tld) when it sets the session cookie. I need to set the cookie to be domain-wide, ie. .domain.tld however it seems silly to hardcode it in the above class. Before I tackle this: 0) is there a better way to do it? 1) if not, is this the right place to do it? 2) what is the best place (ie. where in server.xml) to put an option to enable this? Thanks, Adi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 6983] - SSL + Mac + IE5 = no session cookies
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6983. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6983 SSL + Mac + IE5 = no session cookies --- Additional Comments From [EMAIL PROTECTED] 2003-03-19 09:01 --- The analysis by Anders Rundgren is slightly incorrect, although he is on the right track. It would be good to see this issue resolved as I suspect it affects a larger number of people than anyone realises - IE5 is the default browser on MacOS 9.x, of which there are many installations out there. As suggested in the patch from Jay Sissom, the problem is that IE5/Mac needs a space between the ';' after the last parameter and 'Secure' parameter in the cookie. (The actual value of JSESSIONID that Anders suggested is irrelevent). Although not expected by default, RFC2109 states that White space is permitted between tokens. Therefore it will not affect other browsers, and we have tested to confirm this. We apply this patch to our live servers whenever updating them, and it has fixed past reported problems, and not affected other browsers. So, please could this patch be folded into the main source tree? It would make my life a lot easier. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10419] - Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419 Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-03-20 07:04 --- *** Bug 14354 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17178] New: - if user-agent sends cookies that add up more than 4K SocketInputStream throws an exception
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17178.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17178
if user-agent sends cookies that add up more than 4K SocketInputStream throws an
exception
Summary: if user-agent sends cookies that add up more than 4K
SocketInputStream throws an exception
Product: Tomcat 4
Version: 4.1.20
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
The SocketInputStream class reads HTTP headers up to a maximum of 4096 bytes
(HttpHeader.MAX_VALUE_SIZE), after that it fails logging the exception in
catalina's log.
I assume they hardcoded this limit assuming the maximum length of a single
Cookie (4K). However, browsers append cookies into a single Cookies header
separating the cookies with ';'. If you have 2 cookies going with the same
request and adding up more than 4K, then the request fails.
Offending code [SocketInputStream, line 461]:
if ((2 * maxRead) = HttpHeader.MAX_VALUE_SIZE) {
As browsers are recommended to support at least 20 cookies to a single web site
of 4K each, the value of the HttpHeader.MAX_VALUE_SIZE should be 20 bigger.
[This applies to all 4.x versions]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Cookies, space and MSIE
It seems MSIE on mac ( aparently both 9 and X ) is failing to parse the Cookie if tomcat is used in secure mode ( with SSL enabled ). ( it doesn't matter on which platform you run tomcat - the browser is broken ). I added the extra space - and the problem went away. Remy - should we backport this to 4.1 ( and 4.0 ) ? I made the change in 5.0, and did the tests with a patched 4.1. The problem is: Path=/foo;Secure - fails Path=/foo; Secure - works The examples in the Netscape specification of the Cookie include space after ; - and don't explicitely say the space is optional. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Cookies, space and MSIE
Costin Manolache wrote: It seems MSIE on mac ( aparently both 9 and X ) is failing to parse the Cookie if tomcat is used in secure mode ( with SSL enabled ). ( it doesn't matter on which platform you run tomcat - the browser is broken ). I added the extra space - and the problem went away. Remy - should we backport this to 4.1 ( and 4.0 ) ? I made the change in 5.0, and did the tests with a patched 4.1. +1 for backporting. The problem is: Path=/foo;Secure - fails Path=/foo; Secure - works The examples in the Netscape specification of the Cookie include space after ; - and don't explicitely say the space is optional. Yes, I read your explanation in the commit message. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15555] New: - Setting cookie=false appears to still use cookies.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1 Setting cookie=false appears to still use cookies. Summary: Setting cookie=false appears to still use cookies. Product: Tomcat 4 Version: 4.0.6 Final Platform: PC OS/Version: Windows XP Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I'm trying to disable cookies to use URL rewriting. Using NetBeans, I set the server.xml Context as follows: Context path=/shoestore docBase=shoestore reloadable=true cookies=false However, every time I view a jsp from this context in my browser, a jsessionid cookie is still set. Even when the server is restarted, this behaviour continues. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9791] - Form-based login fails using apache, mod_jk, mod_ssl without cookies
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9791. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9791 Form-based login fails using apache, mod_jk, mod_ssl without cookies [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-11-19 16:27 --- Thanks for looking into this. I was not aware of needing to encode the url like this. I've added the suggested fragment and it works. Thanks! Is that documented somewhere? If not maybe a bug should be filed against the documentation... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9791] - Form-based login fails using apache, mod_jk, mod_ssl without cookies
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9791. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9791 Form-based login fails using apache, mod_jk, mod_ssl without cookies --- Additional Comments From [EMAIL PROTECTED] 2002-11-18 15:29 --- Corey, I've checked through the code and the tomcat side looks fine. Are you sure your login form is ok? For form based authentication without cookies, you need to use URL rewriting on the form action in your login page, like so: form action='%= response.encodeURL(j_security_check) %' If you don't do this, then the session that created the login form will not be requested when the login form is submitted. In particular, if you use a plain .htm login form instead of a jsp, you /must/ use cookies. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9590] - cookies stop sending to browser after nested loop
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9590.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9590
cookies stop sending to browser after nested loop
--- Additional Comments From [EMAIL PROTECTED] 2002-11-18 15:47 ---
Try testing if the response is committed before setting that last cookie,
eg % if (response.isCommitted()) { System.err.println(train has left the
station); } %
If you'd managed to push 256 bytes of whitespace (for example) into the JSP
during that loop then you'll cause the response to commit, so you can no longer
set a 'Set-Cookie' header (or any other header). Also, because the second
addCookie is always adding the same thing, you might not be seeing the real
point that cookies fail, its more likely during the loop than afterwards - try
setting it to a counter instead.
Finally, if the loop has 19 iterations, the /browser/ will cause you a
problem. See
http://jakarta.apache.org/tomcat/tomcat-4.0-doc/servletapi/javax/servlet/http/Cookie.html,
- browsers only have to support 20 cookies per server. You'd have created 20
Set-Cookie headers and the browser would ignore the rest.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cookies with mod_jk 1.2 load balancing and tomcat 4.1.12
How is the cookie written with mod_jk 1.2 and tomcat 4.1.12 to accomplish load balancing? With mod_jk 1.1 and tomcat 3.3 my JSESSIONID would be equal to blah.server_id where blah was the session and .server_id I thought was appended by mod_jk in order to direct the traffic back to the appropriate worker. I've been unsuccessfully trying to get mod_jk 1.2 and tomcat 4.1.12 working with apache 1.3.x and while apache connects to tomcat just fine, the .server_id is never appended to the session and I keep getting bounced from server to server. In addition to mod_jk 1.2, I've also tried mod_jk 1.1 and mod_jk 2.0.1 all with the same issue. Maybe if someone can point me towards the code that is supposed to do the session rewrite I can try to add some debugging to help me discover the problem. Thanks, Jason -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 234] - Can't set multiple cookies in servlet response headers through Ajp13 BugRat Report#371
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=234. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=234 Can't set multiple cookies in servlet response headers through Ajp13 BugRat Report#371 [EMAIL PROTECTED] changed: What|Removed |Added Component|Connectors |Servlet JSP API Product|Tomcat 3|Tomcat 4 Version|3.2.x Nightly |4.0.1 Final -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11596] New: - cookies not working in netscape 4.76 on tomcat 4.0.4
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11596. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11596 cookies not working in netscape 4.76 on tomcat 4.0.4 Summary: cookies not working in netscape 4.76 on tomcat 4.0.4 Product: Tomcat 4 Version: 4.0.4 Final Platform: All OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have a site that initiates a cookie which works fine, however after beginning a new session all I can do is access the cookie. I can't add to it, kill it or insert a new one in place of it and have the new cookie be persisted. It acts as if it is a session variable. I have it running with previous versions of tomcat. Any ideas on this. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10419] - Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419 Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX Version|4.0.4 Final |4.1.6 --- Additional Comments From [EMAIL PROTECTED] 2002-07-03 07:57 --- As I've said, I am not convinced by the use case. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10419] - Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419 Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2002-07-03 08:25 --- No. Just consider the simple case where you have multple application contexts. All of these contexts have their own cookie, since they are separated. If you grab always the first cookie, then you get a session ID that is not valid in the second context. The problem is, that from this (wrong) requestedSessionId() the HttpSession is looked up, thus not found. Bottomline: you can have only one application context running with cookies. I do not agree, that this is not a serious bug! And the second session can not even decide to use URL encoding instead, because cookies (even with invlalid session ids) decide there, that the sessio n needs not to be encoded. Please reconsider this - or we have to write in the documentation that the tomcat session handling can only handle sessions correctly if 1) there is only one context involved 2) we _only_ use cookies, since URL encoding is broken since it will only work in certain cirumstances. I can't see, why we should neglect this part of the spec! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10419] - Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419 Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions [EMAIL PROTECTED] changed: What|Removed |Added Severity|Major |Minor Status|REOPENED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-07-03 08:46 --- Your statement is incorrect. URL encoding does work, but it is a all-or-nothing situation (ie, either you allow session cookies or you don't). As I said, I don't see a use case where the user-agent would submit the session id in the URL for a context, and then would submit it as a cookie for another one. The spec also doesn't specify what is the priority order for the session ids, not that it is really needed anyway IMO. In any case, I don't consider this a major bug, if people think it is a bug. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Bug 10419] - Session-ID grabbing from Request accepts invalidsession cookies in presense of valid URL sessions
Hi, [- this disucsses Bug 10419 and 10418. See details in http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419 and http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10418 with a bug-demonstration servlet http://www.freiheit.com/users/hzeller/SessionBugDemonstration.java this works with JServ and tomcat 3.2 but fails with tc 4.x --- ] Your statement is incorrect. URL encoding does work, but it is a all-or-nothing situation (ie, either you allow session cookies or you don't). Users do sometimes allow cookies for one situation and not for another. The applications shouldn't fail because of this - at least should the application server (tomcat) not make decisions that only the application developer can do. And letting an application fail because once the client used cookies but then in another session chooses not to is not good. Especially, since you cannot do anything to work around this problem in the application since this decision is made in tc. This makes things more fragile which is never good for enterprise quality. And I hope enterprise quality is what we should expect from the flagship of servlet engines! We always have the problem, that we might get multiple session ids (from the URL, from _multple_ cookies). The expected behaviour of getRequestedSessionId() is of course, that it should return a session ID that is (if possible) valid in our context, not just _any_ of the session IDs we got. The servlet spec is not very precise in this point stating, that the getRequestedSessionId() might not necessarily the same as the session in use. However, tomcats lookup mechanism for HttpSessions, does: the id returned by getRequestedSessionId() is the _same_ that is used to lookup the session in the context -- and if this is not a valid session id, we don't get _any_ HttpSession. Or a different problem caused by the same behaviour: Think of the simple use case that is explained in Bug #7588: if we have multiple sessions in different contexts that all use cookies, then all sessions will fail to work but the first one (having the first cookie) Problem here is: there are multiple cookies, but only one of it is valid in an specific context. Just fetching the _first_ cookie ist not possible: only the first application will work (because it can look up a valid HttpSession with the session id), but others not: the first cookie does not denote a valid session id in that context. So: if we use the result of getRequestedSessionId() to lookup the HttpSession (which makes sense), that we _have_ to make sure that we extract the sessionid from the multiple sessionids we might get in the request that actually makes sense in that context. Suggestion: The alternative would be to make getSession() [ HttpRequestBase.doGetSession() ] look itself in the http-request to look for a valid session id from the assortment of possible session ids. instead of using requestedSessionId. Even better would be to delay the determination of requestedSessionId until the context is known: on the first call of getRequestedSessionId() in the application [ and cache the result ]. This would enhance the performance as well in the HttpProcessor.parseHeaders(), since we do the check only if it is necessary at all (Delaying expensive operations is always a good idea). Ok, I'll prepare a patch for this, then we can discuss this. ciao, -hen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10419] - Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419 Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions --- Additional Comments From [EMAIL PROTECTED] 2002-07-03 17:40 --- Here's an FYI regarding disambiguating session id cookies. Tomcat always sets the path attribute of the cookie to correspond to the context path of the web application for which that cookie applies. A client is supposed to send back cookies only when the request URI matches the path prefix. Thus, you will only get 1 session id cookie under the following circumstances: (1) You have context paths nested inside each other (app1 uses /foo and app2 uses /foo/bar) (2) You have a broken client that doesn't respect the path attribute or the cookie value ordering rules (see below for more). Case (1) highlights another interesting issue -- the cookies that are included in the request don't have any identifiers with them, so it is not obvious how you are supposed to tell them apart. Fortunately, the specs define a rule to deal with this -- the client is supposed to send the cookie for the longest matching path first. Thus, in the overlapping case defined above, a request to /foo/bar/baz will include two values for the session id cookie -- first the one for the /foo/bar context and then the one for the /foo context. A request to /foo/xyz will only send the cookie for the /foo context. This is why Tomcat takes the first session id cookie in the list; a properly programmed client will ensure that this is the right one for the most deeply nested context path that matches the request URI. Tomcat cannot do anything to help you on case (2) however. :-) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Bug 10419] - Session-ID grabbing from Request accepts invalidsession cookies in presense of valid URL sessions
On Wed, 3 Jul 2002, Henner Zeller wrote: We always have the problem, that we might get multiple session ids (from the URL, from _multple_ cookies). You should not be getting multiple session id cookies for different webapps unless (a) the context paths overlap, or (b) your client is not following the rules of the specs. See my comments on Bug 10419 for more info on how situation (a) is dealt with. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Bug 10419] - Session-ID grabbing from Request accepts invalidsession cookies in presense of valid URL sessions
Hi, We always have the problem, that we might get multiple session ids (from the URL, from _multple_ cookies). You should not be getting multiple session id cookies for different webapps unless (a) the context paths overlap, or (b) your client is not following the rules of the specs. See my comments on Bug 10419 for more info on how situation (a) is dealt with. ok, sounds good. Considering that the client sends the right cookie for that context first, there is the only problem, that we still can get two session-ids in a request o from the URL o from the cookie. Currently, a cookie overrides a session-id that has been gotten from the URL unconditionally. The whole point here is: if that session id from the cookie is invalid because: a) The session in the cookie is expired or has been invalidated b) The session in the cookie comes from a different application context because for _this_ application context there is no cookie, thus the other cookie is placed first we don't get a HttpSession in the application since it tries to look up it with the wrong ID. If users have cookies enabled all the time, this is probably not the case. Others might be a bit more picky when to allow cookies and in that case the 'override anything requested in the URL' scheme might not be a good idea. Dealing with both possible session ids and give preference to the one that is currently valid in that context should be the goal. -hen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
