在讨论访问控制时，我们已经简单地看过`FilterSecurityInterceptor`，我们已经将它与命名空间一起使用，其中`<intercept-url>`元素被组合在内部进行配置。 现在我们将看到如何显式配置它以与`FilterChainProxy`一起使用，以及它的伴随过滤器`ExceptionTranslationFilter`。 典型配置示例如下所示： ~~~ <bean id="filterSecurityInterceptor" class="org.springframework.security.web.access.intercept.FilterSecurityInterceptor"> <property name="authenticationManager" ref="authenticationManager"/> <property name="accessDecisionManager" ref="accessDecisionManager"/> <property name="securityMetadataSource"> <security:filter-security-metadata-source> <security:intercept-url pattern="/secure/super/**" access="ROLE_WE_DONT_HAVE"/> <security:intercept-url pattern="/secure/**" access="ROLE_SUPERVISOR,ROLE_TELLER"/> </security:filter-security-metadata-source> </property> </bean> ~~~ `FilterSecurityInterceptor`负责处理HTTP资源的安全性。它需要引用`AuthenticationManager`和`AccessDecisionManager`。它还提供了适用于不同HTTP URL请求的配置属性。请参阅技术介绍中有关这些内容的原始讨论。 `FilterSecurityInterceptor`可以通过两种方式配置配置属性。第一个（如上所示）使用`<filter-security-metadata-source>`命名空间元素。这类似于命名空间章节中的`<http>`元素，但`<intercept-url>`子元素仅使用`pattern` 和 `access`属性。逗号用于分隔适用于每个HTTP URL的不同配置属性。第二个选项是编写自己的`SecurityMetadataSource`，但这超出了本文档的范围。无论使用何种方法，`SecurityMetadataSource`都负责返回包含与单个安全HTTP URL关联的所有配置属性的`List <ConfigAttribute>`。 应该注意的是，`FilterSecurityInterceptor.setSecurityMetadataSource（）`方法实际上需要`FilterInvocationSecurityMetadataSource`的实例。这是一个标记接口，它是`SecurityMetadataSource`的子类。它只是表示`SecurityMetadataSource`了解`FilterInvocation`。为了简单起见，我们将继续将`FilterInvocationSecurityMetadataSource`称为`SecurityMetadataSource`，因为区别与大多数用户没有多大关系。 由命名空间语法创建的`SecurityMetadataSource`通过将请求URL与配置的 `pattern`属性相匹配来获取特定`FilterInvocation`的配置属性。这与命名空间配置的行为方式相同。缺省情况是将所有表达式视为Apache Ant路径，并且对于更复杂的情况也支持正则表达式。` request-matcher`属性用于指定正在使用的模式的类型。无法在同一定义中混合表达式语法。例如，使用正则表达式而不是Ant路径的先前配置将编写如下： ~~~ <bean id="filterInvocationInterceptor" class="org.springframework.security.web.access.intercept.FilterSecurityInterceptor"> <property name="authenticationManager" ref="authenticationManager"/> <property name="accessDecisionManager" ref="accessDecisionManager"/> <property name="runAsManager" ref="runAsManager"/> <property name="securityMetadataSource"> <security:filter-security-metadata-source request-matcher="regex"> <security:intercept-url pattern="\A/secure/super/.*\Z" access="ROLE_WE_DONT_HAVE"/> <security:intercept-url pattern="\A/secure/.*\" access="ROLE_SUPERVISOR,ROLE_TELLER"/> </security:filter-security-metadata-source> </property> </bean> ~~~ 始终按照定义的顺序评估模式。 因此，重要的是在列表中定义的更具体的模式比不太具体的模式更高。 这反映在上面的示例中，其中更具体 `/secure/super/`模式看起来高于不太具体 `/secure/`。 如果它们被反转，则`/ secure /` pattern将始终匹配，并且永远不会使用`/ secure / super /` pattern。