發(fā)布時(shí)間：2016-05-14 08:06

  本文關(guān)鍵詞：權(quán)限管理，由筆耕文化傳播整理發(fā)布。

閱讀目錄

前言

 

前一篇文章《通用權(quán)限管理設(shè)計(jì) 之 數(shù)據(jù)庫(kù)設(shè)計(jì)方案》介紹了【主體】- 【領(lǐng)域】 - 【權(quán)限】( who、what、how問(wèn)題原型 ) 的設(shè)計(jì)思想

 

本文將對(duì)這種設(shè)計(jì)思想作進(jìn)一步的擴(kuò)展，介紹數(shù)據(jù)權(quán)限的設(shè)計(jì)方案。

權(quán)限控制可以理解，分為這幾種 ：

【功能權(quán)限】：能做什么的問(wèn)題，如增加產(chǎn)品。
【數(shù)據(jù)權(quán)限】：能看到哪些數(shù)據(jù)的問(wèn)題，如查看本人的所有訂單。
【字段權(quán)限】：能看到哪些信息的問(wèn)題，如供應(yīng)商賬戶(hù)，看不到角色、 部門(mén)等信息。

上面提到的那種設(shè)計(jì)就是【功能權(quán)限】，這種設(shè)計(jì)有一定的局限性，對(duì)于主體，只能明確地指定。對(duì)于不明確的，在這里可能就沒(méi)辦法處理。比如下面這幾種情況：

數(shù)據(jù)僅當(dāng)前部門(mén)及上級(jí)可見(jiàn)
數(shù)據(jù)僅當(dāng)前用戶(hù)(本人)可見(jiàn)

類(lèi)似這樣的就需要用到上面提的數(shù)據(jù)權(quán)限。

上一篇文章我用一個(gè)表五個(gè)字段完成了【功能權(quán)限】的設(shè)計(jì)思路
本文我將介紹如何利用一個(gè)表兩個(gè)字段完成這個(gè)【數(shù)據(jù)權(quán)限】的設(shè)計(jì)思路

初步分析

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

在設(shè)計(jì)中，我們規(guī)定好如果沒(méi)有設(shè)置了數(shù)據(jù)權(quán)限規(guī)則，那么視為允許查看全部的數(shù)據(jù)。

幾個(gè)概念
【資源】：數(shù)據(jù)權(quán)限的控制對(duì)象，業(yè)務(wù)系統(tǒng)中的各種資源。比如訂單單據(jù)、銷(xiāo)售單等。屬于上面提到的【領(lǐng)域】中的一種
【主體】：用戶(hù)、部門(mén)、角色等。
【條件規(guī)則】：用于檢索數(shù)據(jù)的條件定義
【數(shù)據(jù)規(guī)則】：用于【數(shù)據(jù)權(quán)限】的條件規(guī)則 

 
應(yīng)用場(chǎng)景
1，訂單，可以由本人查看 
2，銷(xiāo)售單，可以由本人或上級(jí)領(lǐng)導(dǎo)查看 
3，銷(xiāo)售單，銷(xiāo)售人員可以查看自己的，銷(xiāo)售經(jīng)理只查看 銷(xiāo)售金額大于100,000的。

我們能想到直接的方法，在訪問(wèn)數(shù)據(jù)的入口加入SQL Where條件來(lái)實(shí)現(xiàn)，組織sql語(yǔ)句：

1，where UserID = {CurrentUserID}
2，where UserID = {CurrentUserID} or {CurrentUserID} in (領(lǐng)導(dǎo))
3，where UserID = {CurrentUserID} or ({CurrentUserID} in (銷(xiāo)售經(jīng)理) and 銷(xiāo)售金額 > 100000)

這些一個(gè)一個(gè)的"條件"，本文簡(jiǎn)單理解為一個(gè)【數(shù)據(jù)規(guī)則】，通常會(huì)與原來(lái)我們前臺(tái)的業(yè)務(wù)過(guò)濾條件合并再檢索出數(shù)據(jù)。

這是一種最直接的實(shí)現(xiàn)方式，在【資源】上面加一個(gè)【數(shù)據(jù)規(guī)則】（比如上面的三點(diǎn)）。這樣設(shè)計(jì)就是

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

