Package org.apache.shiro.spring.web

Class ShiroFilterFactoryBean

java.lang.Object
org.apache.shiro.spring.web.ShiroFilterFactoryBean
All Implemented Interfaces:
BeanPostProcessor, FactoryBean
public class ShiroFilterFactoryBean extends Object implements FactoryBean, BeanPostProcessor
FactoryBean to be used in Spring-based web applications for defining the master Shiro Filter.

Usage

Declare a DelegatingFilterProxy in web.xml, matching the filter name to the bean id: 
 <filter>
   <filter-name>shiroFilter</filter-name>
   <filter-class>org.springframework.web.filter.DelegatingFilterProxy<filter-class>
   <init-param>
    <param-name>targetFilterLifecycle</param-name>
     <param-value>true</param-value>
   </init-param>
 </filter>
Then, in your spring XML file that defines your web ApplicationContext: 
 <bean id="shiroFilter" class="org.apache.shiro.spring.web.ShiroFilterFactoryBean">
    <property name="securityManager" ref="securityManager"/>
    <!-- other properties as necessary ... -->
 </bean>

Filter Auto-Discovery

While there is a filters property that allows you to assign a filter beans to the 'pool' of filters available when defining filter chains, it is optional.

This implementation is also a BeanPostProcessor and will acquire any Filter beans defined independently in your Spring application context. Upon discovery, they will be automatically added to the map keyed by the bean ID. That ID can then be used in the filter chain definitions, for example: 

 <bean id="myCustomFilter" class="com.class.that.implements.javax.servlet.Filter"/>
 ...
 <bean id="shiroFilter" class="org.apache.shiro.spring.web.ShiroFilterFactoryBean">
    ...
    <property name="filterChainDefinitions">
        <value>
            /some/path/** = authc, myCustomFilter
        </value>
    </property>
 </bean>

Global Property Values

Most Shiro servlet Filter implementations exist for defining custom Filter chain definitions. Most implementations subclass one of the AccessControlFilter, AuthenticationFilter, AuthorizationFilter classes to simplify things, and each of these 3 classes has configurable properties that are application-specific.

A dilemma arises where, if you want to for example set the application's 'loginUrl' for any Filter, you don't want to have to manually specify that value for each filter instance defined.

To prevent configuration duplication, this implementation provides the following properties to allow you to set relevant values in only one place:

Then at startup, any values specified via these 3 properties will be applied to all configured Filter instances so you don't have to specify them individually on each filter instance. To ensure your own custom filters benefit from this convenience, your filter implementation should subclass one of the 3 mentioned earlier.

Since:
1.0
See Also: