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