我又覺(jué)得不同的人應(yīng)該對(duì)應(yīng)不同的規(guī)則，那么也可以理解為，一個(gè)用戶(hù)對(duì)應(yīng)不同的角色，每一個(gè)角色有不一樣的【數(shù)據(jù)規(guī)則】，那么設(shè)計(jì)就變成

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

根據(jù)提供者的不同，準(zhǔn)備不同的權(quán)限應(yīng)對(duì)策略。

這里可以簡(jiǎn)單地介紹一下，這個(gè)方案至少需要2張表，一個(gè)是  【資源，主體，規(guī)則關(guān)系表】、一個(gè)是【數(shù)據(jù)規(guī)則表】

關(guān)系表不能直接保存角色，因?yàn)槟悴淮_定什么時(shí)候業(yè)務(wù)需要按照【部門(mén)】或者【分公司】來(lái)定義數(shù)據(jù)規(guī)則

于是可以用  Master、MasterKey  類(lèi)似這樣的兩個(gè)字段來(lái)確定一個(gè)【主體】

用XML方式的話是這樣配置的(放在數(shù)據(jù)庫(kù)也類(lèi)似)：

銷(xiāo)售員 = {CurrentUserID}


銷(xiāo)售金額 > 100000


銷(xiāo)售金額 > 100000 and 區(qū)域 = {當(dāng)前用戶(hù)所屬區(qū)域}

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

當(dāng)然，上面是用SQL的方式來(lái)確定條件規(guī)則的，我們當(dāng)然不會(huì)這么做。SQL雖然靈活，但是我們很難去維護(hù)，也不知道SQL在我們的界面UI上面如何體現(xiàn)。難不成直接用一個(gè)文本框來(lái)顯示。這樣對(duì)應(yīng)一個(gè)開(kāi)發(fā)人員來(lái)說(shuō)不是問(wèn)題，可是對(duì)應(yīng)系統(tǒng)管理員，很容易出問(wèn)題。所以我們需要有另一方式來(lái)確定這一規(guī)則，并最終可以轉(zhuǎn)換成我們的SQL語(yǔ)句。

我們的設(shè)計(jì)關(guān)鍵在于如何規(guī)范好這些【數(shù)據(jù)規(guī)則】 ，這個(gè)規(guī)則必須是對(duì)前端友好的，而且是對(duì)后臺(tái)友好的，JSON顯然是很好的方式。

 規(guī)則說(shuō)明：

1，數(shù)據(jù)權(quán)限規(guī)則總是：｛屬性 條件 允許值｝

2，數(shù)據(jù)權(quán)限規(guī)則可以合并。比如 （ {當(dāng)前用戶(hù) 屬于 銷(xiāo)售人員} and {訂單銷(xiāo)售員 等于  當(dāng)前用戶(hù)} )   Or {當(dāng)前用戶(hù)  屬于 銷(xiāo)售經(jīng)理}

3，最終我們會(huì)用JSON格式

在檢索數(shù)據(jù)時(shí)會(huì)先判斷有沒(méi)有注冊(cè)了某某【資源】的【條件規(guī)則】，如果有，那么加載這個(gè)【條件規(guī)則】并合并到我們前臺(tái)的【搜索條件】（你的業(yè)務(wù)界面應(yīng)該有一個(gè)搜索框吧）

 如下圖定義了客戶(hù)信息的搜索框，我們搜索客戶(hù)ID包括AN，我們組織成的規(guī)則將會(huì)是：

{"rules":[{"field":"CustomerID","op":"like","value":"AN","type":"string"}],"op":"and"}

為了更好地理解【數(shù)據(jù)規(guī)則】，這里介紹一下【通用查詢(xún)機(jī)制】 

【通用查詢(xún)機(jī)制】

權(quán)限控制總離不開(kāi)一些條件的限制(比如查看當(dāng)前部門(mén)的單據(jù))，如果沒(méi)有完善的通用查詢(xún)規(guī)則機(jī)制，那么在做權(quán)限條件過(guò)濾的時(shí)候你會(huì)覺(jué)得很別扭。這里介紹一個(gè)通用查詢(xún)方案，然后再介紹如何實(shí)現(xiàn)【數(shù)據(jù)規(guī)則】。

 

