As long as you're happy with that discrepancy in time, yep, that's it :) - Les
On Thu, Sep 10, 2009 at 4:26 PM, Tauren Mills <[email protected]> wrote: > Thanks guys. I knew there was probably a better way than I was > currently doing it. > > I think I'm using http sessions, isn't that the default? Here's my > spring config: > > <bean id="securityManager" > class="org.apache.shiro.web.DefaultWebSecurityManager"> > <property name="realm" ref="myRealm"/> > </bean> > > So without switching to native sessions, the best solution would be to > implement AuthenticationListener#onSuccess, right? > > Thanks again, > Tauren > > > > > On Thu, Sep 10, 2009 at 6:53 AM, Les Hazlewood <[email protected]> wrote: >> 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 >>>>> >>>> >>> >> >
