第三章. 協(xié)助系統(tǒng)

本章介紹一些Acegi Security使用的附加和協(xié)助系統(tǒng)。那些和安全無關，但是包含在Acegi Security項目中的部分，將會在本章中討論

3.1. 本地化

Acegi Security支持對終端客戶可能會看到的異常信息進行本地化。如果你的應用是為英文用戶設計的，那么你什么都不用做，因為Acegi Security的所有消息默認都是英文的。如果你要支持其他區(qū)域用戶，那么本節(jié)包含了你所需要了解的所有東西。

包括認證失敗或者訪問被拒絕（授權失敗）的所有異常消息都可以被本地化。提供給開發(fā)者或者系統(tǒng)部署人員的異常或者日志信息(包括錯誤的屬性、接口不符、構造器錯誤、debug級日志)沒有被本地化，它們硬編碼在Acegi Security的代碼中。

在acegi-security-xx.jar（譯注：xx代表版本號）的org.acegisecurity包中包含了一個 messages.properties文件。這個文件會被你的application context引用，因為Acegi Security實現(xiàn)了Spring的MessageSourceAware接口，它期待在application context啟動的時候注入一個message resolver。通常你所需要做的是在你的application context中注冊一個引用這個消息的bean，如下所示：

xml 代碼
 
<bean id="messageSource" class="org.springframework.context.support.ReloadableResourceBundleMessageSource">  
    <property name="basename"><value>org/acegisecurity/messagesvalue>property>  
bean>  

messages.properties是按照資源包標準命名的，它代表了Acegi Securtiy支持的默認語言。文件默認是英文的。如果你不注冊一個消息源，Acegi Security仍然可以正常工作，它會用回硬編碼的英文消息。

如果你想定制messages.properties文件，或者支持其他語言，那么你應該copy這個文件，然后重命名，并在上述的bean定義中 注冊。因為文件中的key并不多，因此本地化花不了多少工夫。如果你針對消息文件進行了本地化，那么請和社區(qū)分享，你可以添加一個JIRA任務，將你正確 命名的messages.properties本地化文件作為附件添加。

為了完善關于本地化的討論需要知道Spring的ThreadLocal org.springframework.context.i18n.LocaleContextHolder。你應該為每個用戶設置代表他區(qū)域的 LocaleContextHolder。Acegi Security會嘗試從這個ThreadLocal中獲取的Locale來從消息源中獲取消息。請參考Spring的文檔以獲取更多使用 LocaleContextHolder和能夠幫你自動設置它的輔助類(例如

AcceptHeaderLocaleResolver, CookieLocaleResolver, FixedLocaleResolver, SessionLocaleResolver 等)的詳細信息。

3.2. Filters

正如你在整個手冊中看到的那樣，Acegi Security使用很多filter。你可以使用FilterToBeanProxy或者FilterChainProxy來確定這些是怎樣加入到你的web應用中的，下面我們來看看。

大部分filter使用FilterToBeanProxy來配置。例如下面web.xml中配置所示：

xml 代碼
 
<filter>  
    <filter-name>Acegi HTTP Request Security Filter</filter-name>  
    <filter-class>org.acegisecurity.util.FilterToBeanProxy</filter-class>  
    <init-param>  
        <param-name>targetClass</param-name>  
        <param-value>org.acegisecurity.ClassThatImplementsFilter</param-value>  
    </init-param>  
</filter>  

注意在web.xml中的filter實際上是一個FilterToBeanProxy，而不是真正實現(xiàn)filter邏輯的filter。 FilterToBeanProxy所作的是代理Filter的方法到一個從Spring的application context 獲取的bean。這使得這個bean可以享受Spring application context的生命周期支持以及配置靈活性。這個bean必須實現(xiàn)javax.servlet.Filter。

FilterToBeanProxy只需要一個簡單的初始化參數(shù)，targetClass或者targetBean。targetClass會定位 application context中指定的類的第一個對象，而FilterToBeanProxy按照bean的名字定位對象。象標準的Spring web應用一樣，F(xiàn)ilterToBeanProxy使用 WebApplicationContextUtils.getWebApplicationContext(ServletContext)來訪問 application context，所以你應該在web.xml中配置一個ContextLoaderListener。

在IoC容器而不是servlet容器中部署Filter會有一個生命周期的問題。特別是，哪個容器應該負責調用Filter的"startup" 和 "shutdown"方法？注意到Filter的初始化和析構順序隨servlet容器不同而不同，如果一個Filter依賴于由另一個更早初始化的 Filter的配置，這樣就會出現(xiàn)問題。另一方面，Spring IoC具備更加完善的生命周期/IoC接口（例如InitializingBean, DisposableBean, BeanNameAware, ApplicationContextAware以及其他許多）以及一個容易理解的接口契約（interface contract），可預見的方法調用順序，自動裝配支持，以及可以避免實現(xiàn)Spring接口的選項（例如Spring XML中的destroy-method 屬性）。因此，我們推薦盡可能使用Spring生命周期服務而不是servlet容器生命周期服務。FilterToBeanProxy默認不會將 init(FilterConfig) 和 destroy()方法委派到被代理的bean。如果你需要這些調用被委派，那么將lifecycle初始化參數(shù)設置為servlet- container-managed。

