當(dāng)代碼寫多了，總有些是經(jīng)驗，但經(jīng)驗是什么呢？if…else用的次數(shù)比別人多？顯然不是。有些超棒的設(shè)計可以謂之經(jīng)驗！

功能權(quán)限

網(wǎng)絡(luò)上流行的經(jīng)典的權(quán)限設(shè)計是【主體】- 【領(lǐng)域】 - 【權(quán)限】( who、what、how問題原型 ) 的設(shè)計思想，其中：

【主體】可以是用戶，可以是角色，也可以是一個部門

【領(lǐng)域】可以是一個模塊，可以是一個頁面，也可以是頁面上的按鈕

【權(quán)限】可以是“可見”，可以是“只讀”，也可以是“可用”(如按鈕可以點擊)

為了簡化程序開發(fā)，在OpenAuth.Core中去掉了權(quán)限的控制，簡化為【主體】- 【領(lǐng)域】的模式，且【主體】限定為角色。即只能給角色分配模塊和按鈕，不能直接分配給用戶賬號或部門。且一旦分配即表示該角色擁有操作該模塊（按鈕）的權(quán)限。

大道至簡，標準的RBAC規(guī)范比這個還要簡潔，所以它的生命力才最頑強。在此基礎(chǔ)上，如果進行二次開發(fā)，進行更詳細的功能權(quán)限控制，可以按照上面的思想進行改造。

數(shù)據(jù)權(quán)限

數(shù)據(jù)權(quán)限是在功能權(quán)限的基礎(chǔ)上面進一步的擴展，比如可以查看訂單屬于【功能權(quán)限】的范圍，但是可以查看哪些訂單就是【數(shù)據(jù)權(quán)限】的工作了。

這里面的幾個概念：

【資源】：數(shù)據(jù)權(quán)限的控制對象，業(yè)務(wù)系統(tǒng)中的各種資源。比如訂單單據(jù)、銷售單等。

【數(shù)據(jù)規(guī)則】：用于數(shù)據(jù)權(quán)限的條件規(guī)則 。

應(yīng)用場景

• 銷售單，可以由本人查看
• 銷售單，測試角色能看到自己的訂單
• 銷售單，測試角色能看到自己的訂單，管理員角色可以看到所有訂單
• 銷售單，測試角色能看到自己的訂單，管理員角色可以看到所有訂單，賬號test3可以看到應(yīng)用名稱為"xxx管理系統(tǒng)"的訂單

我們能想到直接的方法，在訪問數(shù)據(jù)的入口加入SQL Where條件來實現(xiàn)，以上4種情況對應(yīng)的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 應(yīng)用名稱==XXX管理系統(tǒng))

這些一個一個的"條件"，簡單理解為一個【數(shù)據(jù)規(guī)則】，通常會與原來我們前臺的業(yè)務(wù)過濾條件合并再檢索出數(shù)據(jù)。

每一個角色有不一樣的【數(shù)據(jù)規(guī)則】，那么數(shù)據(jù)權(quán)限設(shè)計就變成

　　【資源】 - 【數(shù)據(jù)規(guī)則】

在數(shù)據(jù)庫記錄中存放為資源ID+規(guī)則的形式，如下：

為了簡化程序開發(fā)，在開發(fā)過程中可以做出以下約定：

• 所有需要進行數(shù)據(jù)權(quán)限控制功能的表，在設(shè)計時必須包含字段CreateUserId（創(chuàng)建用戶Id)。
• 【資源】的名稱限定為模塊名稱。如部門管理，用戶管理，那么資源就是對應(yīng)的部門列表，用戶列表。
• 如果【資源】沒有設(shè)置數(shù)據(jù)規(guī)則，那么視為該資源允許被任何主體查看。
• 數(shù)據(jù)規(guī)則中授權(quán)的對象限定為角色、用戶。即不能設(shè)定為某個部門所有，如果想實現(xiàn)類似的功能，通過角色間接實現(xiàn)。例如：資源屬于角色“開發(fā)組成員”，“開發(fā)組組長”。

