關於權限控制策略的討論

表結構為user--role--menu。
我要實現的功能是：
1.對系統菜單（頁面）的控制，不可訪問的不顯示；
2.對頁面上的具體操作進行控制，如該用戶對該模塊只有查詢權限，不能修改、刪除。
對於第一點，我可以做到。根據當前登錄的用戶，獲取他擁有的角色，進而獲取他可訪問的全部模塊列表，顯示這些可以訪問的模塊。
對 於第二點，我有個想法，在數據庫中，對模塊的訪問設定級別，1-全部操作；2-只能查詢。這樣的話，顯示頁面時，判斷該用戶對該頁面的訪問級別，若為1， 顯示“增加、刪除”按鈕，若為2，只顯示查詢按鈕。但這樣的話，實際上時把權限控制的代碼寫到了各個頁面，很不雅觀。

對合同管理模塊，我們在公司權限系統中新增了五種角色：合同錄入人、合同查閱人、合同審核人、合同管理員、超級管理員。在合同管理權 限設置中，對員工賦角色，一個角色可能有多個員工，而一個員工可能也有多個角色。然後設置一員工所能夠管理的部門。基本業務邏輯是，誰（員工）對何部門有 何權限（5種角色）。

上述系統涉及到以下幾張表：

1.角色表。 （ID），角色名，描述。
2.用戶表。 （HrID），描述。
3.部門表。 （DeptID），描述。
4.部門-角色-用戶表。 （ID，HrID，DeptID）。

在表4中，完成上述的業務邏輯，也即“誰對何部門有何權限”。這裡的權限是用角色名來標識，比如合同錄入人這個角色，擁有合同錄入的 權限，合同查閱人這個角色，擁有查閱合同的權限。而部門的樹形結構，則是依賴於DeptID。 DeptID由12位數字構成，每兩個1組，由左至右分別對應部門的級別。比如010500000000代表**公司**部門。實際使用時，通過like ‘01%’，like ’0105%‘判斷員工所管理的部門（個人認為，這里相當Cool）。

我們用公司現有的權限系統來管理角色，增加部門-角色-用戶映射表來管理權限，在前台頁面中完成用戶的授權。這種設計結構相對清 楚，但在應對高靈活的情況是，可能力不從心，比如要增加合同確認這一功能，那麼必須在增加合同確認人角色等。所以有以下一些考慮。

1.將角色和角色所具有的操作分離，常見的操作包括Insert（新增），Select（查看），Update（更新），Delete等操作。用一個素數 對應這四個操作，分別為2，3，5，7。將角色和操作的對應關係放入數據庫。比如合同錄入人所擁有的操作對應2，而合同查閱人對應3，合同審核人對應3， 合同管理員對應3*7。在Unix系統中，採用1，2，4對應讀、寫、執行三種操作，將這三種標識碼相加，對應組合操作。
2.角色體現在業務流程上，如審核人只有讀的操作，流程上可以對一個合同審核通過，或者是駁回重填。

在《關於權限系統的探討》一文中，還考慮了“限定內容列表”，以區分能夠被操作的表、字段。由（ID）、名稱、描述構成。比如在我們的這個合同管理系統中，可能就是A用戶可以修改數據庫裡的這幾個表，而B用戶只能修改數據庫裡的那幾個表。

Simple is beautiful！ 發覺自己思路開始混亂。這樣設計複雜，同時和原有的系統並不兼容，純屬遐想。

http://topic.csdn.net/t/20030413/09/1653829.html