? ? APP開發(fā) 軟件開發(fā) APP開發(fā)公司 軟件開發(fā)公司

?? ?1、數(shù)據(jù)權(quán)限概述
?? ?1.1、什么是數(shù)據(jù)權(quán)限？
?? ?數(shù)據(jù)權(quán)限是指對(duì)系統(tǒng)用戶對(duì)數(shù)據(jù)資源可見性的控制。流行的解釋是，滿足某種條件的用戶只能在該條件下看到相應(yīng)的數(shù)據(jù)資源。所以最簡單的數(shù)據(jù)權(quán)限可能是：用戶只能看到自己的數(shù)據(jù)。在正式的系統(tǒng)環(huán)境中，有許多更復(fù)雜的數(shù)據(jù)權(quán)限需求方案，例如：
?? ?領(lǐng)導(dǎo)需要看到所有下屬員工的客戶數(shù)據(jù)，員工只能看到自己的客戶數(shù)據(jù)；
?? ?經(jīng)理A可以看到所有企業(yè)客戶，B經(jīng)理只能看到企業(yè)客戶年銷售額不到1000萬；
?? ?a角色可以看到全國的產(chǎn)品數(shù)據(jù)，B角色只能看到上海的產(chǎn)品數(shù)據(jù)；
?? ?這些要求也可以通過使用硬編碼實(shí)現(xiàn)，但是在業(yè)務(wù)的快速發(fā)展過程中，對(duì)于類似的數(shù)據(jù)權(quán)限將有越來越多的要求。如果所有這些要求都是硬編碼的，它無疑將給我們帶來巨大的發(fā)展和維護(hù)壓力。
?? ?1.2、要素分析
?? ?從當(dāng)前登錄用戶的角度來看，數(shù)據(jù)權(quán)限的定義可以理解為：當(dāng)前登錄用戶只能看到用戶權(quán)限范圍內(nèi)的數(shù)據(jù)資源。由此，可以分析數(shù)據(jù)權(quán)限控制的幾個(gè)關(guān)鍵要素：
?? ?主體，即當(dāng)前登錄用戶。領(lǐng)導(dǎo)和角色等概念可以轉(zhuǎn)換為當(dāng)前登錄用戶是否是領(lǐng)導(dǎo)者，以及他或她是否具有角色。
?? ?數(shù)據(jù)資源。即受控系統(tǒng)數(shù)據(jù)。
?? ?有條件的規(guī)則。也就是說，當(dāng)前登錄用戶對(duì)于特定的數(shù)據(jù)資源適用的條件。
?? ?2、數(shù)據(jù)權(quán)限設(shè)計(jì)
?? ?理論上，當(dāng)用戶訪問被控制的系統(tǒng)數(shù)據(jù)時(shí)，可以得到用戶應(yīng)用于數(shù)據(jù)資源的條件規(guī)則，并將條件規(guī)則解析為SQL查詢語句，實(shí)現(xiàn)對(duì)數(shù)據(jù)的權(quán)限控制。但是，在實(shí)現(xiàn)中仍然存在許多困難，例如以下規(guī)則適用于當(dāng)前登錄用戶：
?? ?客戶數(shù)據(jù)：[客戶經(jīng)理][包含在][下屬人員]產(chǎn)品數(shù)據(jù)：[銷售地區(qū)][等于][上海]訂單數(shù)據(jù)：（[產(chǎn)品銷售地區(qū)][等于][上海]）[和]（[客戶營銷經(jīng)理][包含在][下屬人員]）
?? ?思考如下問題：
?? ?[accountManager][included][submiters]如何解析為SQL語句？如何處理多表聯(lián)合查詢？
?? ?下屬由系統(tǒng)根據(jù)當(dāng)前的登錄用戶進(jìn)行計(jì)算，上海則根據(jù)管理員的背景進(jìn)行選擇。這兩種方法如何兼容？
?? ?如何設(shè)計(jì)復(fù)雜多變的組合條件？
?? ?如何確定應(yīng)用于當(dāng)前查詢的條件？
?? ?一個(gè)用戶應(yīng)該如何具有多個(gè)角色，不同角色應(yīng)該如何為同一規(guī)則設(shè)置不同的值？
?? ?2.1、規(guī)則元
?? ?名詞定義：正則元素。在本文中，它是指一個(gè)獨(dú)立的數(shù)據(jù)規(guī)則定義。不同的用戶可以為規(guī)則元素設(shè)置特定的規(guī)則篩選值，作為數(shù)據(jù)查詢的篩選條件。在上述規(guī)則中，[客戶經(jīng)理]和[銷售地區(qū)]屬于規(guī)則元素。
?? ?2.2、規(guī)則元配置
?? ?一。規(guī)則元名稱的配置。表中的哪些字段可以由規(guī)則設(shè)置，以及規(guī)則元名稱如何與表字段相關(guān)聯(lián)。（例如，在上面的規(guī)則[客戶經(jīng)理]，[銷售區(qū)域]）中，很容易想到通過配置文件來維護(hù)規(guī)則名和數(shù)據(jù)庫字段之間的關(guān)系。
?? ?2.規(guī)則元素值數(shù)據(jù)源的配置。例如，【下屬人員】和【上海】在上述規(guī)則中，不難發(fā)現(xiàn)規(guī)則人民幣價(jià)值有三個(gè)來源：
?? ?后臺(tái)管理人員輸入。
?? ?系統(tǒng)提供數(shù)據(jù)源，后臺(tái)管理器選擇。例如：地點(diǎn)[上海]
?? ?系統(tǒng)提供數(shù)據(jù)。如：[下屬人員]
?? ?配置文件可以滿足數(shù)據(jù)規(guī)則的配置要求，但是當(dāng)規(guī)則元素越來越多，維護(hù)配置文件變得很麻煩，我們可以遵循Spring-boot而不是Spring-MVC的實(shí)踐，而是使用注釋而不是配置？每一條數(shù)據(jù)規(guī)則最終都會(huì)落入數(shù)據(jù)庫字段的控制之中，現(xiàn)在大多數(shù)系統(tǒng)都會(huì)有一個(gè)對(duì)應(yīng)于數(shù)據(jù)庫中表的模型層，所以brain組成了一個(gè)完美的規(guī)則元配置模式：
?? ?@TableName（“test“）
?? ?Public class TestModal extension abstract model {\ expndtw-1
?? ?@數(shù)據(jù)規(guī)則（name=“rule meta name”）
?? ?Private string name;
?? ?}
?? ?@DataRule注解源碼如下：
?? ?@Target（{ElementType.FIELD}）
?? ?@Retention (retention policy.(runtime)
?? ?public @interface DataRule {
?? ?/**
?? ?* 規(guī)則元名稱
?? ?*/
?? ?String name() default ";
?? ?/**
?? ?* 規(guī)則元值來源類型
?? ?*/
?? ?RuleSourceStrategy () default RuleSourceStrategy.Text;
?? ?/**
?? ?*當(dāng)用戶選擇數(shù)據(jù)源時(shí){@code rulesourcestrategyChoice}數(shù)據(jù)地址
?? ?*/
?? ?The string URL () defaults to "";
?? ?/**
?? ?*當(dāng)數(shù)據(jù)源由系統(tǒng)提供時(shí){@code rulesourcestrategySystem}提供程序類名稱
?? ?*/
?? ?Class provider（） default NullDataRuleProvider.Class;
?? ?}
?? ?啟動(dòng)系統(tǒng)時(shí)，規(guī)則元素配置信息（名稱、對(duì)應(yīng)數(shù)據(jù)表、對(duì)應(yīng)字段、值源類型、值源URL、值源提供程序類名稱等）。)與數(shù)據(jù)庫同步。數(shù)據(jù)表的簡單設(shè)計(jì)如下：

