Add A Comment:

Please login

Followup

Message Date: 2011-06-10 20:12 Sender: evlist Logged In: YES user_id=8109 Another option: if the Session Invalidator processor would store the old JSESSIONID, the page flow controller could force a page reload in response to the request when seeing a request with this value (the browser would then send the new JSESSIONID). Wouldn't that work? Eric Date: 2011-06-10 19:58 Sender: evlist Logged In: YES user_id=8109 Erik, That's a serious problem indeed ;) ! Looks like we need a way to match the "old" and "new" versions of the JSESSIONID. The login form could retrieve and pass the "old" JSESSIONID to j_security_check (as an hidden field) so that j_security_check save that info server side. The big downside is that existing login pages would have to be updated... Eric Date: 2011-06-10 18:10 Sender: ebruchez Logged In: YES user_id=5065 Eric, The problem is that I wouldn't know how to fix this in Orbeon! Do you have an idea? -Erik Date: 2011-06-10 12:44 Sender: evlist Logged In: YES user_id=8109 I have been hit for one of my applications and have noticed that if you reload your page after authentication everything is OK (the sessions cookie is probably reset correctly). This is still painful since your first page after authentication is broken (if it relies on services) but this means that a workaround can be found by adding an action on xforms-submit-done on one of this services' submission to reload the page (this reload can be done passing a counter to avoid that the page is reloaded forever if the service is genuinely broken). Now, this workaround is messy and needs to be applied to any page that uses services and can be reached after authentication and that would be really useful to get a better solution. I took a look at the Tomcat bug that has been entered and their arguments that this is not a bug but rather a useful feature that prevents session hijacking seem valid to me. What about implementing a fix in Orbeon Forms? Date: 2011-01-22 23:00 Sender: ebruchez Logged In: YES user_id=5065 The Tomcat "bug" I entered is actually not a bug but a feature of Tomcat, which replays the request after authentication. What this means though is that one cannot rely on the JSESSIONID cookie in this way. See more comments in Connection.java. For now, we don't fix this, but we lower the priority as it's not easily fixable as such. Date: 2011-01-22 07:28 Sender: avernet Logged In: YES user_id=4620 Since this caused by a bug in Tomcat, and that we reported the bug, I suggest we document this limitation, and lower the priority of this bug. Date: 2011-01-22 04:08 Sender: ebruchez Logged In: YES user_id=5065 Possible Tomcat bug. I submitted this: https://issues.apache.org/bugzilla/show_bug.cgi?id=50633

Attached Files:

Changes:

Field Old Value Date By priority 9 2011-01-22 23:00 ebruchez priority 7 2010-12-03 19:10 ebruchez