Delegates {@code Filter} requests to a list of Spring-managed filter beans.As of version 2.0, you shouldn't need to explicitly configure a {@code FilterChainProxy} bean in your applicationcontext unless you need very fine control over the filter chain contents. Most cases should be adequately covered by the default {@code <security:http />} namespace configuration options.
The {@code FilterChainProxy} is linked into the servlet container filter chain by adding a standardSpring {@link DelegatingFilterProxy} declaration in the application {@code web.xml} file.
Configuration
As of version 3.1, {@code FilterChainProxy} is configured using a list of {@link SecurityFilterChain} instances,each of which contains a {@link RequestMatcher} and a list of filters which should be applied to matching requests.Most applications will only contain a single filter chain, and if you are using the namespace, you don't have to set the chains explicitly. If you require finer-grained control, you can make use of the {@code <filter-chain>}namespace element. This defines a URI pattern and the list of filters (as comma-separated bean names) which should be applied to requests which match the pattern. An example configuration might look like this:
<bean id="myfilterChainProxy" class="org.springframework.security.util.FilterChainProxy"> <constructor-arg> <util:list> <security:filter-chain pattern="/do/not/filter*" filters="none"/> <security:filter-chain pattern="/**" filters="filter1,filter2,filter3"/> </util:list> </constructor-arg> </bean>
The names "filter1", "filter2", "filter3" should be the bean names of {@code Filter} instances defined in theapplication context. The order of the names defines the order in which the filters will be applied. As shown above, use of the value "none" for the "filters" can be used to exclude a request pattern from the security filter chain entirely. Please consult the security namespace schema file for a full list of available configuration options.
Request Handling
Each possible pattern that the {@code FilterChainProxy} should service must be entered.The first match for a given request will be used to define all of the {@code Filter}s that apply to that request. This means you must put most specific matches at the top of the list, and ensure all {@code Filter}s that should apply for a given matcher are entered against the respective entry. The {@code FilterChainProxy} will not iterate through the remainder of the map entries to locate additional{@code Filter}s.
{@code FilterChainProxy} respects normal handling of {@code Filter}s that elect not to call {@link javax.servlet.Filter#doFilter(javax.servlet.ServletRequest,javax.servlet.ServletResponse,javax.servlet.FilterChain)}, in that the remainder of the original or {@code FilterChainProxy}-declared filter chain will not be called.
Request Firewalling
An {@link HttpFirewall} instance is used to validate incoming requests and create a wrapped request which providesconsistent path values for matching against. See {@link DefaultHttpFirewall}, for more information on the type of attacks which the default implementation protects against. A custom implementation can be injected to provide stricter control over the request contents or if an application needs to support certain types of request which are rejected by default.
Note that this means that you must use the Spring Security filters in combination with a {@code FilterChainProxy}if you want this protection. Don't define them explicitly in your {@code web.xml} file.
{@code FilterChainProxy} will use the firewall instance to obtain both request and response objects which will befed down the filter chain, so it is also possible to use this functionality to control the functionality of the response. When the request has passed through the security filter chain, the {@code reset} method will be called.With the default implementation this means that the original values of {@code servletPath} and {@code pathInfo} willbe returned thereafter, instead of the modified ones used for security pattern matching.
Since this additional wrapping functionality is performed by the {@code FilterChainProxy}, we don't recommend that you use multiple instances in the same filter chain. It shouldn't be considered purely as a utility for wrapping filter beans in a single {@code Filter} instance.
Filter Lifecycle
Note the {@code Filter} lifecycle mismatch between the servlet container and IoCcontainer. As described in the {@link DelegatingFilterProxy} Javadocs, we recommend you allow the IoCcontainer to manage the lifecycle instead of the servlet container. {@code FilterChainProxy} does not invoke thestandard filter lifecycle methods on any filter beans that you add to the application context.
@author Carlos Sanchez
@author Ben Alex
@author Luke Taylor
@author Rob Winch