<!-- We want eternal="true" (with no timeToIdle or timeToLive settings) because Shiro manages session
expirations explicitly. If we set it to false and then set corresponding timeToIdle and timeToLive properties,
ehcache would evict sessions without Shiro's knowledge, which would cause many problems
(e.g. "My Shiro session timeout is 30 minutes - why isn't a session available after 2 minutes?"
Answer - ehcache expired it due to the timeToIdle property set to 120 seconds.)
diskPersistent=true since we want an enterprise session management feature - ability to use sessions after
even after a JVM restart. -->
<cache name="shiro-activeSessionCache"
maxElementsInMemory="10000"
eternal="true"
overflowToDisk="true"
diskPersistent="true"
diskExpiryThreadIntervalSeconds="600"/>
<!-- ========================================================= Shiro Core
Components - Not Spring Specific ========================================================= -->
<!-- Shiro's main business-tier object for web-enabled applications (use
DefaultSecurityManager instead when there is no web environment) -->
<bean id="securityManager" class="org.apache.shiro.web.mgt.DefaultWebSecurityManager">
<property name="cacheManager" ref="cacheManager" />
<!-- Single realm app. If you have multiple realms, use the 'realms' property
instead. -->
<property name="sessionMode" value="native" />
<property name="realm" ref="myRealm" />
</bean>
<!-- Let's use some enterprise caching support for better performance. You
can replace this with any enterprise caching framework implementation that
you like (Terracotta+Ehcache, Coherence, GigaSpaces, etc -->
<bean id="cacheManager" class="org.apache.shiro.cache.ehcache.EhCacheManager">
<!-- Set a net.sf.ehcache.CacheManager instance here if you already have
one. If not, a new one will be creaed with a default config: -->
<property name="cacheManager" ref="ehCacheManager" />
<!-- If you don't have a pre-built net.sf.ehcache.CacheManager instance
to inject, but you want a specific Ehcache configuration to be used, specify
that here. If you don't, a default will be used.: <property name="cacheManagerConfigFile"
value="classpath:some/path/to/ehcache.xml"/> -->
</bean>
<!-- Used by the SecurityManager to access security data (users, roles,
etc). Many other realm implementations can be used too (PropertiesRealm,
LdapRealm, etc. -->
<bean id="jdbcRealm" class="org.apache.shiro.realm.jdbc.JdbcRealm">
<property name="name" value="jdbcRealm" />
<property name="dataSource" ref="dataSource" />
<property name="credentialsMatcher">
<!-- The 'bootstrapDataPopulator' Sha256 hashes the password (using the
username as the salt) then base64 encodes it: -->
<bean class="org.apache.shiro.authc.credential.Sha256CredentialsMatcher">
<!-- true means hex encoded, false means base64 encoded -->
<property name="storedCredentialsHexEncoded" value="false" />
<!-- We salt the password using the username, the most common practice: -->
<property name="hashSalted" value="true" />
</bean>
</property>
<property name="authorizationCacheName" value="shiro.authorizationCache" />
</bean>
<!-- ========================================================= Shiro Spring-specific
integration ========================================================= -->
<!-- Post processor that automatically invokes init() and destroy() methods
for Spring-configured Shiro objects so you don't have to 1) specify an init-method
and destroy-method attributes for every bean definition and 2) even know
which Shiro objects require these methods to be called. -->
<bean id="lifecycleBeanPostProcessor" class="org.apache.shiro.spring.LifecycleBeanPostProcessor" />
<!-- Enable Shiro Annotations for Spring-configured beans. Only run after
the lifecycleBeanProcessor has run: -->
<bean
class="org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator"
depends-on="lifecycleBeanPostProcessor" />
<bean
class="org.apache.shiro.spring.security.interceptor.AuthorizationAttributeSourceAdvisor">
<property name="securityManager" ref="securityManager" />
</bean>
<!-- Secure Spring remoting: Ensure any Spring Remoting method invocations
can be associated with a Subject for security checks. -->
<bean id="secureRemoteInvocationExecutor"
class="org.apache.shiro.spring.remoting.SecureRemoteInvocationExecutor">
<property name="securityManager" ref="securityManager" />
</bean>
<!-- Define the Shiro Filter here (as a FactoryBean) instead of directly
in web.xml - web.xml uses the DelegatingFilterProxy to access this bean.
This allows us to wire things with more control as well utilize nice Spring
things such as PropertiesPlaceholderConfigurer and abstract beans or anything
else we might need: -->
<bean id="shiroFilter" class="org.apache.shiro.spring.web.ShiroFilterFactoryBean">
<property name="securityManager" ref="securityManager" />
<property name="loginUrl" value="/login" />
<property name="successUrl" value="/index" />
<property name="unauthorizedUrl" value="/unauthorized" />
<!-- The 'filters' property is not necessary since any declared javax.servlet.Filter
bean defined will be automatically acquired and available via its beanName
in chain definitions, but you can perform overrides or parent/child consolidated
configuration here if you like: -->
<!-- <property name="filters"> <util:map> <entry key="aName" value-ref="someFilterPojo"/>
</util:map> </property> -->
<property name="filterChainDefinitions">
<value>
/login = authc
/account = user
/manage = user,roles[admin]
</value>
</property>
</bean>
</beans>