Re: Session Cookie Remains after Tapestry Security Logout
On Sun, Nov 2, 2014 at 4:41 PM, Harry Zhou superha...@gmail.com wrote: The user is indeed logged out, and the session is indeed invalidated. Everything seems to work fine. 3. The Issue Upon closer inspection, I noticed that the session cookie created by user during login is still in the browser after logout. The browser repeatedly requests the session with the JSESSIONID: g3xfcskjnvf from the server, which has already been invalidated. Sure enough, the server stderrout log shows the following (trimmed for clarity) for each request made by the user after logout: INFO org.codehaus.wadi.core.contextualiser.HybridRelocater - Unknown session [g3xfcskjnvf] ERROR org.codehaus.wadi.core.manager.StandardManager - Could not acquire session [g3xfcskjnvf] Is it normal that the session cookie is not removed (by setting maxAge to 0, etc.) after the session is invalidated on the server side? If not, did I make a mistake in my way of logging the user out that causes the cookie to remain? First of all, requesting an invalid session should not have been logged as an error - it's a completely normal for a web application - a WARN or simply DEBUG would have suited much better (you could open an issue with Wadi on that). Anyway, tapestry-security doesn't explicitly remove JSESSIONID cookie on logout. It just invalidates the session and removes the rememberMe cookie. I didn't see that you are manually removing the JSESSIONID cookie anywhere in your code. If you are and it doesn't work, the headers must be rewritten after the fact. Whether it should be done automatically by the servlet implementation, I'm actually not sure if the spec says anything about it. We could check that out and if the behavior is left open, it'd be simple to add that as an enhancement to tapestry-security. Kalle
Re: Session Cookie Remains after Tapestry Security Logout
Kalle, Thank you so much for the quick reply, based on which we have done the following: 1. We surveyed several Tapestry sites (including the hotelbooking demo app) and confirmed that leaving the cookie after session invalidation is expected. 2. We then double confirmed that the leftover cookie is indeed the cause of server-side exception reporting -- as soon as the cookie is manually removed or re-issued by the server (as the result of a persistent page field, etc.), the server stops complaining. 3. We then decided that the issue was with the client's server environment, which ran Jetty 6, and confirmed with the client that it was an arbitrary choice. They provided a new Jetty 9 environment, under which we deployed the application, and the exceptions went away! So all is good! Thanks Kalle. Best, Harry On Mon, Nov 3, 2014 at 12:42 PM, Kalle Korhonen kalle.o.korho...@gmail.com wrote: On Sun, Nov 2, 2014 at 4:41 PM, Harry Zhou superha...@gmail.com wrote: The user is indeed logged out, and the session is indeed invalidated. Everything seems to work fine. 3. The Issue Upon closer inspection, I noticed that the session cookie created by user during login is still in the browser after logout. The browser repeatedly requests the session with the JSESSIONID: g3xfcskjnvf from the server, which has already been invalidated. Sure enough, the server stderrout log shows the following (trimmed for clarity) for each request made by the user after logout: INFO org.codehaus.wadi.core.contextualiser.HybridRelocater - Unknown session [g3xfcskjnvf] ERROR org.codehaus.wadi.core.manager.StandardManager - Could not acquire session [g3xfcskjnvf] Is it normal that the session cookie is not removed (by setting maxAge to 0, etc.) after the session is invalidated on the server side? If not, did I make a mistake in my way of logging the user out that causes the cookie to remain? First of all, requesting an invalid session should not have been logged as an error - it's a completely normal for a web application - a WARN or simply DEBUG would have suited much better (you could open an issue with Wadi on that). Anyway, tapestry-security doesn't explicitly remove JSESSIONID cookie on logout. It just invalidates the session and removes the rememberMe cookie. I didn't see that you are manually removing the JSESSIONID cookie anywhere in your code. If you are and it doesn't work, the headers must be rewritten after the fact. Whether it should be done automatically by the servlet implementation, I'm actually not sure if the spec says anything about it. We could check that out and if the behavior is left open, it'd be simple to add that as an enhancement to tapestry-security. Kalle -- Best Regards Harry Zhou
Re: Session Cookie Remains after Tapestry Security Logout
369... On Mon, Nov 3, 2014 at 12:39 PM, Harry Zhou superha...@gmail.com wrote: Kalle, Thank you so much for the quick reply, based on which we have done the following: 1. We surveyed several Tapestry sites (including the hotelbooking demo app) and confirmed that leaving the cookie after session invalidation is expected. 2. We then double confirmed that the leftover cookie is indeed the cause of server-side exception reporting -- as soon as the cookie is manually removed or re-issued by the server (as the result of a persistent page field, etc.), the server stops complaining. 3. We then decided that the issue was with the client's server environment, which ran Jetty 6, and confirmed with the client that it was an arbitrary choice. They provided a new Jetty 9 environment, under which we deployed the application, and the exceptions went away! So all is good! Thanks Kalle. Best, Harry On Mon, Nov 3, 2014 at 12:42 PM, Kalle Korhonen kalle.o.korho...@gmail.com wrote: On Sun, Nov 2, 2014 at 4:41 PM, Harry Zhou superha...@gmail.com wrote: The user is indeed logged out, and the session is indeed invalidated. Everything seems to work fine. 3. The Issue Upon closer inspection, I noticed that the session cookie created by user during login is still in the browser after logout. The browser repeatedly requests the session with the JSESSIONID: g3xfcskjnvf from the server, which has already been invalidated. Sure enough, the server stderrout log shows the following (trimmed for clarity) for each request made by the user after logout: INFO org.codehaus.wadi.core.contextualiser.HybridRelocater - Unknown session [g3xfcskjnvf] ERROR org.codehaus.wadi.core.manager.StandardManager - Could not acquire session [g3xfcskjnvf] Is it normal that the session cookie is not removed (by setting maxAge to 0, etc.) after the session is invalidated on the server side? If not, did I make a mistake in my way of logging the user out that causes the cookie to remain? First of all, requesting an invalid session should not have been logged as an error - it's a completely normal for a web application - a WARN or simply DEBUG would have suited much better (you could open an issue with Wadi on that). Anyway, tapestry-security doesn't explicitly remove JSESSIONID cookie on logout. It just invalidates the session and removes the rememberMe cookie. I didn't see that you are manually removing the JSESSIONID cookie anywhere in your code. If you are and it doesn't work, the headers must be rewritten after the fact. Whether it should be done automatically by the servlet implementation, I'm actually not sure if the spec says anything about it. We could check that out and if the behavior is left open, it'd be simple to add that as an enhancement to tapestry-security. Kalle -- Best Regards Harry Zhou
