摘要

Acegi提供了多種身份驗證方式（表單驗證，CAS等），但只允許一種用戶登錄，而就個人了解，有一些系統(tǒng)是需要多種用戶登錄的。比如企業(yè)的員工需要登錄并使用系統(tǒng)，企業(yè)也允許客戶登錄系統(tǒng)并使用有限的功能。以下嘗試剖析Acegi的表單驗證過程，并給出一種允許多種用戶登錄的方案。本方案基本達到“能用”的目的，但不一定是最佳方案。希望這篇文章能起到拋磚引玉的作用，給各位朋友一點參考，也希望各位提出有益的建議。

Acegi的表單驗證方式簡要分析

一個使用Acegi的表單驗證的登錄頁面通常需要在表單提交時request的j_username和j_password參數賦值，即用戶名和密碼，而表單則提交到Acegi設定到驗證地址。例如：


服務器的Servlet容器收到請求后會傳遞給Acegi的FilterToBeanProxy，這需要在web.xml中進行配置。例如：


FilterToBeanProxy基本上只起到調用轉發(fā)的作用。在它的doFilter方法中會找到類型為FilterChainProxy的bean，調用后者的doFilter方法，同時把request、response會chain參數都傳遞過去。代碼如下：


上面的代碼中的delegate就是找到的類型FilterChainProxy的bean。FilterChainProxy的典型配置如下：


對于上面的配置，引用一段Acegi聯機幫助中的說明來幫助理解：

Internally Acegi Security will use a PropertyEditor to convert the string presented in the above XML fragment into a FilterInvocationDefinitionSource object. What's important to note at this stage is that a series of filters will be run - in the order specified by the declaration - and each of those filters are actually the <bean id> of another bean inside the application context.

實際上，FilterChainProxy的doFilter方法會執(zhí)行如下處理：
1.讀取配置，如果配置為空，則直接調用chain.doFilter，返回
2.如果配置不為空，則根據配置找到各個bean，放入Filter數組中。如果配置中沒有配置任何bean，則直接調用chain.doFilter，返回
3.FilterChainProxy創(chuàng)建一個VirtualFilterChain對象，并將chain封裝為一個FilterInvocation對象，將它和Filter數組一起傳遞給VirtualFilterChain的構造函數。VirtualFilterChain的構造函數初始化了一個指針currentPosition，指向Filter數組的第一個元素additionalFilters[0]
4.FilterChainProxy調用VirtualFilterChain的doFilter方法，在該方法中將指針currentPosition前移，調用additionalFilters[0]的doFilter方法。注意這里VirtualFilterChain把自身作為參數傳遞給additionalFilters[0]的doFilter方法，這樣additionalFilters[0]的doFilter方法最后會調用VirtualFilterChain的doFilter方法，這樣控制就又回到了VirtualFilterChain！于是VirtualFilterChain又將currentPosition前移，調用additionalFilters[1]的doFilter方法......
5.當additionalFilters中所有元素的doFilter都執(zhí)行完畢，VirtualFilterChain執(zhí)行fi.getChain().doFilter，而fi.getChain()的值就是FilterChainProxy的doFilter方法中的參數chain的值。這樣我們就理解了FilterChainProxy是怎樣讓調用兜了個圈，又傳遞出去的。

重新回到FilterChainProxy的配置，看到它調用了authenticationProcessingFilter這個Filter。讓我們看看它的配置：


authenticationProcessingFilter的其中一個作用就是獲取客戶端提交的用戶名和密碼，將它們封裝為一個Token，傳遞給authenticationManager的authenticate方法，由后者負責驗證。

看看authenticationManager的配置：


authenticationManager依次調用每個provider的authenticate方法。如果某個provider驗證成功則返回；如果所有的驗證都不成功，則拋出異常。

讓我們看看daoAuthenticationProvider的配置：


daoAuthenticationProvider在authenticate方法中調用retrieveUser方法取得用戶信息，執(zhí)行基本的驗證，然后調用additionalAuthenticationChecks執(zhí)行附加的驗證（比如驗證密碼是否正確）。在retrieveUser方法中調用userDetailsService的loadUserByUsername方法取得用戶信息，而userDetailsService是一個名為userDao的bean。讓我們看看userDao的配置：


