Skip to main content

Let us look at the Spring security filter chain


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:



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.


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="">
  <sec:filter-chain-map path-type="ant">
     <sec:filter-chain pattern="/SkyPhotoWeb/**" filters="
           filterSecurityInterceptor" />
     <sec:filter-chain pattern="/**" filters="
           filterSecurityInterceptor" />

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.


Popular posts from this blog

Why do you need Spring Cloud Config server?

Last month I wrote a primer on concepts around 12 factor app. Before getting into the details of the Spring Cloud Config Server, I must refresh on the principle #3 from the list presented in that post.

3 – ConfigurationStore config in the environments
Configuration information must be separate from the source code. This may seem so obvious, but often we are guilty of leaving critical configuration parameters in the scattered in the code. Instead, applications should have environment specific configuration files. The sensitive information like database password or API key should be stored in these environment configuration files in encrypted format.
 The key takeaways from this postulate for a cloud-native microservices application are:
Do not store configuration as part of the deployable unit (in the case of lead microservice - inside the jar or war if you are still deploying war like the good old days). Instead, store it in an external location and make it easily accessible during run-…

Changing the root web application in Tomcat 6

These days I am very busy developing a large and complex web application, which is nearing its first release. This web based product runs on Tomcat 6 and will be deployed on
But if I deploy my web application on Tomcat 6, I need to specify the context root. Well this is no good, why will the users of this website be willing to remember the context root. What if the context root changes. In other words the users would not be interest in typing the following - to visit this site.
Hence it is necessary that I change the default / root web application of Tomcat and point it to my application. I wanted to try and test this on localhost first. As always I Googled and found a number of posts and none seem to work. I also read the documentation it was helpful in understanding the concepts but was not effective as I could not get it working. Finally after few hours of trial and error one of my colleague Joyeeta Majumdar found the so…

Part 3 - Integrating Tiles, Thymeleaf and Spring MVC 3

In this post I will demonstrate how to integrate Apache Tiles with Thymeleaf. This is very simple. The first step is to include the tiles and thymeleaf-tiles extension dependencies. I will include them in the pom.xml. Note we wil lbe using Tiles 2.2.2Listing 1 - parent/pom.xml --- thymeleaf-tiles and tiles dependencies <!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->
<!-- Tiles -->
<!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->