Skip to main content

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.
 

Comments

Popular posts from this blog

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.2 Listing 1 - parent/pom.xml --- thymeleaf-tiles and tiles dependencies <!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --> <!-- Tiles --> <!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --> <dependency> <groupId>org.apache.tiles</groupId> <artifactId>tiles-core</artifactId> <version>${tiles.version}</version> <scope>compile</scope> </dependency> <dependency> <groupId>org.apache.tiles</groupId> <artifactId>tiles-template</artifactId> <version>${tiles.version}</version> <scope>compile</s...

CKEDITOR 3.x - Simplest Ajax Submit Plugin

  I have assumed that you have downloaded and got started with CKEDITOR. Step 1 – The html file is shown below: <html> <head> <title>Writer</title> <meta content="text/html; charset=utf-8" http-equiv="content-type" /> <script type="text/javascript" src="ckeditor/ckeditor.js"></script> <script type="text/javascript" src="js/jquery-1.4.2.min.js"></script> <style> .cke_contents { height: 400px !important; } </style> </head> <body> <form action="sample_posteddata.php" method="post"> <textarea id="editor" > </textarea> <script type="text/javascript"> //<![CDATA[ CKEDITOR.replace( 'editor', { fullPage : true, uiColor : '#9AB8F3', toolbar : 'MyToolbar' }); //]]> </script> </form> </body> </html> Note that the jquery js...

Getting started with Prime faces 2

Prime faces is an amazing JSF framework from Cagatay Civici ( http://cagataycivici.wordpress.com/ ). Its wonderful because it is easy to use, minimal dependencies, has probably the widest set of controls among all JSF frameworks, easy to integrate with Spring (including Spring Security) , Java EE EJBs, and last but not the least mobile UI support. So I decided to give Prime faces a try, before selecting it to use in my projects. Step 1 – Create Maven 2 project As a first step to integrating Prime faces, create a Maven 2 project in Eclipse. You will need to select ‘maven-archetype-webapp’. Step 2 – Add repositories and dependencies in pom.xml I will be using Prime faces 2 with JSF 2 on Tomcat 6. Since the dependencies for Prime Faces and JSF 2 (JSF 2.0.3 is required) are available on different repositories, I will add them to my pom file first. The listing below shows my pom.xml <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/X...