?

?? ?2.3、數(shù)據(jù)規(guī)則的配置
?? ?使用規(guī)則元素信息，管理員可以為系統(tǒng)中的不同用戶(角色)設(shè)置規(guī)則元素值，這是數(shù)據(jù)查詢時(shí)的篩選條件。規(guī)則元值數(shù)據(jù)源包括三種情況：情況①和情況②，管理員需要填寫或選擇規(guī)則值，并將其存儲(chǔ)在數(shù)據(jù)庫中；情況③，根據(jù)當(dāng)前登錄用戶計(jì)算值，即提供者在@data rule注解中計(jì)算的值。數(shù)據(jù)庫存儲(chǔ)的規(guī)則與系統(tǒng)計(jì)算的規(guī)則相結(jié)合，即登錄用戶的所有數(shù)據(jù)規(guī)則。
?? ?一個(gè)簡單的配置界面如下：

??? 2.4 數(shù)據(jù)規(guī)則的解析
?? ?如上文所示，當(dāng)前登錄用戶的數(shù)據(jù)規(guī)則有兩個(gè)主要來源：
??? 1. 存儲(chǔ)在數(shù)據(jù)庫中的規(guī)則配置；例如位置[上海]
??? 2.需要系統(tǒng)計(jì)算的規(guī)則配置；如：[下屬人員]
??? 3.合并兩種情況下獲得的數(shù)據(jù)規(guī)則后，可獲得適用于當(dāng)前登錄用戶的數(shù)據(jù)規(guī)則集，流程圖如下：

