Sebastian Beigel (Migrated from SEC-1624) said:
Using plain but secured HTML pages, I have the same problem of a redisplayed login form due to a caching problem (not using ShallowEtagHeaderFilter).
The fix for SEC-1412 should be extended to not include "If-Modified-Since" headers. Their presence results in the same behavior: The "cached" login form is displayed instead of the "real" page. Excluding theses headers fixes the problem.
Luke Taylor said:
I don't really understand what the caching problem is and why something is being cached which shouldn't. Could you provide a detailed description of your setup - what is rendering the pages, what headers the browser is sending and what headers are being set on the server side?
Sebastian Beigel said:
Simple test-case: Tomcat w/ latest Spring & Spring Security. Testing in latest FF and Chrome on OS X.
And a simple & plain HTML file index.html in you doc-root (just
The login.jsp is plain & straight forward as well:
[not logged in, no cookie]
GET /index.html -> 302 (login.jsp;jsessionid..., set-cookie)
GET login.jsp;jsessionid... -> 200 (login form content)
POST /j_spring_security_check (w/ correct credentials & jsessionid cookie) -> 302 (index.html w/ new set-cookie jsessionid)
GET index.html -> 304 (w/ default Etag and mod. date)
GET login.jsp;jsessionid (w/ "old" session id!!) -> 200 (login form content)
Patching DefaultSavedRequest as described (excluding If-Modified-Since headers) or clearing the browser cache (manually) solves the problem.
Ok, I think that makes sense. Thanks for the report. I've added a check for "If-Modified-Since" the header, as described.