On 1/18/12 1:15 AM, Mark Thomas wrote:
> On 18/01/2012 07:46, Remy Maucherat 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 other words, the caller of the API need to know a newSessionId as
follows:
a) javax.servlet.http.HttpServletRequest:
public void changeSessionId(String newSessionId);
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