On 19/04/2011 16:27, Filip Hanik - Dev Lists wrote: > > > On 4/18/2011 4:39 AM, Mark Thomas wrote: >> On 18/04/2011 10:13, Remy Maucherat wrote: >>> On Sat, 2011-04-16 at 22:25 +0000, ma...@apache.org wrote: >>>> Author: markt >>>> Date: Sat Apr 16 22:25:28 2011 >>>> New Revision: 1094069 >>>> >>>> URL: http://svn.apache.org/viewvc?rev=1094069&view=rev >>>> Log: >>>> Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=51042 >>>> Don't trigger session creation listeners when changing the session >>>> ID during authentication. >>> But the listeners have to be aware that the id changed. >> Why? I have checked the Servlet spec and I don't see any event defined >> for "session ID changed". I also don't see anything (although I may have >> missed it) that says the ID must be constant. > > Every logical application that uses the ID as a key, would like to know > that the ID has changed since the key is no longer valid. Those apps > would rely on some sort event that the key is no longer there. > regardless of what the servlet spec says, it's seems logical.
That raises the question of what event to fire. The session lifecycle events are for when <spec-quote>An HttpSession has been created, invalidated, or timed out.</spec-quote>. None of those apply in this case. Hence my leaning towards the view that no event should be fired. If this causes an issue for an application, it can always disable the session fixation protection and provide their own alternative protection. I assume that you are suggesting that the session invalidated + session created events are used, but as I said before, if those events are fired then the object binding and attribute change events should also be fired. I can see firing all these additional events being more likely to cause problems for applications that just a change of the session ID. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
