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? >>>> >>> >>> >>> >
