tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: svn commit: r1094069 - in /tomcat/trunk: java/org/apache/catalina/ java/org/apache/catalina/ha/session/ java/org/apache/catalina/manager/ java/org/apache/catalina/session/ webapps/docs/
Date Tue, 26 Apr 2011 22:24:30 GMT
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, wrote:
>>>>> Author: markt
>>>>> Date: Sat Apr 16 22:25:28 2011
>>>>> New Revision: 1094069
>>>>> URL:
>>>>> Log:
>>>>> Fix
>>>>> 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
> 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:
> For additional commands, e-mail:
> -----
> No virus found in this message.
> Checked by AVG -
> Version: 10.0.1209 / Virus Database: 1500/3593 - Release Date: 04/23/11

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message