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 >> >
