Yeah, I see your point. But for my use case, I don't really need to know exactly the last access, just the last login is fine. Thanks for the help!
Tauren On Thu, Sep 10, 2009 at 3:21 PM, Les Hazlewood <[email protected]> wrote: > 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 >>>>>> >>>>> >>>> >>> >> >