核心實現(xiàn)--查詢對象模式

權(quán)限控制總離不開一些條件的限制，如果沒有完善的查詢機制，那么在做權(quán)限條件過濾的時候你會覺得很別扭。馬丁在《企業(yè)應(yīng)用架構(gòu)模式》第13章對象-關(guān)系元數(shù)據(jù)映射模式中提出查詢對象模式(Query Object Pattern)。該模式核心結(jié)構(gòu)如下：

該結(jié)構(gòu)為【數(shù)據(jù)規(guī)則】的建立提供了理論基礎(chǔ)。在設(shè)計數(shù)據(jù)權(quán)限的時候，可以照搬該思想。上面例子中的規(guī)則，數(shù)據(jù)規(guī)則展開如下：

  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 }

規(guī)則分為三個部分：【分組】(Children)、【規(guī)則】(Filter)、【操作符】(and or)，而規(guī)則自身就是一個分組。這種簡單的結(jié)構(gòu)就可以滿足全部的情況?？床欢兑馑?？

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

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

數(shù)據(jù)權(quán)限實例--按角色

某一角色只能看到自己創(chuàng)建的信息。如：針對資源列表，我們設(shè)置了【測試】角色可以看到自己創(chuàng)建的資源。

這時如果用一個擁有測試角色的賬號（test）登錄，那么他只能看到自己創(chuàng)建的資源：

其他角色的賬號登錄時，會出現(xiàn)無法看到任何信息。我們稍做調(diào)整：【管理員】角色可以看到所有資源，【測試】角色只能看到自己創(chuàng)建的資源。

這時如果用一個擁有管理員角色的賬號（admin）登錄，那么他就可以看到全部資源：

以此為基礎(chǔ)，我們可以擴展非常復(fù)雜的數(shù)據(jù)權(quán)限控制。最終形成最后的復(fù)雜規(guī)則：【管理員】角色可以看到所有資源，【測試】角色只能看到自己創(chuàng)建的資源。賬號test3/test4只能看到應(yīng)用名稱等于“XXX管理平臺”的資源。

數(shù)據(jù)權(quán)限實例--按部門

管理員】可以看到所管轄部門的所有數(shù)據(jù)，其他角色只能看到自己的。

代碼解析

可以在應(yīng)用層基類BaseApp中，定義一個通用函數(shù)，根據(jù)當(dāng)前即將訪問的資源Id獲取相應(yīng)的訪問【數(shù)據(jù)規(guī)則】，并把當(dāng)前登錄的用戶信息注入到該規(guī)則中，最終轉(zhuǎn)換成針對數(shù)據(jù)庫的查詢，如下：（不想看這個？直接跳過吧，看看如何使用也沒有問題）

  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);  //超級管理員特權(quán)
  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); //沒有設(shè)置數(shù)據(jù)規(guī)則，那么視為該資源允許被任何主體查看
  9             if (rule.PrivilegeRules.Contains(Define.DATAPRIVILEGE_LOGINUSER) ||
 10                                              rule.PrivilegeRules.Contains(Define.DATAPRIVILEGE_LOGINROLE))
 11             {
 12 
 13                 //即把{loginUser} =='xxxxxxx'換為 loginUser.User.Id =='xxxxxxx'，從而把當(dāng)前登錄的用戶名與當(dāng)時設(shè)計規(guī)則時選定的用戶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(); //按字母排序,這樣可以進行l(wèi)ike操作
 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         }

這樣在我們自己的應(yīng)用中，使用上面的函數(shù)創(chuàng)建一個基礎(chǔ)查詢，再加上自定義的查詢條件即可輕松實現(xiàn)數(shù)據(jù)權(quán)限的控制。

  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);

最后

以上所有代碼均已實現(xiàn)并開源（配置數(shù)據(jù)規(guī)則的界面可以自己畫，layui的前端畫起來實在太費力），OpenAuth.Core秉承代碼之美，為.net core添磚加瓦，喜歡的star一下！