You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by Mike K <mk...@semanticresearch.com> on 2011/03/16 00:18:38 UTC

How to not "touch" session

When using Shiro inside a Servlet Container is there a way to disable
"touching" the session for certain method calls. 
I would like to allow polling for logged in state (not too frequent) without
causing that to refresh the session.

--
View this message in context: http://shiro-user.582556.n2.nabble.com/How-to-not-touch-session-tp6174681p6174681.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: How to not "touch" session

Posted by Michael Kogan <mk...@semanticresearch.com>.
Thanks Les, 
Sorry I have taken too long to respond - your message did not match my Shiro filter.
I am using Shiro native sessions.
I have contemplated adding a robot header to requests indicating that they are not intended to refresh the session, and customize the filter.
However, that really puts too much power in the hands of the client. What would be preferable is the ability to "untouch" the session in the  method that is being invoked, either manually or through annotation.

Regards,

Mike.


On Mar 17, 2011, at 7:17 PM, Les Hazlewood wrote:

> Hi Mike,
> 
> There is currently no great way to customize this other than to
> override AbstractShiroFilter's 'updateSessionLastAccessTime' method
> and perform the same logic based on request-specific logic.  The
> reason this is the case is that because the behavior is according to
> the Servlet Specification, a session's lastAccessedTimestamp is always
> updated when the container receives a request associated with an
> established session (the second sentence is key):
> 
> SRV.7.6 Last Accessed Times
> The getLastAccessedTime method of the HttpSession interface allows a servlet to
> determine the last time the session was accessed before the current request. The
> session is considered to be accessed when a request that is part of
> the session is first
> handled by the servlet container.
> 
> So, because the servlet spec mandates this, we could only make this
> customizable when using Shiro's native sessions - not the default
> servlet container sessions (since those are outside of Shiro's
> control).  Are you using native sessions?
> 
> If using Shiro's native sessions, we can open a Jira issue to enable
> this extra configuration capability, but I guess I should first ask:
> how should this be supported?
> 
> That is, do you want to exclude timstamp update based on a specific
> request path?  or based on some other request-specific criteria?
> 
> Anyone's feedback is welcome!
> 
> -- 
> Les Hazlewood
> Founder, Katasoft, Inc.
> Application Security Products & Professional Apache Shiro Support and Training:
> http://www.katasoft.com


Re: How to not "touch" session

Posted by Les Hazlewood <lh...@apache.org>.
Hi Mike,

There is currently no great way to customize this other than to
override AbstractShiroFilter's 'updateSessionLastAccessTime' method
and perform the same logic based on request-specific logic.  The
reason this is the case is that because the behavior is according to
the Servlet Specification, a session's lastAccessedTimestamp is always
updated when the container receives a request associated with an
established session (the second sentence is key):

SRV.7.6 Last Accessed Times
The getLastAccessedTime method of the HttpSession interface allows a servlet to
determine the last time the session was accessed before the current request. The
session is considered to be accessed when a request that is part of
the session is first
handled by the servlet container.

So, because the servlet spec mandates this, we could only make this
customizable when using Shiro's native sessions - not the default
servlet container sessions (since those are outside of Shiro's
control).  Are you using native sessions?

If using Shiro's native sessions, we can open a Jira issue to enable
this extra configuration capability, but I guess I should first ask:
how should this be supported?

That is, do you want to exclude timstamp update based on a specific
request path?  or based on some other request-specific criteria?

Anyone's feedback is welcome!

-- 
Les Hazlewood
Founder, Katasoft, Inc.
Application Security Products & Professional Apache Shiro Support and Training:
http://www.katasoft.com