Spring Security
  1. Spring Security
  2. SEC-1664

Documentation slighly misleading: Add a note to the documentation section 5.3.2 to avoid below issue in Spring-MVC

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Complete
    • Affects Version/s: 3.0.5
    • Fix Version/s: 3.1.0.RC1
    • Component/s: Docs and Website
    • Labels:
      None

      Description

      Based on discussion in (closed) bug SEC-1656, it is easy to run into a problem with session creation when manually setting an Authentication using the SecurityContextHolder, when done from within a controller (after the filters).

      The documentation in section 5.3.2 suggest that it is safe practice to set the SecurityContextHolder from within an MVC controller. This will lead many users to a situation where the authentication is lost due to a new session object/session ID being created, but not reported to the browser when the action occurs within a controller (see the aforementioned bug for details).

      The documentation for section 5.3.2 should contain the following notice to avoid users having this problem:

      "If the Authentication is set using SecurityContextHolder from within a SpringMVC controller before a session object is created (for example from within a controller handling user registration), a 'redirect:' directive should be used rather than rendering a page or using the 'forward:' directive. This will ensure that the new session object & new session ID, that are created upon setting the Authentication, are properly reported back to the browser."

        Activity

        Hide
        Luke Taylor added a comment -

        I've added a comment to indicate that you may need to ensure a session is created if you are manually setting the security context yourself, since the issue of committed responses is a common source of confusion. I don't think the issue of forwarding versus redirecting is directly relevant. The point is that a session needs top be available before the response is committed, if you are caching the context in the session.

        Not also that your original description of SEC-1656 doesn't appear to be correct. It implies that a session is created after the response has been committed, which will throw an IllegalStateException.

        Show
        Luke Taylor added a comment - I've added a comment to indicate that you may need to ensure a session is created if you are manually setting the security context yourself, since the issue of committed responses is a common source of confusion. I don't think the issue of forwarding versus redirecting is directly relevant. The point is that a session needs top be available before the response is committed, if you are caching the context in the session. Not also that your original description of SEC-1656 doesn't appear to be correct. It implies that a session is created after the response has been committed, which will throw an IllegalStateException.

          People

          • Assignee:
            Luke Taylor
            Reporter:
            David Parks
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: