在討論訪問控制時，我們已經簡單地看過`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。