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
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
