Hi Les
Les Hazlewood-2 wrote
> It is not possible for an exception to propagate past a catch clause
> that you have defined without you detecting it - this means something
> else (separate from your logout() call) is attempting to use a session
> without you being aware of it.
I've now stepped through most of the code being executed from the
SecurityUtils.getSubject().logout() method onwards and it indeed seems that
something else is going on. The submit method in the logout backing bean
(shown below) completes successfully, so it seems that JSF is doing
something after the logoff button has been presses and the method in the
backing bean executed which is trying use the session.
public String submit() {
try {
System.out.println("****Logging out****");
SecurityUtils.getSubject().logout();
} catch (IllegalStateException e) {
System.out.println("Do nothing");
} catch (UnknownSessionException e) {
System.out.println("Do nothing");
}
Faces.redirect("login.xhtml");
return null;
}
Les Hazlewood-2 wrote
> I've seen this happen a few times in web apps, usually due to one of 2
> cases:
> the web request.
>
> 2) subject.logout() is called after the http response has already been
> committed (body content is being rendered). Because of the way
> cookies work, it is not possible to delete the session id cookie in
> this case, so subsequent requests will have an invalid session id
> cookie and cause this exception.
Having looked at all the output generated in the server log, I've spotted
the following two entries that occur after the
"java.lang.IllegalStateException:
org.apache.shiro.session.UnknownSessionException" exception is thrown which
I think might be relevant.
com.ibm.ws.webcontainer.srt.SRTServletResponse setStatus WARNING: Cannot set
status. Response already committed.
com.ibm.ws.webcontainer.srt.SRTServletResponse addHeader SRVE8094W: WARNING:
Cannot set header. Response already committed.
Note that the above log entries only occur when using Shiro managed
sessions.
What I really don't understand is why these issues does not occur when I
allow the container to manage the session (i.e. remove sessionManager =
org.apache.shiro.web.session.mgt.DefaultWebSessionManager from the shiro.ini
file). I've been able to reproduce this problem on both WebSphere and
GlassFish so it would seem unlikely that it is the application server
causing the problem although I know they both use Tomcat for the servlet
container.
I'm really struggling to understand what's going on here and why it works
with container managed sessions but not with Shiro managed sessions.
Kind Regards
Paul
--
View this message in context:
http://shiro-user.582556.n2.nabble.com/UnknownSessionException-when-calling-logout-method-using-Shiro-s-built-in-session-management-tp7578804p7578827.html
Sent from the Shiro User mailing list archive at Nabble.com.
