二、權(quán)限系統(tǒng)的設(shè)計

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

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

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

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

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

1、粗粒度權(quán)限設(shè)計

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

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

l ????????? 權(quán)限

描述一個權(quán)限可以通過以下幾個要素說明：

類型（ class ） :

名稱（ name ）：

動作 (actions) ：

掩碼（ mask ）：

屬性：

具體權(quán)限 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 ） ：角色到權(quán)限的映射集合，表示某個角色可以在某些資源上執(zhí)行某些動作 ， 它們之間通過 role 關(guān)聯(lián)（繼承）， ACE 之間產(chǎn)生包含關(guān)系。

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

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

2、細粒度權(quán)限設(shè)計

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

1. ??????? 幾乎所有的授權(quán)需要用戶的角色和ID.

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

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

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

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

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

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

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

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

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

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

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

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

實現(xiàn)類：