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