How about this: write a filter that keeps track of most recent users
(e.g. an LRUMap) and when last access time was last stored
persistently, compares that timestamp to
HttpSession.getLastAccessedTime() and re-writes to database if
sufficiently long time has passed (e.g. > 15 mins) to keep it
performing well. Also update last access time on on session expiration
(from SessionListener). I wouldn't try to tie this too tightly with
your security implementation (request.getRemoteUser() seems to be all
you need if you want to track authenticated users only).

Kalle


On Tue, Jun 7, 2011 at 4:44 PM, Tauren Mills <[email protected]> wrote:
> Les,
>
> Thanks for the help. I voted for SHIRO-286. However, now I have a few
> more questions.
>
> How would you keep the database up-to-date with current access times?
> Without a SessionListener.onAccess() method or something similar, the
> only time the database will get updated is when the user logs in, logs
> out, or their session times out. What about all of the time
> in-between? Some users can spend all day using the site, but never hit
> my 30 minute session timeout.
>
> Also, I'm concerned that code to update the database with the last
> accessed date is going to be scattered all over. It would be nice if
> it could all be done inside listener methods, but I don't see how that
> is possible for remember me cases:
>
> When logging in:
> * AuthenticationListener.onSuccess()
> * OR AuthorizingRealm.doGetAuthenticationInfo()
>
> When being remembered:
> * CookieRememberMeManager.getRememberedPrincipals()
> * OR ???Listener???
>
> When logging out:
> * AuthenticationListener.onLogout()
>
> When session expiring:
> * SessionListener.onExpiration()
> * OR? SessionListener.onStop()
>
> When session is accessed by subject:
> * ???
>
> If you were implementing this, where would you put the code to update
> the database and keep track of last accessed dates?
>
> Note that in reality, I don't need exact last accessed dates, but I
> need them with at least 30 minutes of accuracy. My UI displays this
> information from a hibernate query, so it is probably easiest to
> update the database regularly instead of combining the hibernate query
> results with shiro's session store information. It would get messy to
> go through the result set, check if each user has an active shiro
> session, and update the output to show that user's
> session.getLastAccessTime.
>
> Thanks,
> Tauren
>
>
>
> On Mon, Jun 6, 2011 at 2:54 PM, Les Hazlewood <[email protected]> wrote:
>> Hi Tauren,
>>
>>> How do I best go about finding and saving the last accessed date? Are
>>> all of the following statements accurate?
>>>
>>> * SessionListener.onStart() happens when a session starts, but it
>>> doesn't yet know WHO started that session. So it really doesn't help
>>> me.
>>
>> Correct - that just lets you know that a session has been started, but
>> a user isn't associated at that point.
>>
>>> * SessionListener.onStop() and onExpiration() could be used to save
>>> the last accessed time to the Member's table.
>>
>> Correct, this is probably the best approach since you can call
>> session.getLastAccessTime during one of those methods.  This sounds
>> like the best approach.
>>
>>> * AuthenticationListener.onSuccess() could be used to save the time a
>>> user authenticates, but this doesn't help for rememberme logins.
>>
>> Correct - AuthenticationListeners are only triggered on
>> authentication.  RememberMe isn't valid authentication.
>>
>>> * AuthenticationListener.onLogout() could be used to save the time a
>>> user logs out, but won't help for sessions that time out.
>>
>> Correct.
>>
>>> * Should there be a SessionListener.onUserAssociated() method? Les
>>> suggested I add a Jira for this, but that was long ago. Is there an
>>> alternative solution now, or does this still make sense to add?
>>
>> I think it might be better to represent this in the form of a
>> SubjectListener: https://issues.apache.org/jira/browse/SHIRO-286
>>
>> Please vote for it if you'd like it implemented sooner rather than
>> later (While I can't speak for other Shiro devs, I personally pay
>> attention to the vote count as an indicator of community need).
>>
>> HTH,
>>
>> --
>> Les Hazlewood
>> CTO, Katasoft | http://www.katasoft.com | 888.391.5282
>> twitter: http://twitter.com/lhazlewood
>> katasoft blog: http://www.katasoft.com/blogs/lhazlewood
>> personal blog: http://leshazlewood.com
>>
>

Reply via email to