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

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-…

Upgrading Lead Microservice - Use MariaDB and Flyway with Spring Boot

So far I have been using an in-memory H2 database or Mockito for testing the lead microservice. To make the transition towards using the Spring Cloud Config server, I need to upgrade the micro-application to use MariaDB. I will be adding the configuration in the application.yml  the file which in the subsequent post will move over to the config server store. I will also be using Flyway to make it easy to maintain the database schema changes in future. I will use this post to introduce Flyway in the mix. Spring Boot also provides first class integration with Flyway. I am using Flyway as its really quick and easy to get started, minimal learning curve (no DSL) and I am comfortable with it having used it in the past.

Assumptions

MariaDB 10 is installedBasic familiarity with FlywayHeidi SQL client is installed.
Step 1 - Update build.gradle to include the MariaDB JDBC and Flyway dependencies.
Do not forget to do a Gradle refresh on your IDE (I am using STS 3.8.4 on Java 8)

Step 2 - Rename the…

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 -->
<!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -->

<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</scope>