熱門精品專業第三章. 協助系統
本章介紹一些Acegi Security使用的附加和協助系統。那些和安全無關，但是包含在Acegi Security項目中的部分，將會在本章中討論
3.1. 本地化
Acegi Security支持對終端客戶可能會看到的異常信息進行本地化。如果你的應用是為英文用戶設計的，那么你什么都不用做，因為Acegi Security的所有消息默認都是英文的。如果你要支持其他區域用戶，那么本節包含了你所需要了解的所有東西。
包括認證失敗或者訪問被拒絕（授權失敗）的所有異常消息都可以被本地化。提供給開發者或者系統部署人員的異常或者日志信息(包括錯誤的屬性、接口不符、構造器錯誤、debug級日志)沒有被本地化，它們硬編碼在Acegi Security的代碼中。
在acegi-security-xx.jar（譯注：xx代表版本號）的org.acegisecurity包中包含了一個 messages.properties文件。這個文件會被你的application context引用，因為Acegi Security實現了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并不多，因此本地化花不了多少工夫。如果你針對消息文件進行了本地化，那么請和社區分享，你可以添加一個JIRA任務，將你正確 命名的messages.properties本地化文件作為附件添加。
為了完善關于本地化的討論需要知道Spring的ThreadLocal org.springframework.context.i18n.LocaleContextHolder。你應該為每個用戶設置代表他區域的 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，而不是真正實現filter邏輯的filter。 FilterToBeanProxy所作的是代理Filter的方法到一個從Spring的application context 獲取的bean。這使得這個bean可以享受Spring application context的生命周期支持以及配置靈活性。這個bean必須實現javax.servlet.Filter。
FilterToBeanProxy只需要一個簡單的初始化參數，targetClass或者targetBean。targetClass會定位 application context中指定的類的第一個對象，而FilterToBeanProxy按照bean的名字定位對象。象標準的Spring web應用一樣，FilterToBeanProxy使用 WebApplicationContextUtils.getWebApplicationContext(ServletContext)來訪問 application context，所以你應該在web.xml中配置一個ContextLoaderListener。
在IoC容器而不是servlet容器中部署Filter會有一個生命周期的問題。特別是，哪個容器應該負責調用Filter的"startup" 和 "shutdown"方法？注意到Filter的初始化和析構順序隨servlet容器不同而不同，如果一個Filter依賴于由另一個更早初始化的 Filter的配置，這樣就會出現問題。另一方面，Spring IoC具備更加完善的生命周期/IoC接口（例如InitializingBean, DisposableBean, BeanNameAware, ApplicationContextAware以及其他許多）以及一個容易理解的接口契約（interface contract），可預見的方法調用順序，自動裝配支持，以及可以避免實現Spring接口的選項（例如Spring XML中的destroy-method 屬性）。因此，我們推薦盡可能使用Spring生命周期服務而不是servlet容器生命周期服務。FilterToBeanProxy默認不會將 init(FilterConfig) 和 destroy()方法委派到被代理的bean。如果你需要這些調用被委派，那么將lifecycle初始化參數設置為servlet- container-managed。
我們強烈推薦你使用FilterChainProxy而不是FilterToBeanProxy。雖然FilterToBeanProxy是一個非 常有用的類FilterToBeanProxy，問題是當web.xml中filter變多時，
- <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越早出現。在運行時，FilterChainProxy會定位符合當前的web請求的第一個URI模式。每個對應的配置屬 性代表了在application context中定義的一個bean的名字。接著fiter會按照它們被指定的順序，按照FilterChain的標準行為模式被調用(如果一個 Filter決定停止處理，它可以不在chain中執行)。
如你所見，FilterChainProxy需要為不同的請求模式重復配置filter的名字（在上面的例子中，, exceptionTranslationFilter 和 filterSecurityInterceptor 是重復的）。這樣的設計是為了讓FilterChainProxy能夠為不同的URI配置不同的filter調用順序，同時也提高了表達力（針對正則表達 式、Ant Paths、以及任何FilterInvocationDefinitionSource的特定實現）和清晰度，可以知道是哪個filter應該被調用。
你可能注意到了我們在filter chain定義了兩個HttpSessionContextIntegrationFilter (ASC是allowSessionCreation的縮寫,是HttpSessionContextIntegrationFilter的一個屬性)。 因為web服務不會為將來的請求提供一個jsessionid，為這樣的用戶創建HttpSessions是浪費的。如果你有一個需要最大限度的伸縮性的 高容量的應用，我們建議你使用上述的方法。對于小的應用，使用單一的HttpSessionContextIntegrationFilter (默認的allowSessionCreation設為true)應該足夠了。
說到生命周期問題，如果對FilterChainProxy自身調用init(FilterConfig) 和 destroy()方法，它會把它代理到底層的filter。這樣FilterChainProxy保證只初始化和析構每個filter一次，不論它在 FilterInvocationDefinitionSource中定義了多少次。你可以通過FilterToBeanProxy的lifecycle 初始化參數來控制這些方法是否被調用。如上面所討論的那樣，默認所有servlet容器生命周期調用是不被代理到FilterChainProxy的。
在web.xml中定義的filter的順序是非常重要的。不管你實際用到哪個filter，
1．ChannelProcessingFilter，因為可能要重定向到另一種協議。
2．ConcurrentSessionFilter 因為不使用任何SecurityContextHolder的功能，但是需要更新SessionRegistry來表示當前的發送請求的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使用前能夠及時被裝配。
安徽新華電腦學校專業職業規劃師為你提供更多幫助【在線咨詢】
