Ben Alex (Migrated from SEC-1412) said:
Adding ShallowEtagHeaderFilter to a web application that uses Spring Security will cause the redisplay of the Spring Security login page on the second login attempt. This was initially reported widely within the Spring Roo community and resulted in bug report ROO-579.
The problem can be seen by:
I have reproduced this with the Spring Security tutorial 3.0.1 web application WAR. I have made no changes to the WAR except modifying the web.xml to the following (I have included both filters for clarification of the order):
I have attached the tutorial WAR where you can see the problem by deploying to Tomcat. Simply access the "secure page", login as normal, and it will display. Then logout and click to view the "secure page" again. The login page will display. Login as normal, and on submission you will erroneously see the login page again. The problem can be avoided by disabling the ShallowEtagHeaderFilter in web.xml.
Luke Taylor said:
It seems that the problem is as follows:
I'm not sure at the moment why that would be the case. In a real application, this shouldn't be an issue as secured pages should not be cached at the client side.
The problem doesn't occur if you put the ShallowEtagHeaderFilter before the Spring Security filter chain. That way the Etag value changes when the response redirects to the login page.
I've noticed that Firefox doesn't send the If-None-Match header when it is requesting the original page after a redirect (subsequent to logging in). However the DefaultSavedRequest still returns the original header which was cached prior to forcing a login. This results in the 304 code being sent by the ShallowEtagHeaderFilter, and Firefox doesn't know what to do.
I've modified DefaultSavedRequest to ignore this header, which fixes the problem. However secure pages should generally have appropriate headers (no-cache etc) set to prevent the browser caching them to begin with.