Hi,
I am developing the authentication and session management process for a
micro services type restful web platform with a single page web application
- I am only implementing the session cache as this is the only type of cache
I need (using the session ID's for all the restful request's following log
in).
According to the "Session.touch()" method documentation - I shouldn't call
for it's use explicitly (as it will happen automatically), but digging
through the code I had seen that touch only occurs if the session is
automatically identified by the Subject's cache (assuming it is
implemented).
My questions are:
1. Is this the way the code is intended to work? and if so - why is the
touch method documented without "Session ID" type authentication mentioned
as an exception?
2. Assuming the answer to the above question is that the "touch()"
documentation presumes a Subject's cache - Why isn't explicitly stated that
this the assumed implementation, and all other uses are not documented (an
option to use the session ID is well documented).
3. How would you advice me to handle that sort of "touch" use? According to
your understanding of the Shiro correct logical flow (I just though about
putting it after creating a subject from the session ID - via builder - and
before binding it to the current thread).
This is the method documentation:
*org.apache.shiro.session.Session
public abstract void touch()
throws org.apache.shiro.session.InvalidSessionException
Explicitly updates the lastAccessTime of this session to the current time
when this method is invoked. This method can be used to ensure a session
does not time out.
Most programmers won't use this method directly and will instead rely on the
last access time to be updated automatically as a result of an incoming web
request or remote procedure call/method invocation.
However, this method is particularly useful when supporting rich-client
applications such as Java Web Start appp, Java or Flash applets, etc.
Although rare, it is possible in a rich-client environment that a user
continuously interacts with the client-side application without a
server-side method call ever being invoked. If this happens over a long
enough period of time, the user's server-side session could time-out. Again,
such cases are rare since most rich-clients frequently require server-side
method invocations.
In this example though, the user's session might still be considered valid
because the user is actively "using" the application, just not communicating
with the server. But because no server-side method calls are invoked, there
is no way for the server to know if the user is sitting idle or not, so it
must assume so to maintain session integrity. This touch() method could be
invoked by the rich-client application code during those times to ensure
that the next time a server-side method is invoked, the invocation will not
throw an ExpiredSessionException. In short terms, it could be used
periodically to ensure a session does not time out.
How often this rich-client "maintenance" might occur is entirely dependent
upon the application and would be based on variables such as session timeout
configuration, usage characteristics of the client application, network
utilization and application server performance.
Throws:
InvalidSessionException - if this session has stopped or expired prior to
calling this method.*
Thanks in advance.
--
View this message in context:
http://shiro-user.582556.n2.nabble.com/Auto-session-touch-with-only-session-cache-tp7580401.html
Sent from the Shiro User mailing list archive at Nabble.com.
