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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>>>> 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?
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>
