Creating a new session after logout or explicit session invalidation

[Les Hazlewood]

I'm not sure - I think it is undefined - checking the servlet spec now.

At least the HttpServletRequest JavaDoc makes it sound as if it is certainly
possible:

"Returns the current HttpSession associated with this request or, if if
there is no current session and create is true, returns a new session.

  If create is false and the request has no valid HttpSession, this method
returns null.

  To make sure the session is properly maintained, you must call this method
before the response is committed.*
*

*  Parameters:*

      true - to create a new session for this request if necessary; false to
return null if there's no current session*
*

*  Returns:*

    the HttpSession associated with this request or null if create is
falseand the request has no valid session"
Their wording of "valid" gives me hope. If it isn't valid (i.e.
invalidated), it sounds as if a new one would be created.

I'll see if the spec says anything.

On Thu, Jul 31, 2008 at 2:21 PM, Jeremy Haile <[hidden email]> wrote:

> Does HTTP allow this?
>
> Can you call HttpSession.invalidate() and then immediately call
> HttpServletRequest.getSession(true) and get a new session?
>
> If not, we'd have difficulty implementing this since in an HTTP environment
> we replicate those calls to the session.  This sounds worthy of a separate
> thread though if we're going to continue this discussion.
>
> Jeremy
>
>
> On Jul 31, 2008, at 2:07 PM, Les Hazlewood wrote:
>
>  I think it might be more 'correct' to do this in JSecurity via
>> subject.getSession().stop() method instead.  If in an HTTP environment,
>> HttpSession.invalidate() will be called on your behalf.  If not using HTTP
>> container sessions (for whatever reason), it also does the appropriate
>> invalidation on the underlying implementation.
>>
>> But this surfaces an interesting question for the development team:
>>
>> If someone calls subject.getSession().stop(), should they be able to then
>> immediately call subject.getSession() and have it return a brand new
>> session?
>>
>> Currently that doesn't happen.  Any calls on that returned session would
>> throw an InvalidSessionException.  Going back to the desire to prevent
>> these
>> exceptions from occurring when possible, isn't it a good idea to create a
>> new one?
>>
>> I can't think of any reasons at the moment to not allow a new session to
>> be
>> created as described.  I like the idea of making this possible.  What do
>> you
>> guys think?
>
>

[Jeremy Haile]

If the servlet spec allows this, I'm all for it!


On Jul 31, 2008, at 2:34 PM, Les Hazlewood wrote:

> I'm not sure - I think it is undefined - checking the servlet spec  
> now.
>
> At least the HttpServletRequest JavaDoc makes it sound as if it is  
> certainly
> possible:
>
> "Returns the current HttpSession associated with this request or, if  
> if
> there is no current session and create is true, returns a new session.
>
>  If create is false and the request has no valid HttpSession, this  
> method
> returns null.
>
>  To make sure the session is properly maintained, you must call this  
> method
> before the response is committed.*
> *
>
> *  Parameters:*
>
>      true - to create a new session for this request if necessary;  
> false to
> return null if there's no current session*
> *
>
> *  Returns:*
>
>    the HttpSession associated with this request or null if create is
> falseand the request has no valid session"
> Their wording of "valid" gives me hope. If it isn't valid (i.e.
> invalidated), it sounds as if a new one would be created.
>
> I'll see if the spec says anything.
>
> On Thu, Jul 31, 2008 at 2:21 PM, Jeremy Haile <[hidden email]>  
> wrote:
>> Does HTTP allow this?
>>
>> Can you call HttpSession.invalidate() and then immediately call
>> HttpServletRequest.getSession(true) and get a new session?
>>
>> If not, we'd have difficulty implementing this since in an HTTP  
>> environment
>> we replicate those calls to the session.  This sounds worthy of a  
>> separate
>> thread though if we're going to continue this discussion.
>>
>> Jeremy
>>
>>
>> On Jul 31, 2008, at 2:07 PM, Les Hazlewood wrote:
>>
>> I think it might be more 'correct' to do this in JSecurity via
>>> subject.getSession().stop() method instead.  If in an HTTP  
>>> environment,
>>> HttpSession.invalidate() will be called on your behalf.  If not  
>>> using HTTP
>>> container sessions (for whatever reason), it also does the  
>>> appropriate
>>> invalidation on the underlying implementation.
>>>
>>> But this surfaces an interesting question for the development team:
>>>
>>> If someone calls subject.getSession().stop(), should they be able  
>>> to then
>>> immediately call subject.getSession() and have it return a brand new
>>> session?
>>>
>>> Currently that doesn't happen.  Any calls on that returned session  
>>> would
>>> throw an InvalidSessionException.  Going back to the desire to  
>>> prevent
>>> these
>>> exceptions from occurring when possible, isn't it a good idea to  
>>> create a
>>> new one?
>>>
>>> I can't think of any reasons at the moment to not allow a new  
>>> session to
>>> be
>>> created as described.  I like the idea of making this possible.  
>>> What do
>>> you
>>> guys think?
>>
>>

