On 10/8/12 5:16 PM, Shing Wai Chan wrote:
> 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.
Also, it would be more problematic when the session attributes has a
indirect self-reference as follows:
sessions.setAttribute("a", A);
where A is an object that has a reference to session.
In this case, it would be better to keep the same object instance.
>
> 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
>>>
>>
>>
>