Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 3.0.4
    • Fix Version/s: 3.0.5, 3.1.0.M2
    • Component/s: Web
    • Labels:
      None

      Description

      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.

        Activity

        Hide
        Luke Taylor added a comment -

        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?

        Show
        Luke Taylor added a comment - 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?
        Hide
        Sebastian Beigel added a comment -

        Simple test-case: Tomcat w/ latest Spring & Spring Security. Testing in latest FF and Chrome on OS X.

        security-config.xml:

        <http auto-config="true">
        <intercept-url pattern="/login.jsp*" filters="none" />
        <intercept-url pattern="/**" access="ROLE_USER" />

        <form-login login-page="/login.jsp" authentication-failure-url="/accessDenied.jsp" login-processing-url="/j_spring_security_check" default-target-url="/index.html" always-use-default-target="false" />
        </http>
        ...

        And a simple & plain HTML file index.html in you doc-root (just <h1>Test</h1>, no header set via meta or server-side).

        The login.jsp is plain & straight forward as well:

        <form name="f" action="<c:url value="j_spring_security_check"/>" method="POST">
        <table>
        <tr><td>User:</td><td><input type="text" name="j_username" /></td></tr>
        <tr><td>Password:</td><td><input type="password" name="j_password" /></td></tr>
        <tr><td colspan="2"><input name="submit" type="submit" value="Log in" /></td></tr>
        </table>
        </form>

        HTTP-Traffic:
        [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.

        Show
        Sebastian Beigel added a comment - Simple test-case: Tomcat w/ latest Spring & Spring Security. Testing in latest FF and Chrome on OS X. security-config.xml: <http auto-config="true"> <intercept-url pattern="/login.jsp*" filters="none" /> <intercept-url pattern="/**" access="ROLE_USER" /> <form-login login-page="/login.jsp" authentication-failure-url="/accessDenied.jsp" login-processing-url="/j_spring_security_check" default-target-url="/index.html" always-use-default-target="false" /> </http> ... And a simple & plain HTML file index.html in you doc-root (just <h1>Test</h1>, no header set via meta or server-side). The login.jsp is plain & straight forward as well: <form name="f" action="<c:url value="j_spring_security_check"/>" method="POST"> <table> <tr><td>User:</td><td><input type="text" name="j_username" /></td></tr> <tr><td>Password:</td><td><input type="password" name="j_password" /></td></tr> <tr><td colspan="2"><input name="submit" type="submit" value="Log in" /></td></tr> </table> </form> HTTP-Traffic: [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.
        Hide
        Luke Taylor added a comment -

        Ok, I think that makes sense. Thanks for the report. I've added a check for "If-Modified-Since" the header, as described.

        Show
        Luke Taylor added a comment - Ok, I think that makes sense. Thanks for the report. I've added a check for "If-Modified-Since" the header, as described.

          People

          • Assignee:
            Luke Taylor
            Reporter:
            Sebastian Beigel
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: