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