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?
On Thu, Jul 31, 2008 at 1:28 PM, Jeremy Haile <[EMAIL PROTECTED]>
wrote:
Well, the way JSecurity works an explicit logout removes the
"remember me"
cookie. A session timeout will of course not remove the remember
me cookie.
So if the user doesn't log out and their session times out then
when they
go back to the site they are remembered. However, if the
explicitly log out
and return to the site, they will have to re-authenticate.
If you want to simply un-authenticate them, but not remove the
remember me,
you could just invalidate their current HTTP session by calling
HttpSession.invalidate(), but don't call Subject.logout(). Their
next
request would start a new session which would be remembered, but not
authenticated.
Hope this helps!
Jeremy
On Jul 31, 2008, at 1:21 PM, Brad Whitaker wrote:
Thanks for the response -- I didn't realize that Subject.logout()
would
remove the remember me cookies.
This behavior surprises me a little bit and leads to a different
question:
is there a way to "un-authenticate" a user? It seems it would
valuable to be
able to log a user out but still remember them. Am I missing this
in the API
or does this capability not currently exist?
Brad
Jeremy Haile wrote:
Hey Brad,
The usual way of forcing JSecurity to "forget" a subject is to call
Subject.logout() - this should remove any remember me cookies as
well.
Perhaps you could auto-logout subjects in your development
environment upon
first access? You could also just bookmark the /logout URL and
click the
bookmark when you start a new development session.
This would be difficult to do on the server side (i.e. without a
web
request from a browser), since it involves actually clearing the
cookie from
a user's machine.
Please let me know if you have any ideas about how JSecurity
could make
this process easier.
Jeremy
On Jul 31, 2008, at 12:11 PM, Brad Whitaker wrote:
Is it possible to force JSecurity to "forget" a subject that has
previously been remembered?
This is an issue for me only in "development" mode and shouldn't
occur
in a production environment. The problem is that I often start a
development
session with an empty user database but the browser comes to the
site with a
cookie. I end up getting a Principal that I don't know. I would
like to
discard the cookie at this point. Is this possible? Or is there
a better way
to deal with this issue (other than clearing the cache on the
browser)?
Thanks,
Brad
