You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shiro.apache.org by Brad Whitaker <br...@agilemark.com> on 2008/07/31 18:11:04 UTC
jsecurity-user: is it possible to force a discard a "remember me"
cookie?
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
Re: jsecurity-user: is it possible to force a discard a "remember me" cookie?
Posted by Les Hazlewood <le...@hazlewood.com>.
Agreed - moving to new thread.
On Thu, Jul 31, 2008 at 2:21 PM, Jeremy Haile <jh...@fastmail.fm> 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?
>>
>>
>> On Thu, Jul 31, 2008 at 1:28 PM, Jeremy Haile <jh...@fastmail.fm> 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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>
Re: jsecurity-user: is it possible to force a discard a "remember me" cookie?
Posted by Jeremy Haile <jh...@fastmail.fm>.
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 <jh...@fastmail.fm>
> 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
>>>>>
>>>>
>>>>
>>>>
>>>
>>
Re: jsecurity-user: is it possible to force a discard a "remember me" cookie?
Posted by Les Hazlewood <le...@hazlewood.com>.
Hi Brad,
No worries - I didn't feel like it was 'noise' at all. It is always good to
brainstorm and think of better ways to support different behaviors. Some
work and are added, some don't make it. It is a valuable thing for a
community, so thanks for your feedback :)
Cheers,
Les
On Thu, Jul 31, 2008 at 8:15 PM, Brad Whitaker <br...@agilemark.com> wrote:
> Les is correct that my first and second questions were exact opposites.
> Jeremy answered my first question and the solution is completely
> satisfactory for handling the weird condition that occurs only in devel
> mode.
>
> My second question came up when I realized what Subject.logout() is
> discarding the "remember me" cookie as a side effect of logout. I wanted a
> way to have the user "de-authenticate" without being forgotten. Upon further
> review I guess it makes little sense to do this. So I withdraw my request
> and apologize for the all the noise.
>
> Thanks,
>
> Brad
>
>
> Jeremy Haile wrote:
>
>> Brad,
>>
>> My main concern is altering the Subject interface for what may be a rare
>> case and one that has a pretty easy workaround (just invalidate the
>> session). I think that usually when a user logs out, they expect their
>> remembered identity to be logged out as well. Currently, logout() marks
>> the user unauthenticated, forgets their remembered identity, and ends
>> their session - which is the behavior of most web apps that I'm familiar
>> with.
>>
>> As Les mentioned, I'd love to hear more detail about your use case. If
>> this seems to be a common case, then we could definitely consider adding
>> the functionality to Subject.
>> Jeremy
>>
>> On Thu, 31 Jul 2008 19:29:32 -0400, "Les Hazlewood" <le...@hazlewood.com>
>> said:
>>
>>
>>> Hi Brad,
>>>
>>> Could you please summarize the exact end result that you're trying to
>>> achieve? I'm a tad confused at the moment. Your first question was to
>>> see
>>> if the remembered identity could be explicitly forgotten and/or ignored
>>> after a fresh DB install during development. The second question asks if
>>> you can logout a user but still retain the remember me identity, which is
>>> almost an exact opposite of the first question :)
>>>
>>> Perhaps if you could explain exactly what you're trying to achieve, then
>>> it
>>> would be easier for me to think of how this might apply to our API.
>>>
>>> I'm a little hesitant to alter the Subject interface (at least at the
>>> moment) because this is one of the very core interfaces of JSecurity,
>>> used
>>> everywhere by everyone (in JSecurity's 'guts' as well as end-users. I
>>> just
>>> try to think long and hard before doing these kinds of things.
>>>
>>> So, in getting clarification, I might be able to say "Oh, this is easy,
>>> we
>>> could modify some behavior in the SecurityManager implementation to
>>> achieve
>>> what you want" (template methods or whatever), which would be much more
>>> digestible than changing such a critical API interface.
>>>
>>> I'm definitely willing to try to make your life easy, I'm just confused
>>> at
>>> the moment by the polarity of the two questions ;)
>>>
>>> Thanks!
>>>
>>> Les
>>>
>>> On Thu, Jul 31, 2008 at 6:03 PM, Brad Whitaker <br...@agilemark.com>
>>> wrote:
>>>
>>>
>>>
>>>> I've been trying to use subject.getSession().stop() but I seem to be
>>>> having
>>>> some problems with simply creating a new session. I'm not sure exactly
>>>> what
>>>> the problems are (perhaps Grails or some other part of my framework has
>>>> manipulated the session in some way the gets lost when the session is
>>>> stopped.)
>>>>
>>>> Anyway, the more I think about it the more I think this approach is
>>>> really
>>>> taking a very long way around. Why not add a parameter to
>>>> Subject.logout()
>>>> that gets passed to (Default) SecurityManager so that
>>>> DefaultSecurityManager.rememberMeLogout() isn't called? Would this
>>>> work? It
>>>> seems much cleaner and direct than trying to kill and create a session
>>>> because we don't want the subject to be remembered.
>>>>
>>>> Thanks,
>>>>
>>>> Brad
>>>>
>>>>
>>>> Brad Whitaker wrot
>>>>
>>>> I'll let you continue the implementation discussion on the other
>>>> thread,
>>>>
>>>>
>>>>> but will add my two cents from a user's perspective:
>>>>>
>>>>> I'd like to see a method on the Subject that can logout the subject out
>>>>> but preserves "remember me". This could be accomplished with either a
>>>>> new
>>>>> method or a new parameter to logout(). Subject just seems like the
>>>>> right
>>>>> place to put this functionality (although I don't understand the
>>>>> implementation issues).
>>>>>
>>>>> 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 <jh...@fastmail.fm>
>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>
>>
>
>
Re: jsecurity-user: is it possible to force a discard a "remember
me" cookie?
Posted by Brad Whitaker <br...@agilemark.com>.
Les is correct that my first and second questions were exact opposites.
Jeremy answered my first question and the solution is completely
satisfactory for handling the weird condition that occurs only in devel
mode.
My second question came up when I realized what Subject.logout() is
discarding the "remember me" cookie as a side effect of logout. I wanted
a way to have the user "de-authenticate" without being forgotten. Upon
further review I guess it makes little sense to do this. So I withdraw
my request and apologize for the all the noise.
Thanks,
Brad
Jeremy Haile wrote:
> Brad,
>
> My main concern is altering the Subject interface for what may be a rare
> case and one that has a pretty easy workaround (just invalidate the
> session). I think that usually when a user logs out, they expect their
> remembered identity to be logged out as well. Currently, logout() marks
> the user unauthenticated, forgets their remembered identity, and ends
> their session - which is the behavior of most web apps that I'm familiar
> with.
>
> As Les mentioned, I'd love to hear more detail about your use case. If
> this seems to be a common case, then we could definitely consider adding
> the functionality to Subject.
>
> Jeremy
>
> On Thu, 31 Jul 2008 19:29:32 -0400, "Les Hazlewood" <le...@hazlewood.com>
> said:
>
>> Hi Brad,
>>
>> Could you please summarize the exact end result that you're trying to
>> achieve? I'm a tad confused at the moment. Your first question was to
>> see
>> if the remembered identity could be explicitly forgotten and/or ignored
>> after a fresh DB install during development. The second question asks if
>> you can logout a user but still retain the remember me identity, which is
>> almost an exact opposite of the first question :)
>>
>> Perhaps if you could explain exactly what you're trying to achieve, then
>> it
>> would be easier for me to think of how this might apply to our API.
>>
>> I'm a little hesitant to alter the Subject interface (at least at the
>> moment) because this is one of the very core interfaces of JSecurity,
>> used
>> everywhere by everyone (in JSecurity's 'guts' as well as end-users. I
>> just
>> try to think long and hard before doing these kinds of things.
>>
>> So, in getting clarification, I might be able to say "Oh, this is easy,
>> we
>> could modify some behavior in the SecurityManager implementation to
>> achieve
>> what you want" (template methods or whatever), which would be much more
>> digestible than changing such a critical API interface.
>>
>> I'm definitely willing to try to make your life easy, I'm just confused
>> at
>> the moment by the polarity of the two questions ;)
>>
>> Thanks!
>>
>> Les
>>
>> On Thu, Jul 31, 2008 at 6:03 PM, Brad Whitaker <br...@agilemark.com>
>> wrote:
>>
>>
>>> I've been trying to use subject.getSession().stop() but I seem to be having
>>> some problems with simply creating a new session. I'm not sure exactly what
>>> the problems are (perhaps Grails or some other part of my framework has
>>> manipulated the session in some way the gets lost when the session is
>>> stopped.)
>>>
>>> Anyway, the more I think about it the more I think this approach is really
>>> taking a very long way around. Why not add a parameter to Subject.logout()
>>> that gets passed to (Default) SecurityManager so that
>>> DefaultSecurityManager.rememberMeLogout() isn't called? Would this work? It
>>> seems much cleaner and direct than trying to kill and create a session
>>> because we don't want the subject to be remembered.
>>>
>>> Thanks,
>>>
>>> Brad
>>>
>>>
>>> Brad Whitaker wrot
>>>
>>> I'll let you continue the implementation discussion on the other thread,
>>>
>>>> but will add my two cents from a user's perspective:
>>>>
>>>> I'd like to see a method on the Subject that can logout the subject out
>>>> but preserves "remember me". This could be accomplished with either a new
>>>> method or a new parameter to logout(). Subject just seems like the right
>>>> place to put this functionality (although I don't understand the
>>>> implementation issues).
>>>>
>>>> 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 <jh...@fastmail.fm>
>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>>
>>>>
>>>>
>
>
Re: jsecurity-user: is it possible to force a discard a "remember me"
cookie?
Posted by Jeremy Haile <jh...@fastmail.fm>.
Brad,
My main concern is altering the Subject interface for what may be a rare
case and one that has a pretty easy workaround (just invalidate the
session). I think that usually when a user logs out, they expect their
remembered identity to be logged out as well. Currently, logout() marks
the user unauthenticated, forgets their remembered identity, and ends
their session - which is the behavior of most web apps that I'm familiar
with.
As Les mentioned, I'd love to hear more detail about your use case. If
this seems to be a common case, then we could definitely consider adding
the functionality to Subject.
Jeremy
On Thu, 31 Jul 2008 19:29:32 -0400, "Les Hazlewood" <le...@hazlewood.com>
said:
> Hi Brad,
>
> Could you please summarize the exact end result that you're trying to
> achieve? I'm a tad confused at the moment. Your first question was to
> see
> if the remembered identity could be explicitly forgotten and/or ignored
> after a fresh DB install during development. The second question asks if
> you can logout a user but still retain the remember me identity, which is
> almost an exact opposite of the first question :)
>
> Perhaps if you could explain exactly what you're trying to achieve, then
> it
> would be easier for me to think of how this might apply to our API.
>
> I'm a little hesitant to alter the Subject interface (at least at the
> moment) because this is one of the very core interfaces of JSecurity,
> used
> everywhere by everyone (in JSecurity's 'guts' as well as end-users. I
> just
> try to think long and hard before doing these kinds of things.
>
> So, in getting clarification, I might be able to say "Oh, this is easy,
> we
> could modify some behavior in the SecurityManager implementation to
> achieve
> what you want" (template methods or whatever), which would be much more
> digestible than changing such a critical API interface.
>
> I'm definitely willing to try to make your life easy, I'm just confused
> at
> the moment by the polarity of the two questions ;)
>
> Thanks!
>
> Les
>
> On Thu, Jul 31, 2008 at 6:03 PM, Brad Whitaker <br...@agilemark.com>
> wrote:
>
> > I've been trying to use subject.getSession().stop() but I seem to be having
> > some problems with simply creating a new session. I'm not sure exactly what
> > the problems are (perhaps Grails or some other part of my framework has
> > manipulated the session in some way the gets lost when the session is
> > stopped.)
> >
> > Anyway, the more I think about it the more I think this approach is really
> > taking a very long way around. Why not add a parameter to Subject.logout()
> > that gets passed to (Default) SecurityManager so that
> > DefaultSecurityManager.rememberMeLogout() isn't called? Would this work? It
> > seems much cleaner and direct than trying to kill and create a session
> > because we don't want the subject to be remembered.
> >
> > Thanks,
> >
> > Brad
> >
> >
> > Brad Whitaker wrot
> >
> > I'll let you continue the implementation discussion on the other thread,
> >> but will add my two cents from a user's perspective:
> >>
> >> I'd like to see a method on the Subject that can logout the subject out
> >> but preserves "remember me". This could be accomplished with either a new
> >> method or a new parameter to logout(). Subject just seems like the right
> >> place to put this functionality (although I don't understand the
> >> implementation issues).
> >>
> >> 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 <jh...@fastmail.fm>
> >>> 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
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >
Re: jsecurity-user: is it possible to force a discard a "remember me" cookie?
Posted by Les Hazlewood <le...@hazlewood.com>.
Hi Brad,
Could you please summarize the exact end result that you're trying to
achieve? I'm a tad confused at the moment. Your first question was to see
if the remembered identity could be explicitly forgotten and/or ignored
after a fresh DB install during development. The second question asks if
you can logout a user but still retain the remember me identity, which is
almost an exact opposite of the first question :)
Perhaps if you could explain exactly what you're trying to achieve, then it
would be easier for me to think of how this might apply to our API.
I'm a little hesitant to alter the Subject interface (at least at the
moment) because this is one of the very core interfaces of JSecurity, used
everywhere by everyone (in JSecurity's 'guts' as well as end-users. I just
try to think long and hard before doing these kinds of things.
So, in getting clarification, I might be able to say "Oh, this is easy, we
could modify some behavior in the SecurityManager implementation to achieve
what you want" (template methods or whatever), which would be much more
digestible than changing such a critical API interface.
I'm definitely willing to try to make your life easy, I'm just confused at
the moment by the polarity of the two questions ;)
Thanks!
Les
On Thu, Jul 31, 2008 at 6:03 PM, Brad Whitaker <br...@agilemark.com> wrote:
> I've been trying to use subject.getSession().stop() but I seem to be having
> some problems with simply creating a new session. I'm not sure exactly what
> the problems are (perhaps Grails or some other part of my framework has
> manipulated the session in some way the gets lost when the session is
> stopped.)
>
> Anyway, the more I think about it the more I think this approach is really
> taking a very long way around. Why not add a parameter to Subject.logout()
> that gets passed to (Default) SecurityManager so that
> DefaultSecurityManager.rememberMeLogout() isn't called? Would this work? It
> seems much cleaner and direct than trying to kill and create a session
> because we don't want the subject to be remembered.
>
> Thanks,
>
> Brad
>
>
> Brad Whitaker wrot
>
> I'll let you continue the implementation discussion on the other thread,
>> but will add my two cents from a user's perspective:
>>
>> I'd like to see a method on the Subject that can logout the subject out
>> but preserves "remember me". This could be accomplished with either a new
>> method or a new parameter to logout(). Subject just seems like the right
>> place to put this functionality (although I don't understand the
>> implementation issues).
>>
>> 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 <jh...@fastmail.fm>
>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>
>>
>>
>>
>
Re: jsecurity-user: is it possible to force a discard a "remember
me" cookie?
Posted by Brad Whitaker <br...@agilemark.com>.
I've been trying to use subject.getSession().stop() but I seem to be
having some problems with simply creating a new session. I'm not sure
exactly what the problems are (perhaps Grails or some other part of my
framework has manipulated the session in some way the gets lost when the
session is stopped.)
Anyway, the more I think about it the more I think this approach is
really taking a very long way around. Why not add a parameter to
Subject.logout() that gets passed to (Default) SecurityManager so that
DefaultSecurityManager.rememberMeLogout() isn't called? Would this
work? It seems much cleaner and direct than trying to kill and create a
session because we don't want the subject to be remembered.
Thanks,
Brad
Brad Whitaker wrot
> I'll let you continue the implementation discussion on the other
> thread, but will add my two cents from a user's perspective:
>
> I'd like to see a method on the Subject that can logout the subject
> out but preserves "remember me". This could be accomplished with
> either a new method or a new parameter to logout(). Subject just seems
> like the right place to put this functionality (although I don't
> understand the implementation issues).
>
> 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 <jh...@fastmail.fm>
>> 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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>
>>
>
>
>
Re: jsecurity-user: is it possible to force a discard a "remember
me" cookie?
Posted by Brad Whitaker <br...@agilemark.com>.
I'll let you continue the implementation discussion on the other thread,
but will add my two cents from a user's perspective:
I'd like to see a method on the Subject that can logout the subject out
but preserves "remember me". This could be accomplished with either a
new method or a new parameter to logout(). Subject just seems like the
right place to put this functionality (although I don't understand the
implementation issues).
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 <jh...@fastmail.fm> 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
>>>>>
>>>>>
>>>>
>>>>
>
>
Re: jsecurity-user: is it possible to force a discard a "remember me" cookie?
Posted by Les Hazlewood <le...@hazlewood.com>.
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 <jh...@fastmail.fm> 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
>>>>
>>>
>>>
>>>
>>
>
Re: jsecurity-user: is it possible to force a discard a "remember
me" cookie?
Posted by Brad Whitaker <br...@agilemark.com>.
That sounds like it will work for me -- thanks!
Jeremy Haile 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
>>>
>>>
>>
>
>
Re: jsecurity-user: is it possible to force a discard a "remember me" cookie?
Posted by Jeremy Haile <jh...@fastmail.fm>.
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
>>
>>
>
Re: jsecurity-user: is it possible to force a discard a "remember
me" cookie?
Posted by Brad Whitaker <br...@agilemark.com>.
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
>
>
Re: jsecurity-user: is it possible to force a discard a "remember me" cookie?
Posted by Jeremy Haile <jh...@fastmail.fm>.
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