Let me clarify.
First I agree with Mark on the following:
* we can implement session fixation prevention issue when the session is
the "same" after calling request#changeSessionId.
* it is up to implementation on what to do. It may or may not call
request#changeSessionId.
The question that I had was whether we should retain the same session
object instance.
At the beginning, I have a concern on having a requirement of having the
same object instance in the HA environment.
But on the second thought, it should be.
Otherwise, objects implement HttpSessionBindingListener will be invoked
again which may have other side effect.
Shing Wai Chan
On 10/5/12 4:44 PM, Jan Bartel wrote:
> Mark,
>
> See Shing's previous reply - if the below was your intent then that
> intent did not get communicated to everyone in the spec group. Also,
> I didn't see any discussion, nor proposed javadoc, that mandated that
> the implementation of Request.changeSessionId() should preserve
> object identity on an existing session ... so there is some conflict
> between the behaviour of Request.login() and
> Request.changeSessionId().
>
> Jan
>
> On 5 October 2012 19:03, Mark Thomas<markt_at_apache.org> wrote:
>> On 05/10/2012 04:54, Jan Bartel wrote:
>>> Hi,
>>>
>>> The 3.0 Spec sec 13.10 Login and Logout, page 145 says:
>>>
>>> "If a developer creates a session while a user is not authenticated,
>>> and the container then
>>> authenticates the user, the session visible to developer code after
>>> login must be the
>>> same session object that was created prior to login occurring so that
>>> there is no loss
>>> of session information."
>>>
>>> Does that mean that if a session exists before a user called
>>> Request.login(), the container cannot implement session fixation
>>> prevention and change the session id automatically?
>> No it does not. That assumption is not correct.
>>
>>> If changing the session id is actually permitted, should the above clause
>>> be taken to mean that the object must actually the one and the same?
>>> Ie that sessionPrev == sessionNew ?
>> That is how I read it, what I intended when I proposed the change and
>> how Tomcat implements it. The object stays the same but the ID changes.
>> Tomcat doesn't create a new session object.
>>
>>> Alternatively is the container not permitted to implement automatic
>>> session fixation prevention, and callers of Request.login() must
>>> explicitly call Request.changeSessionId()?
>> That is not correct. The container is free to implement session fixation
>> protection automatically. The expectation is that the session ID will be
>> changed but the session object will remain the same.
>>
>> Mark
>>
>
>