[Les Hazlewood]

The (2.3 and 2.4) servlet spec doesn't mention any behavior beyond what I've
already quoted.  It doesn't mention anywhere that this is _not_ allowed or
expected.

The request.getSession(true) java doc certainly sounds like what I describe
is allowed, and I think we can actually rely on it for the behavior I
described earlier.  I'll elaborate:

1.  "Returns the current HttpSession associated with this request or, if if
there is no current session and create is true, returns a new session."

Immediately after calling subject.getSession().stop(), there is no longer a
'current' or valid session - the http session is invalidated and the
JSecurity reference would be nulled out.  So, if then there is an immediate
call to subject.getSession(), which equals subject.getSession(true), which
in turn really calls request.getSession(true), this means it should return a
new session per the spec wording.

2.  "If create is false and the request has no valid HttpSession, this
method
returns null."

Immediately after calling subject.getSession().stop(), there is no *valid*
HttpSession anymore.  Per the spec wording therefore, any call to
subject.getSession(false) --> request.getSession(false) should return null.

I'm going to run a quick test in Tomcat (not a mock unit test) that does the
following:

request.getSession().setAttribute( "quickTest", new Object() );
request.getSession().invalidate();
request.getSession().getAttribute( "quickTest" ) == null (and also this call
does not throw any exceptions).

Because the behavior I outlined in the previous post conforms exactly to
this spec wording, and assuming the above test works as expected, I think
I'll add this behavior unless anyone finds a good reason to object.

Thanks for the feedback!

Les

On Thu, Jul 31, 2008 at 3:55 PM, Jeremy Haile <[hidden email]> wrote:

> If the servlet spec allows this, I'm all for it!
>
>
> On Jul 31, 2008, at 2:34 PM, Les Hazlewood wrote:
>
>  I'm not sure - I think it is undefined - checking the servlet spec now.
>>
>> At least the HttpServletRequest JavaDoc makes it sound as if it is
>> certainly
>> possible:
>>
>> "Returns the current HttpSession associated with this request or, if if
>> there is no current session and create is true, returns a new session.
>>
>>  If create is false and the request has no valid HttpSession, this method
>> returns null.
>>
>>  To make sure the session is properly maintained, you must call this
>> method
>> before the response is committed.*
>> *
>>
>> *  Parameters:*
>>
>>     true - to create a new session for this request if necessary; false to
>> return null if there's no current session*
>> *
>>
>> *  Returns:*
>>
>>   the HttpSession associated with this request or null if create is
>> false and the request has no valid session"
>>
>> Their wording of "valid" gives me hope. If it isn't valid (i.e.
>> invalidated), it sounds as if a new one would be created.
>>
>> I'll see if the spec says anything.
>>
>> On Thu, Jul 31, 2008 at 2:21 PM, Jeremy Haile <[hidden email]> wrote:
>>
>>> Does HTTP allow this?
>>>
>>> Can you call HttpSession.invalidate() and then immediately call
>>> HttpServletRequest.getSession(true) and get a new session?
>>>
>>> If not, we'd have difficulty implementing this since in an HTTP
>>> environment
>>> we replicate those calls to the session.  This sounds worthy of a
>>> separate
>>> thread though if we're going to continue this discussion.
>>>
>>> Jeremy
>>>
>>>
>>> On Jul 31, 2008, at 2:07 PM, Les Hazlewood wrote:
>>>
>>> I think it might be more 'correct' to do this in JSecurity via
>>>
>>>> subject.getSession().stop() method instead.  If in an HTTP environment,
>>>> HttpSession.invalidate() will be called on your behalf.  If not using
>>>> HTTP
>>>> container sessions (for whatever reason), it also does the appropriate
>>>> invalidation on the underlying implementation.
>>>>
>>>> But this surfaces an interesting question for the development team:
>>>>
>>>> If someone calls subject.getSession().stop(), should they be able to
>>>> then
>>>> immediately call subject.getSession() and have it return a brand new
>>>> session?
>>>>
>>>> Currently that doesn't happen.  Any calls on that returned session would
>>>> throw an InvalidSessionException.  Going back to the desire to prevent
>>>> these
>>>> exceptions from occurring when possible, isn't it a good idea to create
>>>> a
>>>> new one?
>>>>
>>>> I can't think of any reasons at the moment to not allow a new session to
>>>> be
>>>> created as described.  I like the idea of making this possible.  What do
>>>> you
>>>> guys think?
>>>>
>>>
>>>
>>>
>

