On 26/04/2011 23:24, Filip Hanik - Dev Lists wrote: > On 4/21/2011 8:00 AM, Mark Thomas wrote: >> 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. > There is nothing that keeps us from defining events. While adhering to > the spec, it doesn't mean to limit us to it. > This is a pretty important event, the change of the ID (key) to existing > data. > I'd be considering a ID_CHANGE_EVENT here
+1. That works for me. Mark >> 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 >> >> >> >> ----- >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 10.0.1209 / Virus Database: 1500/3593 - Release Date: 04/23/11 >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
