I agree that adding a method to allow the application to provoke a session
ID change is a good addition.
However, I question why this is on the Request API? Surely it would be
better on the HttpSession itself?
With regards to a changed ID listener, this should definitely be on a new
interface HttpSessionIdListener that will be called if the ID is changed
either by the container or as a result of the API call.
In summary :
interface HttpSession
{
....
String changeSessionId();
}
interface HttpSessionIdListener extends EventListener
{
public void sessionIdChanged(HttpSessionEvent event, String
oldSessionId);
}
On 26 January 2012 05:57, Shing Wai Chan <shing.wai.chan_at_oracle.com> wrote:
> On 1/25/12 4:39 AM, Mark Thomas wrote:
>
>> On 25/01/2012 02:43, Alex Rojkov wrote:
>>
>>> I don't think it should be default behaviour because it definitely
>>> breaks the session id contracts
>>> established by previous versions of the spec.
>>>
>> Whether or not the session id is changed on authentication should be up
>> to the container. My own view is that they should but I only get a vote
>> on what Tomcat does. The specification should not mandate either doing
>> this or not doing this.
>>
> GlassFish also changes session id on authentication.
> I agree that the spec should not mandate the behavior.
>
> Shing Wai Chan
>
>
>> So adding the method onto an HttpSessionListener is fine and no need to
>>> create an extra class.
>>>
>> I'm happy with doing this and letting the containers make the decision
>> re backwards compatibility. I'd also be happy with a new interface.
>>
>> Mark
>>
>
>