[Jeremy Haile]

Sounds good to me.  If that works in Tomcat, let's make sure it works  
with JSecurity sessions as well.


On Aug 1, 2008, at 9:39 AM, Les Hazlewood wrote:

> The (2.3 and 2.4) servlet spec doesn't mention any behavior beyond  
> what I've
> already quoted.  It doesn't mention anywhere that this is _not_  
> allowed or
> expected.
>
> The request.getSession(true) java doc certainly sounds like what I  
> describe
> is allowed, and I think we can actually rely on it for the behavior I
> described earlier.  I'll elaborate:
>
> 1.  "Returns the current HttpSession associated with this request  
> or, if if
> there is no current session and create is true, returns a new  
> session."
>
> Immediately after calling subject.getSession().stop(), there is no  
> longer a
> 'current' or valid session - the http session is invalidated and the
> JSecurity reference would be nulled out.  So, if then there is an  
> immediate
> call to subject.getSession(), which equals subject.getSession(true),  
> which
> in turn really calls request.getSession(true), this means it should  
> return a
> new session per the spec wording.
>
> 2.  "If create is false and the request has no valid HttpSession, this
> method
> returns null."
>
> Immediately after calling subject.getSession().stop(), there is no  
> *valid*
> HttpSession anymore.  Per the spec wording therefore, any call to
> subject.getSession(false) --> request.getSession(false) should  
> return null.
>
> I'm going to run a quick test in Tomcat (not a mock unit test) that  
> does the
> following:
>
> request.getSession().setAttribute( "quickTest", new Object() );
> request.getSession().invalidate();
> request.getSession().getAttribute( "quickTest" ) == null (and also  
> this call
> does not throw any exceptions).
>
> Because the behavior I outlined in the previous post conforms  
> exactly to
> this spec wording, and assuming the above test works as expected, I  
> think
> I'll add this behavior unless anyone finds a good reason to object.
>
> Thanks for the feedback!
>
> Les
>
> On Thu, Jul 31, 2008 at 3:55 PM, Jeremy Haile <[hidden email]>  
> wrote:
>
>> If the servlet spec allows this, I'm all for it!
>>
>>
>> On Jul 31, 2008, at 2:34 PM, Les Hazlewood wrote:
>>
>> I'm not sure - I think it is undefined - checking the servlet spec  
>> now.
>>>
>>> At least the HttpServletRequest JavaDoc makes it sound as if it is
>>> certainly
>>> possible:
>>>
>>> "Returns the current HttpSession associated with this request or,  
>>> if if
>>> there is no current session and create is true, returns a new  
>>> session.
>>>
>>> If create is false and the request has no valid HttpSession, this  
>>> method
>>> returns null.
>>>
>>> To make sure the session is properly maintained, you must call this
>>> method
>>> before the response is committed.*
>>> *
>>>
>>> *  Parameters:*
>>>
>>>    true - to create a new session for this request if necessary;  
>>> false to
>>> return null if there's no current session*
>>> *
>>>
>>> *  Returns:*
>>>
>>>  the HttpSession associated with this request or null if create is
>>> false and the request has no valid session"
>>>
>>> Their wording of "valid" gives me hope. If it isn't valid (i.e.
>>> invalidated), it sounds as if a new one would be created.
>>>
>>> I'll see if the spec says anything.
>>>
>>> On Thu, Jul 31, 2008 at 2:21 PM, Jeremy Haile <[hidden email]>  
>>> wrote:
>>>
>>>> Does HTTP allow this?
>>>>
>>>> Can you call HttpSession.invalidate() and then immediately call
>>>> HttpServletRequest.getSession(true) and get a new session?
>>>>
>>>> If not, we'd have difficulty implementing this since in an HTTP
>>>> environment
>>>> we replicate those calls to the session.  This sounds worthy of a
>>>> separate
>>>> thread though if we're going to continue this discussion.
>>>>
>>>> Jeremy
>>>>
>>>>
>>>> On Jul 31, 2008, at 2:07 PM, Les Hazlewood wrote:
>>>>
>>>> I think it might be more 'correct' to do this in JSecurity via
>>>>
>>>>> subject.getSession().stop() method instead.  If in an HTTP  
>>>>> environment,
>>>>> HttpSession.invalidate() will be called on your behalf.  If not  
>>>>> using
>>>>> HTTP
>>>>> container sessions (for whatever reason), it also does the  
>>>>> appropriate
>>>>> invalidation on the underlying implementation.
>>>>>
>>>>> But this surfaces an interesting question for the development  
>>>>> team:
>>>>>
>>>>> If someone calls subject.getSession().stop(), should they be  
>>>>> able to
>>>>> then
>>>>> immediately call subject.getSession() and have it return a brand  
>>>>> new
>>>>> session?
>>>>>
>>>>> Currently that doesn't happen.  Any calls on that returned  
>>>>> session would
>>>>> throw an InvalidSessionException.  Going back to the desire to  
>>>>> prevent
>>>>> these
>>>>> exceptions from occurring when possible, isn't it a good idea to  
>>>>> create
>>>>> a
>>>>> new one?
>>>>>
>>>>> I can't think of any reasons at the moment to not allow a new  
>>>>> session to
>>>>> be
>>>>> created as described.  I like the idea of making this possible.  
>>>>> What do
>>>>> you
>>>>> guys think?
>>>>>
>>>>
>>>>
>>>>
>>