?? ?在這兩種情況下獲得的數(shù)據(jù)規(guī)則如何兼容？如何將規(guī)則組合成復(fù)雜的查詢條件？
?? ?定義通用的規(guī)則結(jié)構(gòu)如下：
?? ?{
?? ?rule:[{
?? ?field: “name“,
?? ?operate: “equal“,
?? ?value: “xxx“
?? ?}],
?? ?operate:“and“,
?? ?group:[{
?? ?rule:[],
?? ?operate:“greater“,
?? ?group:[]
?? ?}]
?? ?}
?? ?數(shù)據(jù)庫存儲(chǔ)規(guī)則結(jié)構(gòu)的JSON字符串。合并時(shí)，反序列化JSON字符串，并使用和連接由系統(tǒng)計(jì)算的規(guī)則對(duì)象。將合并的規(guī)則結(jié)構(gòu)解析為一個(gè)簡單的SQL語句并不困難。
?? ?但是如何處理多表聯(lián)合查詢呢？
?? ?在解析成SQL語句時(shí)，可以使用表名+字段名的方法。但是，當(dāng)在查詢中使用別名時(shí)，此方法無法正常工作。這里的臨時(shí)處理方法是支持在解析期間傳遞別名。
?? ?一個(gè)用戶應(yīng)該如何具有多個(gè)角色，不同角色應(yīng)該如何為同一規(guī)則設(shè)置不同的值？
?? ?例如，用戶a具有角色role1和role2，其中：
?? ?ROLE1應(yīng)用程序規(guī)則:[銷售區(qū)域][等][上海]ROLE2應(yīng)用程序規(guī)則:[銷售區(qū)域][等][北京]
?? ?那么用戶A合并后的數(shù)據(jù)規(guī)則應(yīng)該是：
?? ?用戶a的適用規(guī)則：（[銷售地區(qū)][等于][上海]）或（[銷售地區(qū)][等于][北京]）
?? ?即：一個(gè)用戶對(duì)于同一個(gè)規(guī)則元素的多個(gè)規(guī)則設(shè)置，應(yīng)先使用或連接后再與其他規(guī)則元素和連接..
?? ?2.5、確定當(dāng)前查詢適用的數(shù)據(jù)規(guī)則
?? ?通過以上規(guī)則的配置和分析，可以方便地得到適用于當(dāng)前用戶的數(shù)據(jù)規(guī)則集。但是我們應(yīng)該在收集中使用哪些規(guī)則來過濾查詢？是否在查詢中啟用數(shù)據(jù)規(guī)則篩選以及使用規(guī)則篩選的表應(yīng)由開發(fā)人員決定，類似于：
?? ?XXXQuery(..）.withDataRule（“`table1`，`table2`”）；
?? ?也就是說，表1和表2中配置的數(shù)據(jù)規(guī)則用于當(dāng)前用戶的當(dāng)前查詢。數(shù)據(jù)表中的每個(gè)規(guī)則都應(yīng)該支持是否在管理后臺(tái)啟用，這樣理論上每個(gè)用戶都可以配置每個(gè)數(shù)據(jù)規(guī)則。