You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by Tauren Mills <ta...@groovee.com> on 2009/09/10 05:41:33 UTC
Tracking last accessed time for a user
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
Re: Tracking last accessed time for a user
Posted by Tauren Mills <yo...@gmail.com>.
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 <lh...@apache.org> 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 <yo...@gmail.com> 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 <lh...@apache.org> 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 <lh...@apache.org> 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
>>>> <ka...@gmail.com> 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<ta...@groovee.com> 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
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Tracking last accessed time for a user
Posted by Les Hazlewood <lh...@apache.org>.
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 <yo...@gmail.com> 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 <lh...@apache.org> 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 <lh...@apache.org> 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
>>> <ka...@gmail.com> 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<ta...@groovee.com> 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
>>>>>
>>>>
>>>
>>
>
Re: Tracking last accessed time for a user
Posted by Tauren Mills <yo...@gmail.com>.
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 <lh...@apache.org> 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 <lh...@apache.org> 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
>> <ka...@gmail.com> 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<ta...@groovee.com> 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
>>>>
>>>
>>
>
Re: Tracking last accessed time for a user
Posted by Les Hazlewood <lh...@apache.org>.
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 <lh...@apache.org> 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
> <ka...@gmail.com> 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<ta...@groovee.com> 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
>>>
>>
>
Re: Tracking last accessed time for a user
Posted by Les Hazlewood <lh...@apache.org>.
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
<ka...@gmail.com> 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<ta...@groovee.com> 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
>>
>
Re: Tracking last accessed time for a user
Posted by Kalle Korhonen <ka...@gmail.com>.
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<ta...@groovee.com> 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
>