userDao實現了Acegi的UserDetailsService接口，該接口只有l(wèi)oadUserByUsername方法。loadUserByUsername方法根據傳入的username取得相應的Employee對象(Employee實現了UserDetails接口)，該對象返回給daoAuthenticationProvider，由它和authenticationManager聯合完成驗證的任務。

以上對Acegi對表單驗證過程進行了簡單對分析，限于篇幅，無法深入分析源碼。但從配置可以畫出驗證過程的對象圖如下：



從圖中可以看出，盡管Acegi調用了多個Filter來完成驗證過程，關鍵點卻在三處：
1.在客戶端輸入身份驗證信息，包括用戶名和密碼
2.AuthenticationProcessingFilter取出用戶名和密碼，封裝為一個Token往后傳遞
3.DaoAuthenticationProvider從系統(tǒng)中找出用戶資料，并和ProviderManager一起執(zhí)行驗證

實現多種用戶登錄

很明顯，要讓系統(tǒng)識別不同種類的用戶，必須設立一個用戶類型標志。問題就轉化為：
1.用戶在客戶端輸入身份信息時系統(tǒng)就必須設立相應的標志
2.該標志如何傳遞到DaoAuthenticationProvider
3.DaoAuthenticationProvider如何識別該標志，并從相應類型的用戶中找到指定用戶

我不打算改動Acegi的源碼，只打算擴展出我需要的功能。

首先在登錄頁面中加入用戶類型標志j_userkind。在登錄頁面中加入如下代碼：


其中0代碼員工，1代碼客戶。可以考慮在登錄頁面中增加一個選項，如果用戶要以員工身份登錄，則把j_userkind置為0；如果用戶要以客戶身份登錄，則把j_userkind置為1。也可以提供兩個登錄頁面，其中一個員工專用（j_userkind被強制置為0），另一個客戶專用（j_userkind被強制置為1）

系統(tǒng)如何根據收到的用戶類型標志去讀取指定的用戶呢？如果在代碼中寫死（比如當用戶類型標志=0時，讀取員工；當用戶類型標志=1時，讀取客戶）非常不好，還是通過配置來確定比較靈活。首先編寫UserKindComparisonAware接口：


該接口說明實現類需要實現兩個方法，setExpectedUserKind用于接受一個期望的用戶類型標志（通常該標志通過配置來設置），setCurrentUserKind用于接受當前登錄用戶的用戶類型標志（系統(tǒng)在運行時捕獲，并傳遞給實現類）

編寫MKUDaoAuthenticationProvider類：


該類繼承自DaoAuthenticationProvider并實現UserKindComparisonAware接口，在additionalAuthenticationChecks方法中判斷當前登錄用戶的用戶類型標志與期望的用戶類型標志是否一致，如果一致則執(zhí)行父類的additionalAuthenticationChecks，完成驗證；否則拋出一個BadUserKindException異常，表明驗證失敗。BadUserKindException繼承自org.acegisecurity.AuthenticationException，具體的代碼略

在applicationContext.xml中刪除daoAuthenticationProvider相關的配置，增加如下配置：


可以看出customerDaoAuthenticationProvider僅用于驗證客戶（其expectedUserKind被指定為1），而userDaoAuthenticationProvider僅用于驗證員工（其expectedUserKind被指定為0）。customerDao的配置如下：


CustomerDaoHibernate的代碼如下：



可以看出CustomerDaoHibernate是取得一個Customer對象（實現了UserDetails接口），而不是Employee。

修改authenticationManager的配置如下：


在哪里捕獲當前登錄用戶的用戶類型標志，并傳遞給MKUDaoAuthenticationProvider呢？我決定增加一個名為PreAuthenticationProcessingFilter的Filter，放在AuthenticationProcessingFilter之前，代碼如下：


PreAuthenticationProcessingFilter需要在初始化參數中指定targetClass，該參數的值是一個類，該類實現了UserKindComparisonAware接口。PreAuthenticationProcessingFilter找到容器中所有該類的實例，并把捕獲的當前登錄用戶的用戶類型標志賦值給它們。PreAuthenticationProcessingFilter的配置如下：


還需要把preAuthenticationProcessingFilter加入到filterChainProxy的配置中：



注意把它放在authenticationProcessingFilter的前面

至此我們初步實現了使用Acegi實現多種用戶登錄