"myopic" was a poor choice of words, sorry. What I meant to say is that the HTTP session is likely to be used by other non-Shiro frameworks. The assumption that only Shiro is using it is rather presumptuous and having Shiro dictate the semantics of what a logout means with regards to this shared resource is even worse.
Just my opinion. Regards, Alan On Nov 25, 2010, at 9:59 AM, Alan D. Cabrera wrote: > I can see the value of deleting the virtual Shiro session. Deleting the HTTP > session seems a bit myopic; security is just one facet of a web application. > > Regards, > Alan > > > On Nov 25, 2010, at 9:20 AM, Les Hazlewood wrote: > >> Because that is what nearly everyone wants for their applications. I >> think most people would consider it very unnatural to *not* invalidate >> the session upon logout. That is, 'logout' means "I'm completely done >> using this application - release all of my resources and >> associations". The session is clearly the most common mechanism for >> this so it generally should always be released. >> >> I'm not aware of any reason why you would ever want a user's session >> to still remain valid after they've explicitly told the application to >> *not* consider them active any longer. >> >> And just for clarification, invalidation doesn't necessarily mean >> deletion. It just means that it can't be used anymore (which I would >> argue should always be the case when a user logs out). Shiro's >> default behavior is to delete sessions as they are invalidated because >> that's what most people want, it mirrors a servlet container's >> behavior and it prevents session orphans. >> >> Now, if you want to keep a session around after it has been >> invalidated (perhaps because you want to run queries associated with >> it or something for user reporting or whatever), you must first be >> using Shiro's native sessions and then tell the SessionManager to not >> delete them (e.g. in shiro.ini): >> >> securityManager.sessionManager.deleteInvalidSessions = false >> >> Per tha setDeleteInvalidSessions JavaDoc however, you definitely only >> want to set it to false if you have some other mechanism to delete >> sessions based on some other criteria so orphans and/or invalidated >> sessions don't fill up your session data store (e.g. a quartz job that >> periodically deletes session records according to some business rule). >> >> Best, >> >> Les >> >> On Thu, Nov 25, 2010 at 8:18 AM, Alan D. Cabrera <[email protected]> >> wrote: >>> Great. I also see that there is a listener mechanism which would allow >>> others to also perform cleanup operations on logout so there should be no >>> one officially relying on the session being invalidated to released >>> anything that was attached to it. >>> >>> I wonder, with that said, why do we bother invalidating the HTTP session? >>> Seems kind of intrusive. >>> >>> >>> Regards, >>> Alan >>> >>> On Nov 24, 2010, at 7:43 PM, Les Hazlewood wrote: >>> >>>> I'm not sure what you mean by "session info 'leaking'". >>>> >>>> The #unbind(Subject) call just above the finally block is the >>>> mechanism that disassociates state that would allow further requests >>>> to be associated with the Subject. Once that method is called, Shiro >>>> would consider the session 'anonymous'. >>>> >>>> Other state may still exist in the session beyond the keys used for >>>> Subject association. The ones that I can find via an IntelliJ 'find >>>> usages' search: >>>> >>>> - The HttpServletSession implementation uses two String constants as >>>> attribute keys in its implementation >>>> - The DelegatingSubject's 'runAs' implementation uses a session >>>> attribute to remember the runAs stack. >>>> - The 'redirect to login and the redirect to the current page' feature >>>> uses a 'saved request' session attribute. >>>> >>>> Other than those 3, I can't see any other usages of session attribute >>>> data. The logout method however only clears the session attributes >>>> that are used for Subject association - not any of those other >>>> possible 3 (or any other that may be used by Shiro in the future). >>>> >>>> Regards, >>>> >>>> Les >>>> >>>> On Wed, Nov 24, 2010 at 7:19 PM, Alan D. Cabrera <[email protected]> >>>> wrote: >>>>> I won't have any Shiro session info "leaking" if I do this will I? >>>>> >>>>> >>>>> Regards, >>>>> Alan >>>>> >>>>> On Nov 24, 2010, at 6:39 PM, Les Hazlewood wrote: >>>>> >>>>>> Hi Alan, >>>>>> >>>>>> You'll need to override the >>>>>> org.apache.shiro.mgt.DefaultSecurityManager#logout(Subject) >>>>>> implementation to not execute the last 'finally' block. >>>>>> >>>>>> HTH, >>>>>> >>>>>> Les >>>>>> >>>>>> On Wed, Nov 24, 2010 at 6:19 PM, Alan D. Cabrera <[email protected]> >>>>>> wrote: >>>>>>> Logging out invalidates my HttpSession. I would prefer that it only >>>>>>> removes shiro stuff. What do I need to override to get this behavior? >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Alan >
