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?
