I see this in my Spring MVC app’s web.xml
:
<filter>
<filter-name>springSecurityFilterChain</filter-name>
<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
I’m trying to figure out why it’s there and whether it’s actually needed.
I found this explanation in the Spring docs but it doesn’t help me make sense of it:
It seems to suggest that this component is the “glue” between the servlets defined in web.xml
and the components defined in the Spring applicationContext.xml
.
7.1 DelegatingFilterProxy
When using servlet filters, you obviously need to declare them in yourweb.xml
, or they will be ignored by the servlet container. In Spring Security, the filter classes are also Spring beans defined in the application context and thus able to take advantage of Spring’s rich dependency-injection facilities and lifecycle interfaces. Spring’sDelegatingFilterProxy
provides the link betweenweb.xml
and the application context.When using
DelegatingFilterProxy
, you will see something like this in theweb.xml
file:<filter> <filter-name>myFilter</filter-name> <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class> </filter>
<filter-mapping>
<filter-name>myFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
Notice that the filter is actually a
DelegatingFilterProxy
, and not the class that will actually implement the logic of the filter. WhatDelegatingFilterProxy
does is delegate theFilter
’s methods through to a bean which is obtained from the Spring application context. This enables the bean to benefit from the Spring web application context lifecycle support and configuration flexibility. The bean must implementjavax.servlet.Filter
and it must have the same name as that in thefilter-name
element.
So, if I take this out of my web.xml
, what will happen? My servlets won’t be able to communicate with the Spring container?
There’s some kind of magic here, but at the end, everything is a deterministic program.
The DelegatingFilterProxy
is a Filter as it was explained above, whose goal is “delegating to a Spring-managed bean that implements the Filter
interface”, that is, it finds a bean (“target bean” or “delegate”) in your Spring application context and invokes it. How is it possible? Because this bean implements javax.servlet.Filter
, its doFilter
method is called.
Which bean is called? the DelegatingFilterProxy
“Supports a “targetBeanName
“, specifying the name of the target bean in the Spring application context.”
As you saw in your web.xml
that the bean’s name is “springSecurityFilterChain
“.
So, in the context of a web application, a Filter
instantiates a bean called “springSecurityFilterChain
” in your application context and then delegate to it via the doFilter()
method.
Remember, your application context is defined with ALL THE APPLICATION-CONTEXT (XML) files. For instance: applicationContext.xml
AND applicationContext-security.xml
.
So try to find a bean called “springSecurityFilterChain
” in the latter…
…and probably you can’t (for instance if you followed a tutorial or if you configured the security using Roo)
Here is the magic: there’s a new element for configuring the security, something like
<http auto-config="true" use-expressions="true">
as it is allowed by http://www.springframework.org/schema/security/spring-security-3.0.xsd, will do the trick.
When Spring loads the application context using XML files, if it finds a element, it will try to set up the HTTP security, that is, a filter stack and protected URLs and to register the FilterChainProxy
named “springSecurityFilterChain
“.
Alternatively, you can define the bean in the classic way, that is:
<beans:bean id="springSecurityFilterChain" class="org.springframework.security.web.FilterChainProxy">
But it’s less recommended, since you need to do a lot of configuration (all the filters that you’re going to use. And there are more than a dozen of them)
Do you know what a Servlet Filter is and how it works? It’s a very useful piece of the Servlet Spec, allowing us to apply AOP-like concepts to servicing of HTTP requests. Many frameworks use Filter
implementations for various things, and it’s not uncommon to find custom implementations of them because they’ve very simple to write and useful. In a Spring app, most of the stuff that your app can do is in your Spring beans. A Filter
instance, though, is controlled by the servlet container. The container instantiates, initializes, and destroys it. The Servlet Spec doesn’t require any kind of Spring integration, though, so you’re left with a really useful concept (Filters
) with no convenient way of tying it to your Spring app and the beans that do the work.
Enter the DelegatingFilterProxy
. You write a Filter
implementation and make it a Spring bean, but instead of adding your own Filter class to the web.xml
, you use the DelegatingFilterProxy
, and give it the bean name of your filter in the Spring context. (If you don’t explicitly provide a name, it uses the “filter-name
“.) Then at runtime, the DelegatingFilterProxy
handles the complexity of finding the real implementation - the one you wrote and configured in Spring - and routing requests to it. So at runtime, it’s as if you had listed your filter in the web.xml
, but you get the benefit of being able to wire it like any other Spring bean.
If you take that filter mapping out of your web.xml
, everything will continue working, but none of your URLs will be secured. (That’s assuming the name “springSecurityFilterChain
” accurately describes what it does.) That’s because this mapping is filtering every incoming request and handing it off to a security filter that’s defined in your spring context.
What are Servlet Filters?
Servlet Filters are general Java WebApp concept. You can have servlet filters in any webapp, whether or not you use Spring framework in your application.
These filters can intercept requests before they reach the target servlet. You can implement common functionality, like authorization, in servlet filters. Once implemented you can configure the filter in your web.xml
to be applied to specific servlet, specific request url patterns or all url patterns.
Where servlet filters are used?
Modern web-apps can have dozens of such filters. Things like authorization, caching, ORM session management, dependency injection etc. are often implemented with the aid of servlet filter. All of these filters need to be registered in web.xml
Instantiating Servlet Filters - without Spring Framework
Your servlet container create instances of Filters declared in web.xml
and call them at appropriate time (i-e when servicing servlet requests). Now if you are like most of the Dependency Injection (DI) fans, you would likely say that creation of instances is what my DI framework (Spring) does better. Can’t I get my servlet filters created with Spring so they are amenable to all DI goodness?
DelegatingFilterProxy
, so that Spring create your filter instances
This is where DelegatingFilterProxy
steps in.DelegatingFilterProxy
is an impelmentation of javax.servlet.Filter
interface provided by Spring Framework. Once you configure DelegatingFilterProxy
in web.xml
, you can declare the actual beans that do the filtering in your spring configuration. This way Spring create the instances of beans that do the actual filtering, and you can use the DI to configure these beans.
Note that you need only a single DelegatingFilterProxy
declaration in web.xml
but you can have several several filtering beans chained together in your application context.