早些時(shí)候我寫(xiě)過(guò)一篇關(guān)于ligerGrid結(jié)合.net設(shè)計(jì)通用處理類(lèi)的文章《 jQuery liger ui ligerGrid 打造通用的分頁(yè)排序查詢(xún)表格(提供下載) 》。里面提到的過(guò)濾信息是直接的SQL語(yǔ)句。這是不可靠，而且不安全的。
在前端傳輸給后臺(tái)的過(guò)濾信息不應(yīng)該是直接的SQL，，而應(yīng)該是一組過(guò)濾規(guī)則。在ligerui V1.1.8 已經(jīng)加入了一個(gè)條件過(guò)濾器插件，這個(gè)插件組成的規(guī)則數(shù)據(jù)才是我受推薦的：
比如如下

 

{"rules":
[
{"field":"OrderDate","op":"less","value":"2012-01-01"},
{"field":"CustomerID","op":"equal","value":"VINET"}
]
,"op":"and"}

 

規(guī)則描述：
查找顧客VINET所有訂單時(shí)間小于2011-01-01的單據(jù)

這樣的數(shù)據(jù)是安全的，而且是通用的(你甚至可以再加一個(gè)OR子查詢(xún))。無(wú)論是在前端還是后臺(tái)，無(wú)論你使用什么樣的組件，都可以很好地利用。

通用后臺(tái)的翻譯，就可以生成這樣SQL的參數(shù)：

 

)
Parameters:
p1:
p2:VINET

 

下面來(lái)點(diǎn)復(fù)雜的：查找 顧客VINET或者TOMSP，所有訂單時(shí)間小于2011-01-01的單據(jù)

 

{
"rules":[{"field":"OrderDate","op":"less","value":"2012-01-01"}],
"groups":[
{"rules":[{"field":"CustomerID","op":"equal","value":"VINET"}, {"field":"CustomerID","op":"equal","value":"TOMSP"}],"op":"or"}
],
"op":"and"
}

 翻譯結(jié)果：

 

())
Parameters:
p1:
p2:VINET
p3:TOMSP

 

這個(gè)過(guò)濾規(guī)則分為三個(gè)部分：【分組】、【規(guī)則】(字段、值、操作符)、【操作符】(and or)，而自身就是一個(gè)分組。
這種簡(jiǎn)單的結(jié)構(gòu)就可以滿(mǎn)足全部的情況。

當(dāng)然，上面提到的這些條件都是在前臺(tái)定義(可能是用戶(hù)在搜索框自己輸入的)的，而在后臺(tái)，我們可能會(huì)定義一下【隱藏條件】，比如說(shuō) 【員工只能查看自己的】，要怎么做呢，其實(shí)很簡(jiǎn)單，只需要在后臺(tái)接收到這個(gè)過(guò)濾條件(前臺(tái)toJSON，后臺(tái)解析JSON)以后，再加上一個(gè)過(guò)濾規(guī)則(隱藏條件)：

 

{field:'EmployeeID',op:'equal',value:5}

 

可以將原來(lái)的過(guò)濾規(guī)則當(dāng)做一個(gè)分組加入進(jìn)行：

 

 

{op:'and',groups:[

 

{"rules":[{"field":"OrderDate","op":"less","value":"2012-01-01"}],
"groups":[
{"rules":[{"field":"CustomerID","op":"equal","value":"VINET"},{"field":"CustomerID","op":"equal","value":"TOMSP"}],"op":"or"}
],"op":"and"}

 

],rules:[{field:'EmployeeID',op:'equal',value:5}]
}

 

翻譯如下：

 

(()))
Parameters:
p1:
p3:VINET
p4:TOMSP

 這樣的【條件規(guī)則】才是我們想要的，不僅在前端可以很好地解析，也可以在后臺(tái)進(jìn)行處理。在后臺(tái)我們會(huì)定義跟這種數(shù)據(jù)結(jié)構(gòu)對(duì)應(yīng)的類(lèi)，那么再定義一個(gè)翻譯成SQL的類(lèi)：

數(shù)據(jù)權(quán)限規(guī)則

說(shuō)了這些，可以開(kāi)始介紹如何實(shí)現(xiàn)【數(shù)據(jù)規(guī)則】了：

上面提到的【隱藏條件】，就是我介紹的【數(shù)據(jù)規(guī)則】
試想一些，這樣 前臺(tái)的過(guò)濾規(guī)則，再加上我們之間定義好的 【數(shù)據(jù)權(quán)限】控制 過(guò)濾條件。不就達(dá)到目的了嗎。
先看看我們?cè)跀?shù)據(jù)庫(kù)里保存的這些【數(shù)據(jù)規(guī)則】：

 看不明白？那來(lái)個(gè)清楚一點(diǎn)的：