[Les Hazlewood]

Sweet!  I verified that the following JSP functions fine (no exceptions
thrown):

<%-- begin sessionTest.jsp --%>
<%
    String key = "testKey";
    String value = "testValue";
    request.getSession().setAttribute(key, value);
    assert request.getSession().getAttribute(key).equals(value);
    System.out.println("First Session ID: " + request.getSession().getId()
);
    request.getSession().invalidate();
    assert request.getSession() != null;
    assert request.getSession().getAttribute(key) == null;
    System.out.println("Second Session ID: " + request.getSession().getId()
);
%>
<html>
<body>
<h1>It worked!</h1>
</body>
</html>
<%-- end sessionTest.jsp --%>

I hit the page once, and then refreshed it again, and you can see that it
does indeed print out two different session ids on each request (the refresh
was to show the session id was consistent across requests, but changed
correctly after invalidation):

catalina.out:
First Session ID: ECA1F6C889DFC51608D907BC72747C32
Second Session ID: 6DCA18B0854637BE39751873ED468B39
First Session ID: 6DCA18B0854637BE39751873ED468B39
Second Session ID: D1B52AE47827424E6711127CD74A5AA4

So, I'm going to add this support to JSecurity - to ensure that
subject.getSession().stop(); and subject.getSession().<any method here> will
function the same way (both web and non-web environments).

Cheers,

Les

On Fri, Aug 1, 2008 at 9:52 AM, Jeremy Haile <[hidden email]> wrote:

