|
@@ -83,43 +83,35 @@
|
|
<para>Spring Security uses many filters, as referred to throughout the
|
|
<para>Spring Security uses many filters, as referred to throughout the
|
|
remainder of this reference guide. You have a choice in how these
|
|
remainder of this reference guide. You have a choice in how these
|
|
filters are added to your web application, in that you can use either
|
|
filters are added to your web application, in that you can use either
|
|
- <literal>FilterToBeanProxy</literal> or
|
|
|
|
|
|
+ Spring's <literal>DelegatingFilterProxy</literal> or
|
|
<literal>FilterChainProxy</literal>. We'll look at both below.</para>
|
|
<literal>FilterChainProxy</literal>. We'll look at both below.</para>
|
|
-
|
|
|
|
- <para>Most filters are configured using the
|
|
|
|
- <literal>FilterToBeanProxy</literal>. An example configuration from
|
|
|
|
- <literal>web.xml</literal> follows:</para>
|
|
|
|
-
|
|
|
|
- <para><programlisting><filter>
|
|
|
|
-<filter-name>Spring Security HTTP Request Security Filter</filter-name>
|
|
|
|
-<filter-class>org.springframework.security.util.FilterToBeanProxy</filter-class>
|
|
|
|
-<init-param>
|
|
|
|
-<param-name>targetClass</param-name>
|
|
|
|
-<param-value>org.springframework.security.ClassThatImplementsFilter</param-value>
|
|
|
|
-</init-param>
|
|
|
|
-</filter></programlisting></para>
|
|
|
|
-
|
|
|
|
- <para>Notice that the filter in <literal>web.xml</literal> is actually
|
|
|
|
- a <literal>FilterToBeanProxy</literal>, and not the filter that will
|
|
|
|
- actually implement the logic of the filter. What
|
|
|
|
- <literal>FilterToBeanProxy</literal> does is delegate the
|
|
|
|
|
|
+
|
|
|
|
+ <para>When using <literal>DelegatingFilterProxy</literal>, you will see
|
|
|
|
+ something like this in the web.xml file:
|
|
|
|
+
|
|
|
|
+ <programlisting>
|
|
|
|
+ <![CDATA[
|
|
|
|
+ <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>
|
|
|
|
+ ]]>
|
|
|
|
+ </programlisting>
|
|
|
|
+
|
|
|
|
+ Notice that the filter is actually a <literal>DelegatingFilterProxy</literal>,
|
|
|
|
+ and not the filter that will actually implement the logic of the filter. What
|
|
|
|
+ <literal>DelegatingFilterProxy</literal> does is delegate the
|
|
<literal>Filter</literal>'s methods through to a bean which is
|
|
<literal>Filter</literal>'s methods through to a bean which is
|
|
obtained from the Spring application context. This enables the bean to
|
|
obtained from the Spring application context. This enables the bean to
|
|
- benefit from the Spring application context lifecycle support and
|
|
|
|
|
|
+ benefit from the Spring web application context lifecycle support and
|
|
configuration flexibility. The bean must implement
|
|
configuration flexibility. The bean must implement
|
|
- <literal>javax.servlet.Filter</literal>.</para>
|
|
|
|
-
|
|
|
|
- <para>The <literal>FilterToBeanProxy</literal> only requires a single
|
|
|
|
- initialization parameter, <literal>targetClass</literal> or
|
|
|
|
- <literal>targetBean</literal>. The <literal>targetClass</literal>
|
|
|
|
- parameter locates the first object in the application context of the
|
|
|
|
- specified class, whilst <literal>targetBean</literal> locates the
|
|
|
|
- object by bean name. Like standard Spring web applications, the
|
|
|
|
- <literal>FilterToBeanProxy</literal> accesses the application context
|
|
|
|
- via<literal>
|
|
|
|
- WebApplicationContextUtils.getWebApplicationContext(ServletContext)</literal>,
|
|
|
|
- so you should configure a <literal>ContextLoaderListener</literal> in
|
|
|
|
- <literal>web.xml</literal>.</para>
|
|
|
|
|
|
+ <literal>javax.servlet.Filter</literal> and it must have the same name as that in
|
|
|
|
+ the <literal>filter-name</literal> element.</para>
|
|
|
|
|
|
<para>There is a lifecycle issue to consider when hosting
|
|
<para>There is a lifecycle issue to consider when hosting
|
|
<literal>Filter</literal>s in an IoC container instead of a servlet
|
|
<literal>Filter</literal>s in an IoC container instead of a servlet
|
|
@@ -139,39 +131,31 @@
|
|
Spring interfaces (eg the <literal>destroy-method</literal> attribute
|
|
Spring interfaces (eg the <literal>destroy-method</literal> attribute
|
|
in Spring XML). For this reason we recommend the use of Spring
|
|
in Spring XML). For this reason we recommend the use of Spring
|
|
lifecycle services instead of servlet container lifecycle services
|
|
lifecycle services instead of servlet container lifecycle services
|
|
- wherever possible. By default <literal>FilterToBeanProxy</literal>
|
|
|
|
- will not delegate <literal>init(FilterConfig)</literal> and
|
|
|
|
- <literal>destroy()</literal> methods through to the proxied bean. If
|
|
|
|
- you do require such invocations to be delegated, set the
|
|
|
|
- <literal>lifecycle</literal> initialization parameter to
|
|
|
|
- <literal>servlet-container-managed</literal>.</para>
|
|
|
|
-
|
|
|
|
- <para>Rather than using <literal>FilterToBeanProxy</literal>, we
|
|
|
|
|
|
+ wherever possible. Read the Javadoc for <classname>DelegatingFilterProxy</classname>
|
|
|
|
+ for more information</para>
|
|
|
|
+
|
|
|
|
+ <para>Rather than using <literal>DelegatingFilterProxy</literal>, we
|
|
strongly recommend to use <literal>FilterChainProxy</literal> instead.
|
|
strongly recommend to use <literal>FilterChainProxy</literal> instead.
|
|
- Whilst <literal>FilterToBeanProxy</literal> is a very useful class,
|
|
|
|
- the problem is that the lines of code required for
|
|
|
|
|
|
+ Whilst <literal>DelegatingFilterProxy</literal> is a very useful class,
|
|
|
|
+ the problem is that the number of lines of code required for
|
|
<literal><filter></literal> and
|
|
<literal><filter></literal> and
|
|
<literal><filter-mapping></literal> entries in
|
|
<literal><filter-mapping></literal> entries in
|
|
<literal>web.xml</literal> explodes when using more than a few
|
|
<literal>web.xml</literal> explodes when using more than a few
|
|
filters. To overcome this issue, Spring Security provides a
|
|
filters. To overcome this issue, Spring Security provides a
|
|
<literal>FilterChainProxy</literal> class. It is wired using a
|
|
<literal>FilterChainProxy</literal> class. It is wired using a
|
|
- <literal>FilterToBeanProxy</literal> (just like in the example above),
|
|
|
|
|
|
+ <literal>DelegatingFilterProxy</literal> (just like in the example above),
|
|
but the target class is
|
|
but the target class is
|
|
<literal>org.springframework.security.util.FilterChainProxy</literal>.
|
|
<literal>org.springframework.security.util.FilterChainProxy</literal>.
|
|
The filter chain is then declared in the application context, using
|
|
The filter chain is then declared in the application context, using
|
|
code such as this:</para>
|
|
code such as this:</para>
|
|
|
|
|
|
- <para><programlisting><bean id="filterChainProxy"
|
|
|
|
- class="org.springframework.security.util.FilterChainProxy">
|
|
|
|
-<property name="filterInvocationDefinitionSource">
|
|
|
|
-<value>
|
|
|
|
- CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
|
|
|
|
- PATTERN_TYPE_APACHE_ANT
|
|
|
|
- /webServices/**=httpSessionContextIntegrationFilterWithASCFalse,basicProcessingFilter,exceptionTranslationFilter,filterSecurityInterceptor
|
|
|
|
- /**=httpSessionContextIntegrationFilterWithASCTrue,authenticationProcessingFilter,exceptionTranslationFilter,filterSecurityInterceptor
|
|
|
|
-</value>
|
|
|
|
-</property>
|
|
|
|
-</bean> </programlisting></para>
|
|
|
|
|
|
+ <para><programlisting><![CDATA[
|
|
|
|
+<bean id="filterChainProxy" class="org.springframework.security.util.FilterChainProxy">
|
|
|
|
+ <sec:filter-chain-map path-type="ant">
|
|
|
|
+ <sec:filter-chain pattern="/webServices/**" filters="httpSessionContextIntegrationFilterWithASCFalse,basicProcessingFilter,exceptionTranslationFilter,filterSecurityInterceptor"/>
|
|
|
|
+ <sec:filter-chain pattern="/**" filters="httpSessionContextIntegrationFilterWithASCTrue,authenticationProcessingFilter,exceptionTranslationFilter,filterSecurityInterceptor"/>
|
|
|
|
+ </sec:filter-chain-map>
|
|
|
|
+</bean> ]]> </programlisting></para>
|
|
|
|
|
|
<para>You may notice similarities with the way
|
|
<para>You may notice similarities with the way
|
|
<literal>FilterSecurityInterceptor</literal> is declared. Both regular
|
|
<literal>FilterSecurityInterceptor</literal> is declared. Both regular
|
|
@@ -221,11 +205,11 @@
|
|
irrespective of how many times it is declared by the
|
|
irrespective of how many times it is declared by the
|
|
<literal>FilterInvocationDefinitionSource</literal>. You control the
|
|
<literal>FilterInvocationDefinitionSource</literal>. You control the
|
|
overall choice as to whether these methods are called or not via the
|
|
overall choice as to whether these methods are called or not via the
|
|
- <literal>lifecycle</literal> initialization parameter of the
|
|
|
|
- <literal>FilterToBeanProxy</literal> that proxies
|
|
|
|
- <literal>FilterChainProxy</literal>. As discussed above, by default
|
|
|
|
|
|
+ <literal>targetFilterLifecycle</literal> initialization parameter of the
|
|
|
|
+ <literal>DelegatingFilterProxy</literal> that proxies
|
|
|
|
+ <literal>DelegatingFilterProxy</literal>. As discussed above, by default
|
|
any servlet container lifecycle invocations are not delegated through
|
|
any servlet container lifecycle invocations are not delegated through
|
|
- to <literal>FilterChainProxy</literal>.</para>
|
|
|
|
|
|
+ to <literal>DelegatingFilterProxy</literal>.</para>
|
|
|
|
|
|
<para>You can also omit a URI pattern from the filter chain by using
|
|
<para>You can also omit a URI pattern from the filter chain by using
|
|
the token <literal>#NONE#</literal> on the right-hand side of the
|
|
the token <literal>#NONE#</literal> on the right-hand side of the
|
|
@@ -317,12 +301,12 @@
|
|
</orderedlist>
|
|
</orderedlist>
|
|
|
|
|
|
<para>All of the above filters use
|
|
<para>All of the above filters use
|
|
- <literal>FilterToBeanProxy</literal> or
|
|
|
|
|
|
+ <literal>DelegatingFilterProxy</literal> or
|
|
<literal>FilterChainProxy</literal>. It is recommended that a single
|
|
<literal>FilterChainProxy</literal>. It is recommended that a single
|
|
- <literal>FilterToBeanProxy</literal> proxy through to a single
|
|
|
|
|
|
+ <literal>DelegatingFilterProxy</literal> proxy through to a single
|
|
<literal>FilterChainProxy</literal> for each application, with that
|
|
<literal>FilterChainProxy</literal> for each application, with that
|
|
<literal>FilterChainProxy</literal> defining all of Spring Security
|
|
<literal>FilterChainProxy</literal> defining all of Spring Security
|
|
- <literal>Filter</literal>s.</para>
|
|
|
|
|
|
+ filters.</para>
|
|
|
|
|
|
<para>If you're using SiteMesh, ensure Spring Security filters execute
|
|
<para>If you're using SiteMesh, ensure Spring Security filters execute
|
|
before the SiteMesh filters are called. This enables the
|
|
before the SiteMesh filters are called. This enables the
|