If you get the chance to have a look at this some time, Les, it would be appreciated.
The good news in the meantime, though, is that I have come up with a simple workaround which appears to do the job of effectively logging an authenticated user out without triggering the UnknownSessionException. In my signout method, instead of calling SecurityUtils.getSubject().logout(), I simply delete all the existing session attributes (loop through session.getAttributeNames()), which leaves the session 'empty' rather than invalidating it. This means that whatever it is further up the filter chain which is flipping out because it can't find the session identified in the request cookie will be happy - the session is there, but no longer contains the authentication information so that any further request will cause a redirect to the login page again. I have chosen to remove all session attributes, as opposed to just the ones associated with authentication, which appear to be these two: org.apache.shiro.subject.support.DefaultSubjectContext_AUTHENTICATED_SESSION_KEY org.apache.shiro.subject.support.DefaultSubjectContext_PRINCIPALS_SESSION_KEY That's because in this app, there are no actions which do not require a user to be logged in, so it makes sense to clear out as much memory as possible when the user logs out. If anyone can see any obvious pitfalls with this approach, please let me know... -- View this message in context: http://shiro-user.582556.n2.nabble.com/What-might-cause-an-UnknownSessionException-tp7578179p7578202.html Sent from the Shiro User mailing list archive at Nabble.com.
