目前有關使用者許可權採用的比較多的都是基於rbac模型，即通過對角色許可權的定義完成對使用者許可權的限制。有關功能許可權部分想必都比較清楚，就是將系統的功能模組劃分清楚，並賦予不同角色的訪問許可權，這樣在使用者訪問某個功能模組之前進行許可權校驗即可。但是有關資料許可權部分卻一直比較模糊。
在如下這篇文章中給出乙個許可權模型，裡面提到了資料許可權的建模。
這個模型中有關資料許可權也是對角色進行許可權限定。模型中定義了幾個概念：
資源：使用者將要訪問的資料物件（如使用者）
資料物件型別：對使用者將要訪問的資料物件的限定型別（如部門）
資源資料物件型別：上面兩個概念關聯產生的，即使用者要訪問什麼型別的資料物件（如××部門的使用者，但是此時的××是通用的，只有將資料物件型別具體化之後××才會出現）。
將上面的資源資料物件型別例項化（即××具體化）之後就形成了一條資料物件訪問規則，將這條規則附加給某個角色就完成了對角色資料訪問許可權的限定。這個模型定義是很清楚的，但是如何具體實現，其實是乙個比較複雜的問題。
乙個比較直觀的想法就是在業務層之上加乙個資料許可權校驗層。
上面定義的資料物件型別其實就是使用者訪問的資料物件的屬性，因此在校驗的時候確定相關資料物件的屬性是否滿足使用者資料許可權規則即可，對於增刪改就是操作之前校驗，對於查詢就需要對查詢結果過濾。當然為了整個實現的簡單需要確保系統中的所有資料物件class都是從乙個class中繼承而來限制是。這一想法實現起來比較簡單，但是有乙個限制和乙個效能憂慮。限制就是為了保證規則校驗的進行，必須使得所有資料物件都應當具有許可權規則定義的相應屬性，如果規則定義的屬性發生變化，勢必需要所有資料物件的生成方法發生變化。效能憂慮就是對查詢結果的過濾，其實在一般的mis系統中多數情況是進行查詢，但是如果依照這種方法進行結果過濾的話，可能會存在效能的問題。
因此，這一想法具有緊耦合和效能問題。
另外乙個想法依然無法避免緊耦合，但是可以避免效能問題。然而在邏輯上就沒有上面那個直觀了。這一想法就是將資料許可權規則轉成sql語句，嵌入到資料訪問層中去。
因為資源必定會對應到某乙個資料表，而資料物件型別也會對應的到某個資料表的某個屬性列，因此完全可以依據資料許可權規則動態生成sql語句。資料許可權規則可以如下定義：【資源資料物件型別 關係符 右值】，右值可以分為靜態和動態兩種：靜態就是乙個具體的值；動態就是使用者的某個屬性，這只有在與使用者關聯上之後才能確定。但是由於乙個角色可以有多條資料許可權規則，那麼他們之後可以是與和或的關係，多個規則之間可能存在衝突，必須進行避免，如：當規則之間是與關係時，如果資源資料物件型別和關係符都相同時，就有可能衝突。具體的說就是要限制角色r只能訪問a部門的使用者且只能訪問b部門的使用者，這樣子勢必是相互衝突的。
在資料訪問層呼叫乙個統一的sql生成方法，傳入兩個引數：不加限定是要訪問的資料表名和角色資料許可權規則集（此時的規則集中應當已經具有準確的右值，即如果是動態的也已經根據使用者屬性賦值了）。方法是：依次判斷規則集中的規則是否有要訪問的資料表名，如果有就生成sql語句的from子句和where子句，最終語句規則集關係符（and | or）生成from子句和where子句返回。
資料訪問層獲得許可權校驗產生的from子句和where子句嵌入到資料訪問方法中去，這樣就將資料訪問和許可權校驗結合在一起了。明顯是緊耦合，但是規避了效能問題。
因此，上面兩個想法各有個的優勢，但是同樣都有一定的問題，是不是有更好的辦法？
通用資料許可權的思考與設計
1 資料許可權概述 1.1 什麼是資料許可權？資料許可權是指對系統使用者進行資料資源可見性的控制，通俗的解釋就是 符合某條件的使用者只能看到該條件下對應的資料資源。那麼最簡單的資料許可權大概就是 使用者只能看到自己的資料。而在正式的系統環境中，會有很多更為複雜的資料許可權需求場景，如 上述這些需求，...
設定字段許可權 通用資料許可權的思考與設計
1 資料許可權概述 1.1 什麼是資料許可權？資料許可權是指對系統使用者進行資料資源可見性的控制，通俗的解釋就是 符合某條件的使用者只能看到該條件下對應的資料資源。那麼最簡單的資料許可權大概就是 使用者只能看到自己的資料。而在正式的系統環境中，會有很多更為複雜的資料許可權需求場景，如 上述這些需求，...
資料許可權設計
資料許可權設計思考目前有關使用者許可權採用的比較多的都是基於rbac模型 目前有關使用者許可權採用的比較多的都是基於rbac模型，即通過對角色許可權的定義完成對使用者許可權的限制。有關功能許可權部分想必都比較清楚，就是將系統的功能模組劃分清楚，並賦予不同角色的訪問許可權，這樣在使用者訪問某個功能模組...