Let us look at the Spring security filter chain

DelegatingFilterProxy

The DelegatingFilterProxy is a special filter provided by the Spring framework.It acts as a bridge connecting
the web container and spring application container. In other words it helps pipeline request processing
from the web container filter to a bean in Spring web application context.

DelegatingFilterProxy is configured in the web.xml as shown below:


<filter>
    <filter-name>springSecurityFilterChain</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
  </filter>

  <filter-mapping>
    <filter-name>springSecurityFilterChain</filter-name>
    <url-pattern>/*</url-pattern>
  </filter-mapping>
     

DelegatingFilterProxy is essentially a dumb filter and implements no logic. Its sole responsibility is to delegate the Filter'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.
This bean must implement javax.servlet.Filter and it must have the same name as that in the filter-name element.


FilterChainProxy

DelegatingFilterProxy is actually connected to a FilterChainProxy in the Spring application context.
The FilterChainProxy bean has the same name as the filter name in the web.xml
You all must be very bored hearing this again again. I am trying to get this deep into your head
as it is one area of common configuration mistake and subsequent head banging. Trivial errors are
always difficult to locate.

In our case the FilterChainProxy was configured by the namespace configuration. A typical FilterChainProxy
would look like this:

<bean id="springSecurityFilterChain" class="org.springframework.security.web.FilterChainProxy">
  <sec:filter-chain-map path-type="ant">
     <sec:filter-chain pattern="/SkyPhotoWeb/**" filters="
           securityContextPersistenceFilterWithASCFalse,
           basicAuthenticationFilter,
           exceptionTranslationFilter,
           filterSecurityInterceptor" />
     <sec:filter-chain pattern="/**" filters="
           securityContextPersistenceFilterWithASCTrue,
           formLoginFilter,
           exceptionTranslationFilter,
           filterSecurityInterceptor" />
  </sec:filter-chain-map>
</bean>


Now from the documentation -
"The namespace element filter-chain-map is used to set up the security filter chain(s) which are required within the application.
It maps a particular URL pattern to a chain of filters built up from the bean names specified in the filters element.
Both regular expressions and Ant Paths are supported, and the most specific URIs appear first.
At runtime the FilterChainProxy will locate the first URI pattern that matches the current web request and the list of filter beans specified
by the filters  attribute will be applied to that request.
The filters will be invoked in the order they are defined, so you have complete control over the filter chain which is applied to a particular URL."

As you may have already guessed the bean names in the filters atrribute is a comma separate list of
bean names configured in the Spring context. For the moment assume that they are there. I will come back to put them into action and lecture
more about them.

Now let us look into the lifecycle aspect of the FilterChainProxy.Today being a weekend, I am feeling a bit lazy so will
copy and paste again from the official documentation which gives very good information on the lifecycle aspects.

"In relation to lifecycle issues, the FilterChainProxy will always delegate init(FilterConfig) and destroy() 
methods through to the underlaying Filters if such methods are called against FilterChainProxy itself.
In this case, FilterChainProxy guarantees to only initialize and destroy each Filter bean once,
no matter how many times it is declared in the filter chain(s).
You control the overall choice as to whether these methods are called or not via the targetFilterLifecycle initialization parameter
of DelegatingFilterProxy.
By default this property is false and servlet container lifecycle invocations are not delegated through DelegatingFilterProxy."

Thats it for now. I know you guys are getting bored with theory. Please be patient, I will drop in few more theory session, and
soon get back to hands on stuff.