大話設計，沒有模式—通用權限設計與實現

當代碼寫多了，總有些是經驗，但經驗是什麼呢？if…else用的次數比別人多？顯然不是。有些超棒的設計能夠謂之經驗！

功能權限
網絡上流行的經典的權限設計是【主體】- 【領域】 - 【權限】( who、what、how問題原型 ) 的設計思想，其中：

【主體】能夠是用戶，能夠是角色，也能夠是一個部門

【領域】能夠是一個模塊，能夠是一個頁面，也能夠是頁面上的按鈕

【權限】能夠是「可見」，能夠是「只讀」，也能夠是「可用」(如按鈕能夠點擊)

爲了簡化程序開發，在OpenAuth.Core中去掉了權限的控制，簡化爲【主體】- 【領域】的模式，且【主體】限定爲角色。即只能給角色分配模塊和按鈕，不能直接分配給用戶帳號或部門。且一旦分配即表示該角色擁有操做該模塊（按鈕）的權限。

大道至簡，標準的RBAC規範比這個還要簡潔，因此它的生命力才最頑強。在此基礎上，若是進行二次開發，進行更詳細的功能權限控制，能夠按照上面的思想進行改造。

數據權限
數據權限是在功能權限的基礎上面進一步的擴展，好比能夠查看訂單屬於【功能權限】的範圍，可是能夠查看哪些訂單就是【數據權限】的工做了。

這裏面的幾個概念：

【資源】：數據權限的控制對象，業務系統中的各類資源。好比訂單單據、銷售單等。

【數據規則】：用於數據權限的條件規則 。

應用場景

銷售單，能夠由本人查看
銷售單，測試角色能看到本身的訂單
銷售單，測試角色能看到本身的訂單，管理員角色能夠看到全部訂單
銷售單，測試角色能看到本身的訂單，管理員角色能夠看到全部訂單，帳號test3能夠看到應用名稱爲"xxx管理系統"的訂單
咱們能想到直接的方法，在訪問數據的入口加入SQL Where條件來實現，以上4種狀況對應的sql語句：

1 where CreateUserID = {loginUser}
 2 where CreateUserID = {loginUser} and {loginRole} in (測試）
 3 where CreateUserID = ({loginUser} and {loginRole} in (測試)) or {loginRole} in (管理員)
 4 where CreateUserID = ({loginUser} and {loginRole} in (測試)) or {loginRole} in (管理員)or ({loginUser}==test3 and 應用名稱==XXX管理系統)

這些一個一個的"條件"，簡單理解爲一個【數據規則】，一般會與原來咱們前臺的業務過濾條件合併再檢索出數據。

每個角色有不同的【數據規則】，那麼數據權限設計就變成

【資源】 - 【數據規則】

在數據庫記錄中存放爲資源ID+規則的形式，以下：

爲了簡化程序開發，在開發過程當中能夠作出如下約定：

全部須要進行數據權限控制功能的表，在設計時必須包含字段CreateUserId（建立用戶Id)。
【資源】的名稱限定爲模塊名稱。如部門管理，用戶管理，那麼資源就是對應的部門列表，用戶列表。
若是【資源】沒有設置數據規則，那麼視爲該資源容許被任何主體查看。
數據規則中受權的對象限定爲角色、用戶。即不能設定爲某個部門全部，若是想實現相似的功能，經過角色間接實現。例如：資源屬於角色「開發組成員」，「開發組組長」。

核心實現--查詢對象模式
權限控制總離不開一些條件的限制，若是沒有完善的查詢機制，那麼在作權限條件過濾的時候你會以爲很彆扭。馬丁在《企業應用架構模式》第13章對象-關係元數據映射模式中提出查詢對象模式(Query Object Pattern)。該模式核心結構以下：

該結構爲【數據規則】的創建提供了理論基礎。在設計數據權限的時候，能夠照搬該思想。上面例子中的規則，數據規則展開以下：

1 {
 2  "Operation": "or",
 3  "Filters": [{
 4      "Key": "{loginRole}",
 5      "Value": "09ee2ffa-7463-4938-ae0b-1cb4e80c7c13",
 6      "Contrast": "contains",
 7      "Text": "管理員"
 8  }],
 9  "Children": [{
 10         "Operation": "and",
 11         "Filters": [{
 12             "Key": "{loginRole}",
 13             "Value": "0a7ebd0c-78d6-4fbc-8fbe-6fc25c3a932d",
 14             "Contrast": "contains",
 15             "Text": "測試"
 16         }, {
 17             "Key": "CreateUserId",
 18             "Value": "{loginUser}",
 19             "Contrast": "==",
 20             "Text": ""
 21         }]
 22     }, {
 23         "Operation": "and",
 24         "Filters": [{
 25             "Key": "AppName",
 26             "Value": "XXX管理平臺",
 27             "Contrast": "==",
 28             "Text": ""
 29         }, {
 30             "Key": "{loginUser}",
 31             "Value": "229f3a49-ab27-49ce-b383-9f10ca23a9d5,1df68dfd-3b6d-4491-872f-00a0fc6c5a64",
 32             "Contrast": "in",
 33             "Text": "test3,test4"
 34         }]
 35     }]
 36 }

