This sounds like a great approach, and it totally reminded me that I'm using shiro native sessions, not standard web sessions. Am I correct in thinking that the suggestion Kalle made is best suited for apps that do not use native sessions and use standard HttpSessions? Although my app is web-based, wouldn't it be better to track the last accessed value from somewhere other than a filter since I'm using native sessions?
If I go this route, I'm still not sure where the best place to add my session access logic would be. I like Kalle's suggestion of only updating the datastore if a sufficiently long period of time has passed, but where would this logic go? He's suggesting it go into a filter, but with native sessions where would it go? Thanks for the ideas, Tauren On Mon, Jun 13, 2011 at 2:42 PM, Les Hazlewood <[email protected]> wrote: > I don't have much time to elaborate at the moment, but I like the > approach of using Shiro's native session mechanisms - I store the > Sessions in a data store I control that has query capabilities (write > a Shiro SessionDAO to talk to the data store). When a user logs in, I > associate their session to their user account (the session records > have a 'userId' field). This way, I can query the session data store > for all sessions associated with a particular user including the one > they're currently using... > > 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 >