> Sounds good to me.  If that works in Tomcat, let's make sure it works with
> JSecurity sessions as well.
>
>
>
> On Aug 1, 2008, at 9:39 AM, Les Hazlewood wrote:
>
>  The (2.3 and 2.4) servlet spec doesn't mention any behavior beyond what
>> I've
>> already quoted.  It doesn't mention anywhere that this is _not_ allowed or
>> expected.
>>
>> The request.getSession(true) java doc certainly sounds like what I
>> describe
>> is allowed, and I think we can actually rely on it for the behavior I
>> described earlier.  I'll elaborate:
>>
>> 1.  "Returns the current HttpSession associated with this request or, if
>> if
>> there is no current session and create is true, returns a new session."
>>
>> Immediately after calling subject.getSession().stop(), there is no longer
>> a
>> 'current' or valid session - the http session is invalidated and the
>> JSecurity reference would be nulled out.  So, if then there is an
>> immediate
>> call to subject.getSession(), which equals subject.getSession(true), which
>> in turn really calls request.getSession(true), this means it should return
>> a
>> new session per the spec wording.
>>
>> 2.  "If create is false and the request has no valid HttpSession, this
>> method
>> returns null."
>>
>> Immediately after calling subject.getSession().stop(), there is no *valid*
>> HttpSession anymore.  Per the spec wording therefore, any call to
>> subject.getSession(false) --> request.getSession(false) should return
>> null.
>>
>> I'm going to run a quick test in Tomcat (not a mock unit test) that does
>> the
>> following:
>>
>> request.getSession().setAttribute( "quickTest", new Object() );
>> request.getSession().invalidate();
>> request.getSession().getAttribute( "quickTest" ) == null (and also this
>> call
>> does not throw any exceptions).
>>
>> Because the behavior I outlined in the previous post conforms exactly to
>> this spec wording, and assuming the above test works as expected, I think
>> I'll add this behavior unless anyone finds a good reason to object.
>>
>> Thanks for the feedback!
>>
>> Les
>>
>> On Thu, Jul 31, 2008 at 3:55 PM, Jeremy Haile <[hidden email]> wrote:
>>
>>  If the servlet spec allows this, I'm all for it!
>>>
>>>
>>> On Jul 31, 2008, at 2:34 PM, Les Hazlewood wrote:
>>>
>>> I'm not sure - I think it is undefined - checking the servlet spec now.
>>>
>>>>
>>>> At least the HttpServletRequest JavaDoc makes it sound as if it is
>>>> certainly
>>>> possible:
>>>>
>>>> "Returns the current HttpSession associated with this request or, if if
>>>> there is no current session and create is true, returns a new session.
>>>>
>>>> If create is false and the request has no valid HttpSession, this method
>>>> returns null.
>>>>
>>>> To make sure the session is properly maintained, you must call this
>>>> method
>>>> before the response is committed.*
>>>> *
>>>>
>>>> *  Parameters:*
>>>>
>>>>   true - to create a new session for this request if necessary; false to
>>>> return null if there's no current session*
>>>> *
>>>>
>>>> *  Returns:*
>>>>
>>>>  the HttpSession associated with this request or null if create is
>>>> false and the request has no valid session"
>>>>
>>>> Their wording of "valid" gives me hope. If it isn't valid (i.e.
>>>> invalidated), it sounds as if a new one would be created.
>>>>
>>>> I'll see if the spec says anything.
>>>>
>>>> On Thu, Jul 31, 2008 at 2:21 PM, Jeremy Haile <[hidden email]>
>>>> wrote:
>>>>
>>>>  Does HTTP allow this?
>>>>>
>>>>> Can you call HttpSession.invalidate() and then immediately call
>>>>> HttpServletRequest.getSession(true) and get a new session?
>>>>>
>>>>> If not, we'd have difficulty implementing this since in an HTTP
>>>>> environment
>>>>> we replicate those calls to the session.  This sounds worthy of a
>>>>> separate
>>>>> thread though if we're going to continue this discussion.
>>>>>
>>>>> Jeremy
>>>>>
>>>>>
>>>>> On Jul 31, 2008, at 2:07 PM, Les Hazlewood wrote:
>>>>>
>>>>> I think it might be more 'correct' to do this in JSecurity via
>>>>>
>>>>>  subject.getSession().stop() method instead.  If in an HTTP
>>>>>> environment,
>>>>>> HttpSession.invalidate() will be called on your behalf.  If not using
>>>>>> HTTP
>>>>>> container sessions (for whatever reason), it also does the appropriate
>>>>>> invalidation on the underlying implementation.
>>>>>>
>>>>>> But this surfaces an interesting question for the development team:
>>>>>>
>>>>>> If someone calls subject.getSession().stop(), should they be able to
>>>>>> then
>>>>>> immediately call subject.getSession() and have it return a brand new
>>>>>> session?
>>>>>>
>>>>>> Currently that doesn't happen.  Any calls on that returned session
>>>>>> would
>>>>>> throw an InvalidSessionException.  Going back to the desire to prevent
>>>>>> these
>>>>>> exceptions from occurring when possible, isn't it a good idea to
>>>>>> create
>>>>>> a
>>>>>> new one?
>>>>>>
>>>>>> I can't think of any reasons at the moment to not allow a new session
>>>>>> to
>>>>>> be
>>>>>> created as described.  I like the idea of making this possible.  What
>>>>>> do
>>>>>> you
>>>>>> guys think?
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>

[Jeremy Haile]

> So, I'm going to add this support to JSecurity - to ensure that
> subject.getSession().stop(); and subject.getSession().<any method  
> here> will
> function the same way (both web and non-web environments).

+1

[Les Hazlewood]

All done, with validating unit tests.  Works nicely ;)

On Fri, Aug 1, 2008 at 12:46 PM, Jeremy Haile <[hidden email]> wrote:

> So, I'm going to add this support to JSecurity - to ensure that
>> subject.getSession().stop(); and subject.getSession().<any method here>
>> will
>> function the same way (both web and non-web environments).
>>
>
> +1
>