On 1/19/12 2:41 PM, Alex Rojkov wrote:
>>>> On Tue, 2012-01-17 at 17:36 -0800, Shing Wai Chan wrote:
>>>>> I am looking at http://java.net/jira/browse/SERVLET_SPEC-13
>>>>> ("SERVLET_SPEC-13: Make session fixation protection part of the spec")
>>>> As the container would use this automagically, it would break existing
>>>> applications (the session id is used often as a key).
>>> I've seen little evidence of that on the Tomcat users list since Tomcat
>>> 7 introduced this behaviour by default.
>>>
>>> There was one instance where an applet broke because it continued to use
>>> the old session ID and didn't pick up the new one.
>>>
>>> That said, it would be advisable for containers to make any automatic
>>> use of this API configurable.
>>>
>>>> The new changeSessionId API method, if added, must be added on the
>>>> request object (since the request has fields about the session that must
>>>> be updated, and a new cookie must be added). So -1 for adding it on
>>>> HttpSession, I think this won't work well.
>>> Makes sense to me. Tomcat's implementation already has this so plumbing
>>> it in to the Servlet API would be trivial.
>> 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.
I have a concern about this, too.
The caller may need to know the algorithm for generating the 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.
>
> public void changeSessionId() is OK.
>
> public String changeSessionId() can be considered as alternative.
+1 for the latter api.
>
> It's likely that the new sessionId will be needed right after it's generated.
>
> 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?
>>
>> Shing Wai Chan
>>
>>
>>