Decorators are rendered upon completion of the servlet filterChain and returning back up to the Sitemesh filter. The correct placement of the Sitemesh filter is in a position before any possible content rendering so that it could be buffered for processing.
The issue with Spring Security is its own filterChain.
If the security context is needed inside a decorator it will not be available if the Sitemesh filter I registered prior to the execution of SecurityContextPersistenceFilter because it is cleared when the filter completes. This can be solved by registering the Sitemesh filter immediately after the Spring Security filterChain.
However, if the Sitemesh filter is registered after the Spring Security filterChain and a user tries to access a protected page, the Sitemesh filter is bypassed and the not authorized error page is not decorated.
Decorators are rendered upon completion of the servlet filterChain and returning back up to the Sitemesh filter. The correct placement of the Sitemesh filter is in a position before any possible content rendering so that it could be buffered for processing.
The issue with Spring Security is its own filterChain.
If the security context is needed inside a decorator it will not be available if the Sitemesh filter I registered prior to the execution of
SecurityContextPersistenceFilterbecause it is cleared when the filter completes. This can be solved by registering the Sitemesh filter immediately after the Spring Security filterChain.However, if the Sitemesh filter is registered after the Spring Security filterChain and a user tries to access a protected page, the Sitemesh filter is bypassed and the not authorized error page is not decorated.