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
