You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by "Alan D. Cabrera" <li...@toolazydogs.com> on 2010/11/25 03:19:22 UTC
Logout invalidates HttpSession
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
Re: Logout invalidates HttpSession
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
"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 <li...@toolazydogs.com> 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 <li...@toolazydogs.com> 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 <li...@toolazydogs.com> 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
>
Re: Logout invalidates HttpSession
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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 <li...@toolazydogs.com> 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 <li...@toolazydogs.com> 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 <li...@toolazydogs.com> 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
Re: Logout invalidates HttpSession
Posted by Les Hazlewood <lh...@apache.org>.
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 <li...@toolazydogs.com> 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 <li...@toolazydogs.com> 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 <li...@toolazydogs.com> 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
Re: Logout invalidates HttpSession
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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 <li...@toolazydogs.com> 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 <li...@toolazydogs.com> 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
Re: Logout invalidates HttpSession
Posted by Les Hazlewood <lh...@apache.org>.
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 <li...@toolazydogs.com> 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 <li...@toolazydogs.com> 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
Re: Logout invalidates HttpSession
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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 <li...@toolazydogs.com> 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
Re: Logout invalidates HttpSession
Posted by Les Hazlewood <lh...@apache.org>.
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 <li...@toolazydogs.com> 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