Hi Les, Thanks for the info. This helped me to understand that setting the timeout isn't an explicit "this will expire at this time" statement, but instead setting the max idle duration that will be reset with every request (that explains my incorrect getLastAccessTime() in my question).
Two questions related to your recommendations: 1) Could I not use the recommendation for servlet-based sessions with native sessions as well? Although I'll have to dig around in the API to figure it out, it seems like there would be a way to grab the Session from within a Filter and change it. I'm thinking something like: SecurityUtils.getSubject().getSession().setTimeout(x); Possibly a lot of overhead with this approach because it would happen with every request, but seems straightforward. For this reason alone, though, I don't really want to do this. 2) For the SessionListener recommendation, I only partially understand the comment re: using the ThreadLocal variable. I understand that it has to be accessible from within the SessionListener, but you don't mean anything more that that, correct? Based on what I can see, there isn't a way to get at what the context path is for the http request from the listener, since that's disconnected from the actual request itself. I was thinking I could set a session attribute that I could access in this listener, but I think that would require me touching the same method in SessionManager as the other approach anyway because it would have to be there at the very beginning to be available to the onStart() method. Even if neither of the above work, though, you were kind enough to provide we with nearly all the code for my subclassed DefaultWebSessionManager if I need to go there, so thank you! Mike -- View this message in context: http://shiro-user.582556.n2.nabble.com/Support-for-multiple-session-timeouts-tp7577708p7577710.html Sent from the Shiro User mailing list archive at Nabble.com.
