6月iOS設(shè)備好評(píng)榜：第一蟬聯(lián)榜首近一年
作為安兔兔各種榜單里變化最小的那個(gè)，2023年6月的iOS好評(píng)榜和上個(gè)月相比沒(méi)有任何排名上的變化，僅僅是部分設(shè)備好評(píng)率的下降，長(zhǎng)年累月的用戶評(píng)價(jià)和逐漸退出市場(chǎng)的老款機(jī)器讓這
常見(jiàn)的，在項(xiàng)目實(shí)際開(kāi)發(fā)中我們不光要控制一個(gè)用戶能訪問(wèn)哪些資源，還需要控制用戶只能訪問(wèn)資源中的某部分?jǐn)?shù)據(jù)。這就是所謂的數(shù)據(jù)權(quán)限。典型的如列表數(shù)據(jù)權(quán)限，主要通過(guò)數(shù)據(jù)權(quán)限控制行數(shù)據(jù)，讓不同的人有不同的查看數(shù)據(jù)規(guī)則。
在互聯(lián)網(wǎng)系統(tǒng)中，權(quán)限一般分為功能權(quán)限和數(shù)據(jù)權(quán)限，功能權(quán)限比較常見(jiàn)，因?yàn)橥ㄓ眯院蛷?fù)用性，業(yè)內(nèi)有很多的通用框架和設(shè)計(jì)。但對(duì)應(yīng)數(shù)據(jù)權(quán)限來(lái)說(shuō)，由于數(shù)據(jù)權(quán)限強(qiáng)依賴客戶組織架構(gòu)和具體業(yè)務(wù)的關(guān)系，往往實(shí)現(xiàn)起來(lái)會(huì)比較復(fù)雜，很少有一個(gè)設(shè)計(jì)架構(gòu)能完全覆蓋住，所以大部分的系統(tǒng)都一致性的遵循此策略：如非必要的盡量不使用數(shù)據(jù)權(quán)限，必須要的則單獨(dú)控制。
目前常見(jiàn)數(shù)據(jù)權(quán)限方案基本為硬編碼，具體分為如下兩種：一是拆分功能頁(yè)面，即根據(jù)不同數(shù)據(jù)權(quán)限用戶，通過(guò)復(fù)制拷貝的方式，增加多個(gè)類似的菜單，再通過(guò)功能權(quán)限配置來(lái)給不同用戶設(shè)置不同的菜單，從而實(shí)現(xiàn)數(shù)據(jù)權(quán)限的控制；二是在功能對(duì)應(yīng)的后端接口里做判斷，對(duì)不同數(shù)據(jù)權(quán)限的用戶，過(guò)濾不同的數(shù)據(jù)列表透出給用戶。硬編碼的方式顯而易見(jiàn)的優(yōu)點(diǎn)是技術(shù)難度低，實(shí)現(xiàn)簡(jiǎn)單。
但以上硬編碼的方式，無(wú)論選擇用哪一種，都無(wú)法解決系統(tǒng)靈活性的問(wèn)題，每當(dāng)系統(tǒng)有老的需求要變更或者新的需求要新增，對(duì)應(yīng)的開(kāi)發(fā)人員就不得不去調(diào)整編碼，修改菜單和頁(yè)面，由此可見(jiàn)，硬編碼對(duì)開(kāi)發(fā)的成本和運(yùn)維的成本都比較高。與此同時(shí)，行業(yè)內(nèi)常見(jiàn)的通用數(shù)據(jù)權(quán)限控制，大都是給單一業(yè)務(wù)使用，和業(yè)務(wù)耦合度較高，可能在當(dāng)前業(yè)務(wù)客戶端是通用可擴(kuò)展的，但是在另一個(gè)業(yè)務(wù)客戶端就無(wú)法做到無(wú)縫接入了。
因此，如何提高數(shù)據(jù)權(quán)限設(shè)置的靈活性，降低耦合性，是本領(lǐng)域技術(shù)人員需要解決的問(wèn)題。
首先來(lái)說(shuō)一下，為什么我們要做這樣一個(gè)多系統(tǒng)的數(shù)據(jù)權(quán)限控制裝置？
大背景是我司當(dāng)前有多個(gè)業(yè)務(wù)系統(tǒng)需要通過(guò)數(shù)據(jù)權(quán)限控制業(yè)務(wù)數(shù)據(jù)，它們的用戶體系或相同或不同，控制維度各有定制。
于是產(chǎn)生諸如以下需求：
為了支持以上需求，于是理所當(dāng)然的出現(xiàn)了如下一套多系統(tǒng)的通用數(shù)據(jù)權(quán)限控制系統(tǒng)。
本系統(tǒng)底層使用統(tǒng)一的一套模型，支持權(quán)限配置化，業(yè)務(wù)方可自定義權(quán)限維度，用戶體系解耦，滿足不同系統(tǒng)快速接入數(shù)據(jù)權(quán)限的業(yè)務(wù)場(chǎng)景。
RBAC是經(jīng)典的功能權(quán)限模型，它是 Role-BasedAccess Control 的英文縮寫，意思是基于角色的訪問(wèn)控制。
運(yùn)營(yíng)事先會(huì)在系統(tǒng)中定義出各種不同的角色，不同的角色擁有不同的權(quán)限，一個(gè)角色實(shí)際上就是一組權(quán)限的集合。而系統(tǒng)的所有用戶都會(huì)被分配到不同的角色中，一個(gè)用戶可能擁有多個(gè)角色。使用這種模型可以極大地簡(jiǎn)化權(quán)限的管理。
但是，在該模型下，系統(tǒng)只會(huì)驗(yàn)證用戶甲是否屬于角色A，而不會(huì)判斷用戶甲是否能訪問(wèn)只屬于用戶乙的數(shù)據(jù) Data。這種問(wèn)題我們稱之為“水平權(quán)限管理問(wèn)題”。
所以，為了解決這個(gè)問(wèn)題，我們基于 RBAC 模型下，又?jǐn)U展了功能和維度的概念，使系統(tǒng)能基于角色控制用戶的數(shù)據(jù)權(quán)限。如下：
圖片
同時(shí)，為了做到多系統(tǒng)通用，我們又對(duì)系統(tǒng)、功能、權(quán)限做了如下抽象：
圖片
模型把每個(gè)系統(tǒng)抽象成由一個(gè)個(gè)業(yè)務(wù)組成，業(yè)務(wù)下分解成多個(gè)功能，功能對(duì)應(yīng)多個(gè)維度:
根據(jù)以上描述，顯而易見(jiàn)的，要實(shí)現(xiàn)數(shù)據(jù)權(quán)限，最重要的是需要抽象出數(shù)據(jù)規(guī)則。
比如我們營(yíng)銷系統(tǒng)的訂單列表，需要從下面幾個(gè)維度來(lái)控制數(shù)據(jù)訪問(wèn)權(quán)限。
銷售人員只能看自己的數(shù)據(jù)；
a 部門的人只能看自己部門的數(shù)據(jù)；
a 部門的上級(jí)部門 A 的人能看自己部門的數(shù)據(jù)和下級(jí) b 部門的人；
上面的這些維度就是數(shù)據(jù)規(guī)則。
這樣數(shù)據(jù)規(guī)則的幾個(gè)重點(diǎn)要素我們也明晰了，就是規(guī)則字段，規(guī)則表達(dá)式，規(guī)則值，上面三個(gè)場(chǎng)景對(duì)應(yīng)的規(guī)則分別如下：
規(guī)則字段：創(chuàng)建人，規(guī)則表達(dá)式：= ，規(guī)則值：當(dāng)前登錄人
規(guī)則字段：所屬部門，規(guī)則表達(dá)式：= ，規(guī)則值：a
規(guī)則字段：所屬部門，規(guī)則表達(dá)式：in ，規(guī)則值：A,a
即數(shù)據(jù)規(guī)則由【維度+條件表達(dá)式+維度對(duì)應(yīng)值】組成，業(yè)務(wù)數(shù)據(jù)的數(shù)據(jù)權(quán)限就是由多個(gè)數(shù)據(jù)規(guī)則組成的范圍控制。具體模型如下：
圖片
那么，本套多系統(tǒng)權(quán)限控制系統(tǒng)，到底該如何接入呢？大致流程如下：
圖片
按照此通用方案，數(shù)據(jù)控制整體接入過(guò)程如下：
1.業(yè)務(wù)確定需要數(shù)據(jù)權(quán)限接入的功能。
2.產(chǎn)品、開(kāi)發(fā)、業(yè)務(wù)確認(rèn)功能的維度。
3.運(yùn)營(yíng)在開(kāi)發(fā)的支持下在運(yùn)營(yíng)管理端配置數(shù)據(jù)權(quán)限，包括支持的維度、表達(dá)式、固定值等等。如需自定義維度對(duì)應(yīng)值，實(shí)現(xiàn)對(duì)應(yīng)端口。
4.各系統(tǒng)管理員登錄各自的數(shù)據(jù)權(quán)限配置端，設(shè)置每個(gè)角色的數(shù)據(jù)規(guī)則。
5.客戶訪問(wèn)系統(tǒng)的具體功能，根據(jù)客戶的角色，獲得數(shù)據(jù)規(guī)則，根據(jù)數(shù)據(jù)規(guī)則組裝業(yè)務(wù)數(shù)據(jù)返回。
訂單是很常見(jiàn)的系統(tǒng)功能，當(dāng)前，需要對(duì)不同員工查看訂單的數(shù)據(jù)范圍做控制，根據(jù)員工所屬的部門不同，查看對(duì)應(yīng)部門的訂單列表。
步驟一：確定系統(tǒng)、功能、維度
系統(tǒng)：xxx系統(tǒng) 功能：訂單列表 維度：部門
步驟二：管理端配置數(shù)據(jù)權(quán)限
圖片
步驟三：業(yè)務(wù)方接入 Sdk，實(shí)現(xiàn)自定義維度（部門）選擇項(xiàng)配置端口
示意代碼
/** * 獲取維度選擇項(xiàng) */List<DimensionOption> getDimensionOptionList(List<String> dimensionCodes);步驟四: 對(duì)應(yīng)api查詢數(shù)據(jù)接口接入 Sdk，完成數(shù)據(jù)過(guò)濾
步驟五: 系統(tǒng)管理員配置角色數(shù)據(jù)權(quán)限
只要完成以上5步，就實(shí)現(xiàn)了接入數(shù)據(jù)權(quán)限的功能。整個(gè)流程只有接入 Sdk 的成本，1天內(nèi)即可完成，快速、高效，極大的降低了成本。同時(shí)公司內(nèi)所有系統(tǒng)都擁有了一套完整統(tǒng)一的權(quán)限控制系統(tǒng)。
那么，底層究竟是如何實(shí)現(xiàn)數(shù)據(jù)權(quán)限控制的？
以下是一個(gè)請(qǐng)求的控制鏈路：
圖片
權(quán)限 Sdk 是真正實(shí)現(xiàn)權(quán)限控制的核心組件。
圖片
Sdk 中的基石是一個(gè)個(gè)對(duì)外開(kāi)放的端口，其中最底層的是上下文端口。接入方需實(shí)現(xiàn)這個(gè)端口接口，根據(jù)當(dāng)前緩存用戶封裝數(shù)據(jù)權(quán)限上下文。如有自定義維度，需實(shí)現(xiàn)自定義維度選擇項(xiàng)端口，返回業(yè)務(wù)自定義的維度選擇項(xiàng)。
數(shù)據(jù)權(quán)限生效實(shí)現(xiàn)過(guò)程如下：
1.請(qǐng)求 Path 被 Sdk 攔截，通過(guò)正則匹配配置的權(quán)限 Api，匹配到說(shuō)明需要被控制。
2.在功能接口中，Sdk 根據(jù)上下文端口獲取當(dāng)前請(qǐng)求上下文，根據(jù)上下文獲取對(duì)應(yīng)用戶所有角色的數(shù)據(jù)權(quán)限。
3.根據(jù)數(shù)據(jù)權(quán)限設(shè)置的配置，組裝權(quán)限控制的條件。
4.業(yè)務(wù)方查詢時(shí)加上權(quán)限控制條件，得到的數(shù)據(jù)，就是控制了數(shù)據(jù)權(quán)限后的數(shù)據(jù)。
ps:本sdk只針對(duì)java語(yǔ)言的后端
如果業(yè)務(wù)方使用的是 MyBatis 的 Xml 原生語(yǔ)句， Sdk 會(huì)把所有的數(shù)據(jù)權(quán)限組裝成對(duì)應(yīng)的 Sql 片段，自動(dòng)對(duì)XML查詢注入該 Sql 片段；如果使用的是 MyBatis-plus 的 QueryWrapper 方式，Sdk 會(huì)把所有的數(shù)據(jù)權(quán)限自動(dòng)注入到生成的 QueryWrapper 條件中。
業(yè)務(wù)方也可以自主使用權(quán)限控制配置查詢數(shù)據(jù)，關(guān)閉 Sdk 的自動(dòng)注入。
還有更多的類似問(wèn)題，都是多系統(tǒng)數(shù)據(jù)權(quán)限控制需要解決的。雖然具體到每個(gè)小點(diǎn)，單從技術(shù)的角度來(lái)說(shuō)，可能未必很難，但要支持更多系統(tǒng)，具備更好的通用化，還有很長(zhǎng)的一段路可走。這是一個(gè)會(huì)隨著業(yè)務(wù)的發(fā)展，需要持續(xù)改進(jìn)的工作。
本文鏈接：http://www.tebozhan.com/showinfo-26-16497-0.html權(quán)限管理——多系統(tǒng)下的數(shù)據(jù)權(quán)限通用控制
聲明：本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問(wèn)題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請(qǐng)聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)