David Parks (Migrated from SEC-1664) said:
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."
Luke Taylor said:
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.