> 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.
Did we dissect a case of serving two or more connections simultaneously? Even on a single machine there is a possibility of executing 2 or more simultaneous requests from the same client.
What's the proper thing to do when the first connection changes the session id while the second connection offers an older session-id and has yet to obtain the HttpSession using old session-id? (old session-id is an id prior to change)
I am not exactly sure yet… I think a session should be made available by an old session-id to a connection that opened before session-id changes. If so… how far back do we go? i.e. how many previously used Ids for the same session remain valid for fetching the session? (connection priority rule observed)
That should also help with the problem represented by the async requests, which could outlive several session-id changes for the same session.
Alex
> 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
>>>
>>
>>
>
>