規(guī)則描述

訂單：【訂單管理員和演示角色可以查看所有的】，【訂單查看員】只能查看自己的

產(chǎn)品：【基礎(chǔ)信息錄入員和演示角色可以查看所有的】，【供應(yīng)商】只能查看自己的

{CurrentEmployeeID}表示當(dāng)前的員工。

實(shí)質(zhì)上，我們還可以根據(jù)當(dāng)前用戶(hù)信息定義需要的參數(shù)，比如：

{CurrentUserID} 當(dāng)前用戶(hù)Id ，對(duì)應(yīng)表【CF_User】

{CurrentRoleID} 當(dāng)前角色I(xiàn)d ，對(duì)應(yīng)表 【CF_Role】 

{CurrentDeptID} 當(dāng)前用戶(hù)部門(mén)Id，對(duì)應(yīng)表【CF_Department】

{CurrentEmployeeID} 當(dāng)前用戶(hù)員工Id，對(duì)應(yīng)表【Employees】(CF_User.EmployeeID)

{CurrentSupplierID} 當(dāng)前用戶(hù)供應(yīng)商Id，對(duì)應(yīng)表【Suppliers】(CF_User.SupplierID)

 在數(shù)據(jù)庫(kù)中我們直接保存這些用戶(hù)參數(shù)，在“翻譯”規(guī)則成為SQL時(shí)，會(huì)替換掉：

比如查看訂單，我們得到的SQL，可能是這樣的：

((( (())) OrderID

{CurrentRuleID} 替換為 7

{CurrentEmployeeID} 替換為1

 下圖是我們?cè)O(shè)計(jì)【數(shù)據(jù)權(quán)限】的界面，可以選擇所有的字段，包括幾個(gè)用戶(hù)信息：

這些字段不僅僅只是在文本框中輸入值，那么可以自定義數(shù)據(jù)來(lái)源：

 

{
: { type: ,
options: {
width: Orderstrue"
}
}
};

效果界面：

 

實(shí)際應(yīng)用

既然是數(shù)據(jù)權(quán)限控制，如果有一個(gè)統(tǒng)一的數(shù)據(jù)接收入口，我們倒是可以利用這個(gè)入口做一些工作。

比如【ligerRM權(quán)限管理系統(tǒng)】統(tǒng)一使用 grid.ashx 這個(gè)數(shù)據(jù)處理程序作為列表數(shù)據(jù)的接收入口。

有了統(tǒng)一的接口，方便做權(quán)限的控制，使用過(guò) ligerGrid Javascript表格，或者類(lèi)似插件的朋友，應(yīng)該比較清楚服務(wù)器的交互原理。
在grid.ashx中，我們會(huì)通過(guò)
【視圖/表名 】、 【排序信息】、【分頁(yè)信息】、【過(guò)濾信息】
這幾個(gè)指標(biāo)來(lái)獲取指定的數(shù)據(jù)。

而在實(shí)際的業(yè)務(wù)中，可能會(huì)引入權(quán)限的控制。比如某某【資源】，只能由當(dāng)前用戶(hù)自身才能查看，或者只能由當(dāng)前用戶(hù)部門(mén)及上級(jí)部門(mén)才能查看。對(duì)于這些控制，我們采用對(duì)這些可能做權(quán)限控制的【資源】注冊(cè)一組【條件規(guī)則】的方式來(lái)進(jìn)行。

 我們將找到view定義好的【數(shù)據(jù)權(quán)限規(guī)則】，然后和用戶(hù)在前臺(tái)搜索框輸入的【搜索規(guī)則】合并：

上面的代碼就是數(shù)據(jù)條件合并的例子，這樣便得到了我們最終需要的 過(guò)濾規(guī)則。

結(jié)語(yǔ)

本文提出了數(shù)據(jù)權(quán)限的一種實(shí)現(xiàn)思路，只是本人在做一個(gè)web應(yīng)用時(shí)構(gòu)思的方案，談不上規(guī)范，歡迎提出你的建議意見(jiàn)。

可以在體驗(yàn)實(shí)際的應(yīng)用效果。

  本文關(guān)鍵詞：權(quán)限管理，由筆耕文化傳播整理發(fā)布。

本文編號(hào)：45007