規則分爲三個部分：【分組】(Children)、【規則】(Filter)、【操做符】(and or)，而規則自身就是一個分組。這種簡單的結構就能夠知足所有的狀況。看不懂啥意思？

這樣理解起來就比較簡單了。

還不懂？？咱們從簡單的開始：

某一角色只能看到本身建立的信息。如：針對資源列表，咱們設置了【測試】角色能夠看到本身建立的資源。

這時若是用一個擁有測試角色的帳號（test）登陸，那麼他只能看到本身建立的資源：

其餘角色的帳號登陸時，會出現沒法看到任何信息。咱們稍作調整：【管理員】角色能夠看到全部資源，【測試】角色只能看到本身建立的資源。

這時若是用一個擁有管理員角色的帳號（admin）登陸，那麼他就能夠看到所有資源：

以此爲基礎，咱們能夠擴展很是複雜的數據權限控制。最終造成最後的複雜規則：【管理員】角色能夠看到全部資源，【測試】角色只能看到本身建立的資源。帳號test3/test4只能看到應用名稱等於「XXX管理平臺」的資源。

代碼解析--不要BB，秀出你的代碼
能夠在應用層基類BaseApp中，定義一個通用函數，根據當前即將訪問的資源Id獲取相應的訪問【數據規則】，並把當前登陸的用戶信息注入到該規則中，最終轉換成針對數據庫的查詢，以下：（不想看這個？直接跳過吧，看看如何使用也沒有問題）

1 protected IQueryable<T> GetDataPrivilege(string parametername)
 2 {
 3 var loginUser = _auth.GetCurrentUser();
 4 if (loginUser.User.Account == Define.SYSTEM_USERNAME) return UnitWork.Find<T>(null); //超級管理員特權
 5 
 6 var moduleName = typeof(T).Name;
 7 var rule = UnitWork.FindSingle<DataPrivilegeRule>(u => u.SourceCode == moduleName);
 8 if (rule == null) return UnitWork.Find<T>(null); //沒有設置數據規則，那麼視爲該資源容許被任何主體查看
 9 if (rule.PrivilegeRules.Contains(Define.DATAPRIVILEGE_LOGINUSER) ||
 10 rule.PrivilegeRules.Contains(Define.DATAPRIVILEGE_LOGINROLE))
 11 {
 12 
 13 //即把{loginUser} =='xxxxxxx'換爲 loginUser.User.Id =='xxxxxxx'，從而把當前登陸的用戶名與當時設計規則時選定的用戶id對比
 14 rule.PrivilegeRules = rule.PrivilegeRules.Replace(Define.DATAPRIVILEGE_LOGINUSER, loginUser.User.Id);
 15 var roles = loginUser.Roles.Select(u => u.Id).ToList();
 16 roles.Sort(); //按字母排序,這樣能夠進行like操做
 17 rule.PrivilegeRules = rule.PrivilegeRules.Replace(Define.DATAPRIVILEGE_LOGINROLE,
 18 string.Join(',',roles));
 19 }
 20 return UnitWork.Find<T>(null).GenerateFilter(parametername,
 21 JsonHelper.Instance.Deserialize<FilterGroup>(rule.PrivilegeRules));
 22 }
這樣在咱們本身的應用中，使用上面的函數建立一個基礎查詢，再加上自定義的查詢條件便可輕鬆實現數據權限的控制。

 1 var result = new TableData();
 2 var objs = GetDataPrivilege("u");
 3 if (!string.IsNullOrEmpty(request.key))
 4 {
 5 objs = objs.Where(u => u.Id.Contains(request.key));
 6 }
 7 
 8 result.data = objs.OrderBy(u => u.Id)
 9 .Skip((request.page - 1) * request.limit)
 10 .Take(request.limit);

最後
以上全部代碼均已實現並開源（配置數據規則的界面能夠本身畫，layui的前端畫起來實在太費力），OpenAuth.Core秉承代碼之美，爲.net core添磚加瓦，喜歡的star一下！

以爲不錯的話點個關注哦