Hi Les
Les Hazlewood-2 wrote > It appears that MyFaces is trying to use the Session after it has been > closed - the renderView method calls AbstractThreadSafeAttributeMap > which in turn tries to use the Session. It is almost as if an HTTP > redirect is _not_ happening. Unfortunately I've got myself in to a bit of a mess whilst playing with the code in my logout backing bean and taking the traces to troubleshoot the problem. It seems the trace I took yesterday was done whilst the redirect line of code was commented out. Nevertheless even with the redirect reinstated the exception "java.lang.IllegalStateException: org.apache.shiro.session.UnknownSessionException" is still thrown, and the only difference is the section "Error Rendering View[/app/index.xhtml]" in the trace doesn't happen and instead goes straight to "An exception was thrown by one of the service methods of the servlet [Faces Servlet] in application [Test-EAR]. Exception created : [java.lang.IllegalStateException: org.apache.shiro.session.UnknownSessionException". Sorry for any confusion caused by this. Les Hazlewood-2 wrote > Does Faces.redirect actually execute a > 302 redirect? Or does it do something JSF-ish instead? Faces.redirect is a method provided by a library called Omnifaces. The Faces.redirect method is wrapper around the JSF redirect method to reduce the amount of boilerplate code in the backing bean. The JavaDoc for this method says it "Sends a temporary (302) redirect to the given URL" Les Hazlewood-2 wrote > As to your question about Shiro's behavior vs your Servlet container's > behavior: Shiro's web support attempts to acquire a request's > referenced session at the beginning of a request chain (i.e. top of > the filter stack). If the session is expired or non-existent, then > the SessionException is ignored, with the expectation that a new > Session will be created later in the request if it is needed. This > effectively eliminates downstream code from worrying about > SessionExceptions. > > However, Shiro currently does _not_ swallow these exceptions if the > Session is terminated and that same session is attempted to be used > again. Maybe a less intrusive behavior would be to only throw the > SessionException if the response hasn't yet been committed (because if > it had been committed, there wouldn't be a way to set the session ID > cookie, and the session couldn't be reliably referenced again, > indicating an error scenario). > > But I wonder if this proposed behavior might be less ideal than > Shiro's current behavior: clearly you have logged out the user, > indicating the user is done using the application. Doesn't it seem > odd to allow a new session to be created and populated with data if > that session will (probably) never be used again? Why should > infrastructure (MyFaces) be allowed to create new sessions when you've > indicated that the user is done using the app? > > Current servlet containers that allow this behavior allow for > potentially very inefficient use of resources (many unused sessions > could be created, eating up session storage memory and/or disk). > > I'm curious as to your thoughts and what you'd like to see though! My initial thoughts are that if the session has been stopped then any subsequent SessionException should be swallowed as I've decided that session is no longer required and subsequently the user will be redirected to the login page where they will acquire a new session. However on further reflection this does seem like it would just be treating the symptom rather than the underlying cause. Maybe a compromise would a parameter which controls whether these exceptions are swallowed. I agree that it seems odd to allow MyFaces to continue using the session once the user has indicated they have finished using the app. Unfortunately I don't have a sufficiently detailed knowledge of MyFaces to understand what's happening under the covers. On one hand I think that that if the exception could be swallowed by Shiro it would solve this problem, but on the other hand I fear that the issues you highlight around inefficient use of resources could create a bigger problem in the future. Assuming that the SessionException were to be swallowed, could it be flagged in some way to be cleaned up by the session validation mechanism? Les Hazlewood-2 wrote > I do have a request that would help me greatly in trying to trace > things further though: would you be able to add the current thread ID > in the log message output? It is hard to see if this stuff is > happening in a single thread of execution or across two requests (i.e. > It is hard to see with the log output if: 1) all of this happens in a > single thread or 2) the first request calls logout and redirects, and > the second request attempts to use the stale session ID. I've captured four traces which include the thread in the output. 1. Shows the UnknownSessionException with no redirect (i.e Faces.redirect method is commented out) <http://pastebin.com/U34qy7qD> 2. Shows the UnknownSessionException with the redirect to the login page <http://pastebin.com/scWqrpAJ> 3. Shows the normal flow of events when using container managed session with no redirect <http://pastebin.com/rnrCch4J> 4. Shows the normal flow of events when using container managed session with the redirect to the login page. <http://pastebin.com/GT7tJPuH> Once again thank you for taking the time to look at this problem and sorry for any confusion caused by me commenting out the redirect. 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-tp7578804p7578830.html Sent from the Shiro User mailing list archive at Nabble.com.
