The order that filters are defined in web.xml is very important. Irrespective of which filters you are actually using, the order of the <filter-mapping>s should be as follows:
1,ChannelProcessingFilter, because it might need to redirect to a different protocol
2,ConcurrentSessionFilter, because it doesn't use any SecurityContextHolder functionality but needs to update the SessionRegistry to reflect ongoing requests from the principal
3,HttpSessionContextIntegrationFilter, so a SecurityContext can be setup in the SecurityContextHolder at the beginning of a web request, and any changes to the SecurityContext can be copied to the HttpSession when the web request ends (ready for use with the next web request)
4,Authentication processing mechanisms - AuthenticationProcessingFilter, CasProcessingFilter, BasicProcessingFilter, HttpRequestIntegrationFilter, JbossIntegrationFilter etc - so that the SecurityContextHolder can be modified to contain a valid Authentication request token
5,The SecurityContextHolderAwareRequestFilter, if you are using it to install an Acegi Security aware HttpServletRequestWrapper into your servlet container
6,RememberMeProcessingFilter, so that if no earlier authentication processing mechanism updated the SecurityContextHolder, and the request presents a cookie that enables remember-me services to take place, a suitable remembered Authentication object will be put there
7,AnonymousProcessingFilter, so that if no earlier authentication processing mechanism updated the SecurityContextHolder, an anonymous Authentication object will be put there
8,ExceptionTranslationFilter, to catch any Acegi Security exceptions so that either a HTTP error response can be returned or an appropriate AuthenticationEntryPoint can be launched
9,FilterSecurityInterceptor, to protect web URIs
All of the above filters use FilterToBeanProxy or FilterChainProxy. It is recommended that a single FilterToBeanProxy proxy through to a single FilterChainProxy for each application, with that FilterChainProxy defining all of Acegi Security Filters.
1,ChannelProcessingFilter, because it might need to redirect to a different protocol
2,ConcurrentSessionFilter, because it doesn't use any SecurityContextHolder functionality but needs to update the SessionRegistry to reflect ongoing requests from the principal
3,HttpSessionContextIntegrationFilter, so a SecurityContext can be setup in the SecurityContextHolder at the beginning of a web request, and any changes to the SecurityContext can be copied to the HttpSession when the web request ends (ready for use with the next web request)
4,Authentication processing mechanisms - AuthenticationProcessingFilter, CasProcessingFilter, BasicProcessingFilter, HttpRequestIntegrationFilter, JbossIntegrationFilter etc - so that the SecurityContextHolder can be modified to contain a valid Authentication request token
5,The SecurityContextHolderAwareRequestFilter, if you are using it to install an Acegi Security aware HttpServletRequestWrapper into your servlet container
6,RememberMeProcessingFilter, so that if no earlier authentication processing mechanism updated the SecurityContextHolder, and the request presents a cookie that enables remember-me services to take place, a suitable remembered Authentication object will be put there
7,AnonymousProcessingFilter, so that if no earlier authentication processing mechanism updated the SecurityContextHolder, an anonymous Authentication object will be put there
8,ExceptionTranslationFilter, to catch any Acegi Security exceptions so that either a HTTP error response can be returned or an appropriate AuthenticationEntryPoint can be launched
9,FilterSecurityInterceptor, to protect web URIs
All of the above filters use FilterToBeanProxy or FilterChainProxy. It is recommended that a single FilterToBeanProxy proxy through to a single FilterChainProxy for each application, with that FilterChainProxy defining all of Acegi Security Filters.
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