我們強烈推薦你使用FilterChainProxy而不是FilterToBeanProxy。雖然FilterToBeanProxy是一個非 常有用的類FilterToBeanProxy，問題是當web.xml中filter變多時， 和 項就會太多而變得臃腫不堪。為了解決這個問題，Acegi Security提供一個FilterChainProxy類。它在FilterToBeanProxy中被裝配（正如上面例子中所示），但目標類 （target class）是org.acegisecurity.util.FilterChainProxy。這樣過濾器鏈（filter chain）可以在application context中按照如下代碼配置：

xml 代碼
 
<bean id="filterChainProxy" class="org.acegisecurity.util.FilterChainProxy">  
    <property name="filterInvocationDefinitionSource">  
        <value>  
            CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON  
            PATTERN_TYPE_APACHE_ANT  
            /webServices/*=httpSessionContextIntegrationFilterWithASCFalse,basicProcessingFilter,exceptionTranslationFilter,  
            /*=httpSessionContextIntegrationFilterWithASCTrue,authenticationProcessingFilter,exceptionTranslationFilter,filterSecurityInterceptor  
        value>  
    property>  
bean>  
    

你可能注意到FilterSecurityInterceptor定義方式的相似之處。同時支持正則表達式和Ant Paths格式，越對應的URI越早出現(xiàn)。在運行時，F(xiàn)ilterChainProxy會定位符合當前的web請求的第一個URI模式。每個對應的配置屬 性代表了在application context中定義的一個bean的名字。接著fiter會按照它們被指定的順序，按照FilterChain的標準行為模式被調用(如果一個 Filter決定停止處理，它可以不在chain中執(zhí)行)。

如你所見，F(xiàn)ilterChainProxy需要為不同的請求模式重復配置filter的名字（在上面的例子中，, exceptionTranslationFilter 和 filterSecurityInterceptor 是重復的）。這樣的設計是為了讓FilterChainProxy能夠為不同的URI配置不同的filter調用順序，同時也提高了表達力（針對正則表達 式、Ant Paths、以及任何FilterInvocationDefinitionSource的特定實現(xiàn)）和清晰度，可以知道是哪個filter應該被調用。

你可能注意到了我們在filter chain定義了兩個HttpSessionContextIntegrationFilter (ASC是allowSessionCreation的縮寫,是HttpSessionContextIntegrationFilter的一個屬性)。 因為web服務不會為將來的請求提供一個jsessionid，為這樣的用戶創(chuàng)建HttpSessions是浪費的。如果你有一個需要最大限度的伸縮性的 高容量的應用，我們建議你使用上述的方法。對于小的應用，使用單一的HttpSessionContextIntegrationFilter (默認的allowSessionCreation設為true)應該足夠了。

說到生命周期問題，如果對FilterChainProxy自身調用init(FilterConfig) 和 destroy()方法，它會把它代理到底層的filter。這樣FilterChainProxy保證只初始化和析構每個filter一次，不論它在 FilterInvocationDefinitionSource中定義了多少次。你可以通過FilterToBeanProxy的lifecycle 初始化參數(shù)來控制這些方法是否被調用。如上面所討論的那樣，默認所有servlet容器生命周期調用是不被代理到FilterChainProxy的。

在web.xml中定義的filter的順序是非常重要的。不管你實際用到哪個filter，的順序應該是如下所示的：

1．ChannelProcessingFilter，因為可能要重定向到另一種協(xié)議。

2．ConcurrentSessionFilter 因為不使用任何SecurityContextHolder的功能，但是需要更新SessionRegistry來表示當前的發(fā)送請求的principal。

3． HttpSessionContextIntegrationFilter, 這樣當一個web請求開始的時候就可以在SecurityContextHolder中設置一個SecurityContext，當web請求結束的時候 任何對SecurityContext的改動都會被copy到HttpSession（以備下一個web請求使用）。

4．Authentication processing mechanisms - AuthenticationProcessingFilter, CasProcessingFilter, BasicProcessingFilter, HttpRequestIntegrationFilter, JbossIntegrationFilter 等 - 修改SecurityContextHolder，使其中包含一個有效的認證請求令牌（token）。

5．SecurityContextHolderAwareRequestFilter, 如果你使用它來在你的servlet容器中安裝一個Acegi Security aware HttpServletRequestWrapper。

6．RememberMeProcessingFilter, 如果早期的認證處理過程沒有更新SecurityContextHolder，并且請求（request）提供了一個cookie啟用remember- me服務，一個合適的被記住的Authentication對象會被放到SecurityContextHolder那里。

7．AnonymousProcessingFilter, 如果早期的認證處理過程沒有更新SecurityContextHolder，, 一個匿名Authentication 對象會被放到SecurityContextHolder那里。

8．ExceptionTranslationFilter, 捕獲所有的Acegi Security 異常，這樣要么返回一個HTTP錯誤響應或者加載一個對應的AuthenticationEntryPoint。

9．FilterSecurityInterceptor, 保護 web URIs

所有上述的filter使用FilterToBeanProxy或FilterChainProxy。建議在一個應用中使用一個單個的 FilterToBeanProxy代理到一個單個的FilterChainProxy。，在FilterChainProxy中定義所有的Acegi Security Filters。如果你使用SiteMesh，確保Acegi Security filters 在 SiteMesh filters調用前調用。這樣使SecurityContextHolder在SiteMesh decorator使用前能夠及時被裝配。