Now that I've thought about it a little more, I think the best way to retain the 'true' last access time for a user is to use Shiro's native sessions and implement a org.apache.shiro.session.SessionListener.
In the SessionListener#onStop _and_ SessionListener#onExpiration methods, you can get the last access time for the session and update the owning user's record at that time. That way you are guaranteed to have the timestamp of their last access to the system under that session - a little more accurate than their last login time. Cheers, Les On Thu, Sep 10, 2009 at 9:36 AM, Les Hazlewood <[email protected]> wrote: > Kalle's correct in that Shiro is read-only for authentication and > authorization operations. Shiro however does perform write operations > for 'native' Session management. If you are using 'native' sessions > (not the default Servlet container sessions) the SessionManager uses a > SessionDAO to perform write/update operations to retain Session state. > > However, unless you are using a relational database to persist > sessions (not recommended unless you have an enterprise cache sitting > in front of it), you can't query against the session's last access > time. > > If you want to update your own domain model as a result of > authentication operations, the recommended approach is to implement an > org.apache.shiro.authc.AuthenticationListener. > > The AuthenticationListener#onSuccess call will only be called if > credentials matching is successful and the user's identity has been > verified and guaranteed. Contrast this with updating state in your > Realm implementation - the authentication may not actually succeed, > but your data model update might occur anyway, reflecting an incorrect > state. > > In practice, if this is all done in a transaction, this usually won't > occur, since the update to the user would be rolled back when the > AuthenticationException is thrown. But for clarity and separation of > concerns, it is more 'correct' to use an AuthenticationListener if you > need to update your own data model based on authentication operations. > > Best, > > Les > > On Thu, Sep 10, 2009 at 12:54 AM, Kalle Korhonen > <[email protected]> wrote: >> Shiro doesn't rely on any persistence strategy to be available and any >> APIs are read-only, so no, Shiro doesn't keep track of these details >> automatically. How you are doing it is ok - if you want a more >> reusable and better capsulated approach, consider implementing a >> custom realm and updating the last accessed record there. >> >> Kalle >> >> >> On Wed, Sep 9, 2009 at 8:41 PM, Tauren Mills<[email protected]> wrote: >>> Currently, whenever a user logs into my system, the method >>> SecurityUtiles.getSubject().login(context) is run, followed by a >>> hibernate call that updates the user object with a new "last accessed" >>> date. >>> >>> I'm not having a problem with this, but I was just wondering if Shiro >>> is already keeping track of details like this and if there is a better >>> approach. >>> >>> Thanks, >>> Tauren >>> >> >
