一、???????????? 考慮實現

1、? 系統權限考慮繼續采用原先實現方式，在構造功能樹和樹狀菜單時作出權限判斷；

2、? 數據庫操作權限考慮應用 Acegi 擴展，在業務層對相應的瀏覽 / 增加 / 修改 / 刪除的業務方法進行攔截；

3、? 行級數據權限考慮采用 AOP 的方式在用戶訪問相關資源時根據用戶權限動態構造 SQL 注入到業務方法里，再由業務方法傳遞到 DAO 里；

4、? 列級數據權限考慮做入頁面，這里不再討論。

5、? 大集中模式下的權限管理，本質也是行級數據權限，即在每次數據訪問時都需要強制判斷用戶所屬部門 Group 。

一、 權限管理詳細解決方案

用戶、用戶組、角色設計如下：

Principal 即為權限主體

1、? 系統權限授權

web 頁面：

頁面上顯示兩棵樹：左側顯示用戶、用戶組和角色樹，右側顯示功能模塊樹，功能模塊樹的節點上跟兩個復選框，分別是可見 / 可再授權。點擊用戶、用戶組和角色樹上的節點對相應權限主體進行授權。

很顯然可再授權權限包含可見權限。

數據庫實現：

用 ACL 實現，表設計如下：

資源 ID ，權限主體 ID ，權限主體 TYPE ，資源 TYPE ，資源操作權限，條件查詢語句 queryStr 。

說明：

權限主體 TYPE? 三種： user/group/role

資源 TYPE??? ???? 兩種： function/method? 此時對系統權限來說是 function

條件查詢語句 queryStr??? 數據范圍控制 ? 此時對系統權限該字段無效

對象：

用戶保存授權信息時，先刪除該權限主體 ID 的授權記錄，再更新。

2、? 數據庫操作權限授權

這里引入一個新的對象：數據庫操作資源對象 ? DataResource

表設計如下：

ID ， NAME ， parentId ， resStr ， resType ， desc

說明如下：

ID

NAME 資源名稱 例如：新增用戶

parentId

resStr? 業務方法地址 例如： com.way.sevice.UserService.addUser

resType 資源類型，分兩種： abstract/detail? 抽象 / 具體

desc? 描述說明

例子：

對用戶管理進行數據庫操作權限授權

新建“用戶管理”做父節點，選擇資源類型為“抽象”

在“用戶管理”下再依次新增“新增用戶”、“瀏覽用戶”、“修改用戶”、“刪除用戶”四個子節點，選擇資源類型為“具體”

如果系統自己來判斷存儲就是葉子節點是“具體”，其他為“抽象”

web 頁面：

頁面上顯示兩棵樹：左側顯示用戶、用戶組和角色樹，右側顯示數據庫操作資源對象樹，數據庫操作資源對象樹的葉子節點的一級父節點上跟一個數據范圍限定 button ，點擊后彈出窗口輸入限定條件；葉子節點上跟一個復選框。點擊用戶、用戶組和角色樹上的節點對相應權限主體進行授權

授權信息存入 ACL 表中

資源 TYPE 為 method

3、? 行級數據權限授權

已在上面做了說明即數據范圍限定

4、? 大集中模式下的權限授權

其實所謂大集中模式控制的也不過是數據范圍，考慮是所有相關表全部增加 groupId 字段，新增時添入該字段，讀出時進行判斷

web 頁面：

“組織和用戶管理”模塊中，每個組織中都允許設定一個管理員，一旦設定管理員，該組織就進入大集中模式，即所有該組織的數據與其他同級組織互相隔離，僅上級組織可見。同時說明一點的是：該管理員與系統總的管理員權限一樣，不同的是數據范圍僅限制與該組織內部。

綜述：

實際的授權部分采用了 ACL ，所以授權比較簡單和直觀

系統資源和數據庫操作資源分開兩個表存儲，這樣可能會給用戶帶來不便，也就是授權時還需要切換，但這種不便似乎不好解決，因為一個是粗粒度的一個是細粒度的。

http://www.aygfsteel.com/ronghao 榮浩原創，轉載請注明出處：）