jsr340-experts@servlet-spec.java.net

[jsr340-experts] Re: SERVLET_SPEC-13: Make session fixation protection part of the spec

From: Alex Rojkov <alex_at_caucho.com>
Date: Tue, 24 Jan 2012 18:43:14 -0800

>>>>>>>> On Tue, 2012-01-17 at 17:36 -0800, Shing Wai Chan wrote:
>>>>>> I notice one more different: a String argument.
>>>>>> In Tomcat (and also GlassFish), we have
>>>>>> org.apache.catalina.connector.Request#changeSessionId(String newSessionId)
>>>>> In my opinion the session ids must be container managed. We can't rely on the users
>>>>> of the API to be able to generate good IDs. I am not in favour of letting users
>>>>> generate Ids.
>>>> Agreed. org.apache.catalina.connector.Request is an internal class and
>>>> could easily be refactored to not take the new session ID.
>>>>
>>>>>> In other words, the caller of the API need to know a newSessionId as follows:
>>>>>> a) javax.servlet.http.HttpServletRequest:
>>>>>> public void changeSessionId(String newSessionId);
>>>>> -1. See above.
>>>> Agreed. -1 to the API allowing the new ID to be specified.
>>>>
>>>>> public void changeSessionId() is OK.
>>>>>
>>>>> public String changeSessionId() can be considered as alternative.
>>>>>
>>>>> It's likely that the new sessionId will be needed right after it's generated.
>>>> I have no issues with this proposed change.
>>>>
>>>> Mark
>>> Agreed to have this on HttpServletRequest.
>>>>> Alex
>>>>>
>>>>>> Also, in previous bug comments and discussion, there is a suggestion to add a new method:
>>>>>> b) javax.servlet.http.HttpSessionListener
>>>>>> public void sessionIdChanged(HttpSessionEvent se);
>>>>>>
>>>>>> Note that (b) may break some of the user applications. Is it ok?
>>
>> I am not sure I understand how it breaks existing apps.
> Suppose there is an application using form based login and has an HttpSessionListener.
> With the API, HttpServletRequest#changeSessionId will be invoked by the container and
> an event will be fired.

I don't think it should be default behaviour because it definitely breaks the session id contracts
established by previous versions of the spec.

So adding the method onto an HttpSessionListener is fine and no need to create an extra class.

Alex

> Hence "HttpSessionListener#sessionIdChanged" will be called.
> But the old HttpSessionListener interface does not have that method.
>
> Shing Wai Chan
>>
>> Alex
>>
>>>>>> Shing Wai Chan
>>>>>>
>>>>>>
>>>>>>
>>> I feel the change of session id has to be notified. Since adding it in HttpSessionListener might break the interface. How about introducing an standard 'javax.servlet.http.session.id' session attribute and notify using :
>>> javax.servlet.http.HttpSessionAttributeListener
>>> void attributeAdded(javax.servlet.http.HttpSessionBindingEvent event);
>>> void attributeReplaced(javax.servlet.http.HttpSessionBindingEvent event);
>>>
>>>
>
>
>