public class FilterChainProxy extends GenericFilterBean
Filter
requests to a list of Spring-managed filter beans.
As of version 2.0, you shouldn't need to explicitly configure a FilterChainProxy
bean in your application
context unless you need very fine control over the filter chain contents. Most cases should be adequately covered
by the default <security:http />
namespace configuration options.
The FilterChainProxy
is linked into the servlet container filter chain by adding a standard
Spring DelegatingFilterProxy
declaration in the application web.xml
file.
As of version 3.1, FilterChainProxy
is configured using a list of SecurityFilterChain
instances,
each of which contains a 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 <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
Filter
instances defined in the
application 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.
Each possible pattern that the FilterChainProxy
should service must be entered.
The first match for a given request will be used to define all of the Filter
s that apply to that
request. This means you must put most specific matches at the top of the list, and ensure all Filter
s
that should apply for a given matcher are entered against the respective entry.
The FilterChainProxy
will not iterate through the remainder of the map entries to locate additional
Filter
s.
FilterChainProxy
respects normal handling of Filter
s that elect not to call Filter.doFilter(javax.servlet.ServletRequest, javax.servlet.ServletResponse,
javax.servlet.FilterChain)
, in that the remainder of the original or FilterChainProxy
-declared filter
chain will not be called.
HttpFirewall
instance is used to validate incoming requests and create a wrapped request which provides
consistent path values for matching against. See 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 FilterChainProxy
if you want this protection. Don't define them explicitly in your web.xml
file.
FilterChainProxy
will use the firewall instance to obtain both request and response objects which will be
fed 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 reset
method will be called.
With the default implementation this means that the original values of servletPath
and pathInfo
will
be returned thereafter, instead of the modified ones used for security pattern matching.
Since this additional wrapping functionality is performed by the 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 Filter
instance.
Note the Filter
lifecycle mismatch between the servlet container and IoC
container. As described in the DelegatingFilterProxy
Javadocs, we recommend you allow the IoC
container to manage the lifecycle instead of the servlet container. FilterChainProxy
does not invoke the
standard filter lifecycle methods on any filter beans that you add to the application context.
Modifier and Type | Class and Description |
---|---|
static interface |
FilterChainProxy.FilterChainValidator |
Constructor and Description |
---|
FilterChainProxy() |
FilterChainProxy(List<SecurityFilterChain> filterChains) |
FilterChainProxy(SecurityFilterChain chain) |
Modifier and Type | Method and Description |
---|---|
void |
afterPropertiesSet() |
void |
doFilter(javax.servlet.ServletRequest request,
javax.servlet.ServletResponse response,
javax.servlet.FilterChain chain) |
Map<RequestMatcher,List<javax.servlet.Filter>> |
getFilterChainMap()
Deprecated.
use the list of
SecurityFilterChain s instead |
List<SecurityFilterChain> |
getFilterChains() |
List<javax.servlet.Filter> |
getFilters(String url)
Convenience method, mainly for testing.
|
void |
setFilterChainMap(Map<RequestMatcher,List<javax.servlet.Filter>> filterChainMap)
Deprecated.
Use the constructor which takes a
List<SecurityFilterChain> instead. |
void |
setFilterChainValidator(FilterChainProxy.FilterChainValidator filterChainValidator)
Used (internally) to specify a validation strategy for the filters in each configured chain.
|
void |
setFirewall(HttpFirewall firewall)
Sets the "firewall" implementation which will be used to validate and wrap (or potentially reject) the
incoming requests.
|
String |
toString() |
addRequiredProperty, destroy, getFilterConfig, getFilterName, getServletContext, init, initBeanWrapper, initFilterBean, setBeanName, setEnvironment, setServletContext
public FilterChainProxy()
public FilterChainProxy(SecurityFilterChain chain)
public FilterChainProxy(List<SecurityFilterChain> filterChains)
public void afterPropertiesSet()
afterPropertiesSet
in interface InitializingBean
afterPropertiesSet
in class GenericFilterBean
public void doFilter(javax.servlet.ServletRequest request, javax.servlet.ServletResponse response, javax.servlet.FilterChain chain) throws IOException, javax.servlet.ServletException
IOException
javax.servlet.ServletException
public List<javax.servlet.Filter> getFilters(String url)
url
- the URL@Deprecated public void setFilterChainMap(Map<RequestMatcher,List<javax.servlet.Filter>> filterChainMap)
List<SecurityFilterChain>
instead.Filter
objects.
It's VERY important that the type of map used preserves ordering - the order in which the iterator
returns the entries must be the same as the order they were added to the map, otherwise you have no way
of guaranteeing that the most specific patterns are returned before the more general ones. So make sure
the Map used is an instance of LinkedHashMap
or an equivalent, rather than a plain HashMap
, for
example.filterChainMap
- the map of path Strings to List<Filter>
s.@Deprecated public Map<RequestMatcher,List<javax.servlet.Filter>> getFilterChainMap()
SecurityFilterChain
s insteadpublic List<SecurityFilterChain> getFilterChains()
SecurityFilterChain
s which will be matched against and
applied to incoming requests.public void setFilterChainValidator(FilterChainProxy.FilterChainValidator filterChainValidator)
filterChainValidator
- the validator instance which will be invoked on during initialization
to check the FilterChainProxy
instance.public void setFirewall(HttpFirewall firewall)
firewall
-