二、權限系統(tǒng)的設計

權限往往是一個極其復雜的問題， 設計權限系統(tǒng)第一個要解決的問題就是什么樣的行為是需要權限控制，什么樣的是業(yè)務方法。他們之間本來是沒有明確的區(qū)分，任何權限從某種角度上說可以是一種業(yè)務方法。為了以后管理和開發(fā)方面我們從概念上需要將權限和業(yè)務明確劃分清楚，指導開發(fā)。

權限控制行為 ：??對What(Which)進行How的操作需要區(qū)分 Who ，具有 Who 身份差異性和可替換性。 ?? 我們將此類操作作為權限。

????? 特點：可以收回也可以分配的，具有一定的抽象級別。 ??????? 消耗資源，行為結果具備一些持久性的影響。

業(yè)務邏輯行為 ：??對What(Which)進行How的操作的時候與Who的身份無關或者具有 Who 身份差異性但?????????????是不具有可替換性。

????特點：不能抽象和共享，很難回收和分配。不消耗資源，不產(chǎn)生持久性。現(xiàn)實中也存在某一時期行為是業(yè)務邏輯，最后演變成權限控制，或者相反的過程。

1、粗粒度權限設計

??????? 采用 自主型訪問控制方法，操作給予訪問控制列表。 每一個用戶通過角色獲得一組權限集合，權限系統(tǒng)的功能是驗證用戶申請的權限（集合）是否在這個集合當中，即申請的權限（集合）是否投影在用戶擁有的權限集合 , 換句話說： 只要某用戶直接或者間接的屬于某個Role那么它就具備這個Role的所有權限許可。

一個 自主型訪問控制方法的權限系統(tǒng)包括以下幾個部分：角色、權限、訪問控制表、

l ????????? 權限

描述一個權限可以通過以下幾個要素說明：

類型（ class ） :

名稱（ name ）：

動作 (actions) ：

掩碼（ mask ）：

屬性：

具體權限 Example:

1 、 Test

類型（ class ） :com.yangjs.secutiry. permissions. TestPermission

名稱（ name ）：如： test.* ， test.sub.* ,test.sub1.sub2

動作 (actions) ： brower_detail ,post,repost,……

掩碼（ mask ）： 0x1,0x2,0x4…..

屬性： 無

l ????????? 存取控制器（ my--acl.xml ）配置

存取控制項（ ACE ） ：角色到權限的映射集合，表示某個角色可以在某些資源上執(zhí)行某些動作 ， 它們之間通過 role 關聯(lián)（繼承）， ACE 之間產(chǎn)生包含關系。

存取控制列表（ ACL ）： ACE 的集合。

我們的存取控制器（ ACL ）是通過一個 xml 的配置文件說明，存取控制列表由多個存取控制項（ ACE ）來描述。 使用方法 (略）

2、細粒度權限設計

????細粒度授權需要上下文的支持，而且每個權限控制的上下問題都不一樣，這由相關的業(yè)務邏輯決定，而且此類授權一般變化較快，應此需要將強的可維護性和擴展性，支持變化，但又不能夠太復雜，否則缺乏可執(zhí)行性。雖然此類權限個性化較強，我們?nèi)匀豢梢钥偨Y出很多共性：

1. ??????? 幾乎所有的授權需要用戶的角色和ID.

2. ??????? 特定的上下文幾乎都同用戶資源使用情況相關.

???我們將此類信息稱為UserState 即：User角色以及資源使用情況和當前狀態(tài)。大部分信息我們在用戶登陸的時候已經(jīng)。獲得。授權貫穿Web層和Biz層，因此我們的登陸要獨立于Web端。因此上下文我們可以用UserState結合其他來抽象。

???關于上下文的維護問題，我們不可能將UserState此類參數(shù)在Web層和Biz層來回傳遞，更加不能在需要授權的地方都加上一個這樣的方法參數(shù)，這樣不太現(xiàn)實。其次如果在授權的地方再從數(shù)據(jù)庫中取一次這樣雖然能夠解決部分問題（不能解決userId的傳遞），這樣效率太低，不能接受。

??????? 解決方法就是將此類信息 cache 起來，用的時候再去取，由于此類信息具有非常高的并發(fā)性，對線程安全較高，因此我們決定將此類信息放入一個線程上下文的內(nèi)存 cache 中。此外我們由于引入 cache ，就需要解決所有 cache 共有的維護性問題。

???????Cache 的生命周期：用戶的一次請求，屬于線程級，用戶請求線程結束， Cache 結束。

???????Cache 的更新：當上下文信息發(fā)生變化是需要及時更新 Cache ，這是一個不可避免的步驟。

??????? Cache 丟失：發(fā)生在如系統(tǒng) down 機，線程崩潰，內(nèi)存溢出等等，對用戶來說就是當前請求突然中斷。

??????? 當用戶重新發(fā)送請求，我們的系統(tǒng)就需要重新驗證用戶，此時我們可以更新 Cache 解

??????? 決丟失問題。

???????Cache 的清理：這個實現(xiàn)就是當用戶請求結束，返回應答的時候清理，可以通過 Filter 實現(xiàn)，比較簡單。

以上是相關的原理部分，我們看看系統(tǒng)地實現(xiàn)：

實現(xiàn)： 線程上下文的 cache

實現(xiàn)類：