---

toB 的系統(tǒng)，除了普通的權(quán)限管理之外，往往還需要數(shù)據(jù)范圍權(quán)限。本文介紹一種，簡單的易實(shí)現(xiàn)的 Saas 多租戶數(shù)據(jù)范圍權(quán)限系統(tǒng)的簡單設(shè)計(jì)與實(shí)現(xiàn)。

權(quán)限的概述

我們一般說權(quán)限的時(shí)候是在說「功能權(quán)限和數(shù)據(jù)權(quán)限」 。

功能權(quán)限指用「戶登陸系統(tǒng)后能看到什么模塊，能看到哪些頁面」 ，

而數(shù)據(jù)權(quán)限指的「是用戶在某個(gè)模塊里能看到幾條數(shù)據(jù)，能看到哪些數(shù)據(jù)」 。

基于 Spring Boot + MyBatis Plus + Vue & Element 實(shí)現(xiàn)的后臺管理系統(tǒng) + 用戶小程序，支持 RBAC 動態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

• 項(xiàng)目地址：https://github.com/YunaiV/ruoyi-vue-pro
• 視頻教程：https://doc.iocoder.cn/video/

功能權(quán)限

在企業(yè)系統(tǒng)中，通過配置用戶的功能權(quán)限可以解決不同的人分管不同業(yè)務(wù)的需求，基于RBAC模型，RBAC（Role Based Access Control)模型，它的中文是基于角色的訪問控制，主要是將功能組合成角色，再將角色分配給用戶，也就是說「角色是功能的合集。」

為何要基于RBAC

企業(yè)A一共有12個(gè)功能，需要?jiǎng)?chuàng)建100個(gè)用戶，這些用戶中有管財(cái)務(wù)的、有管人事的、有管銷售的等等。如果不引入RBAC模型，我們需要每創(chuàng)建一個(gè)用戶就要分配一次功能，至少（每個(gè)用戶只有一個(gè)功能）操作100次，如果人數(shù)增加到1000甚至10000，并且一個(gè)用戶可能會有多個(gè)功能的時(shí)候，操作會非常繁瑣，如圖：

為何要基于RBAC

經(jīng)過多次操作發(fā)現(xiàn)：分配給某些人的功能都是相同的，比如分配給A、B等10個(gè)用戶的功能都是客戶管理、訂單管理及供應(yīng)商管理這幾個(gè)模塊，那是不是可以把這幾個(gè)功能模塊打成一個(gè)包整體分給需要的用戶呢？

這個(gè)包就叫做角色。由于角色和功能的對應(yīng)關(guān)系相對固定，給用戶分配權(quán)限的時(shí)候只分配角色即可。

為何要基于RBAC

總結(jié)：

1. 解耦用戶和功能，降低操作錯(cuò)誤率；
2. 降低功能權(quán)限分配的繁瑣程度。

為何要基于RBAC

功能粒度

功能的粒度從粗到細(xì)一般分為：「模塊級->頁面級->接口級（接口級的功能權(quán)限指的是哪個(gè)角色能調(diào)用哪些接口）。」

從后臺角度：為了系統(tǒng)安全，代碼肯定都會實(shí)現(xiàn)到接口級。那我們做粒度選擇的意義是什么？當(dāng)然是為用戶降本增效。只是粒度越粗，用戶操作越簡單，靈活性卻越低。

用戶的優(yōu)先級

我們常用的優(yōu)先級順序是查看「詳情>查看列表>增加、刪除、編輯、其他操作按鈕」 。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實(shí)現(xiàn)的后臺管理系統(tǒng) + 用戶小程序，支持 RBAC 動態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

• 項(xiàng)目地址：https://github.com/YunaiV/yudao-cloud
• 視頻教程：https://doc.iocoder.cn/video/

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

數(shù)據(jù)權(quán)限解決的是用戶能看到多少數(shù)據(jù)量和什么數(shù)據(jù)的問題，例如A和B兩個(gè)用戶都能看到銷售模塊，但A能看到320條數(shù)據(jù)，B只能看到100條數(shù)據(jù)，且A能看到的320條數(shù)據(jù)中包含著B能看到的100條數(shù)據(jù)，這些都是由數(shù)據(jù)權(quán)限決定的。

數(shù)據(jù)權(quán)限和什么有關(guān)系

數(shù)據(jù)權(quán)限一般和企業(yè)的組織架構(gòu)相關(guān)，而組織架構(gòu)分為樹狀和扁平狀的（還有更復(fù)雜組織架構(gòu)，此處暫不做說明）

數(shù)據(jù)權(quán)限和什么有關(guān)系

「數(shù)據(jù)權(quán)限主要和組織架構(gòu)有關(guān)」 ，組織架構(gòu)中樹狀架構(gòu)較為復(fù)雜，需要統(tǒng)一或者分模塊的定義層級間數(shù)據(jù)共享問題。

數(shù)據(jù)權(quán)限定義過程中如果出現(xiàn)同一結(jié)點(diǎn)下的【用戶間層級問題（上下級）】需要回到功能權(quán)限的【角色定義】去解決。

數(shù)據(jù)權(quán)限的操作步驟

思想

「數(shù)據(jù)權(quán)限的控制是通過部門的菜單展示來實(shí)現(xiàn)的。」

用到數(shù)據(jù)權(quán)限的地方

1. 用戶添加時(shí)候，選擇部門的下拉框

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

2. 部門管理的列表

部門管理的列表

3. 角色管理，新增彈框頁面，選擇部門的樹狀菜單

角色管理

部門管理中部門列表的數(shù)據(jù)權(quán)限

controller層加載部門列表，加載全部部門信息

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

sevice層邏輯：將當(dāng)前登錄用戶所擁有的部門id設(shè)置成查詢部門列表的where的篩選條件

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

定義一個(gè)commonDataservice層：獲取用戶所具有的所有部門ids

1. 在commonDataService類中的getCurrUserDataDeptIds()方法，獲取當(dāng)前登錄用戶的部門數(shù)據(jù)ids列表

圖片

2. 如果當(dāng)前登錄用戶id為超級管理員，則加載全部菜單信息，如下圖所示：

圖片

3. 如果當(dāng)前登錄用戶id不為超級管理員，通過用戶id，獲取sys_role_dpet,sys_user_role這兩張表進(jìn)行關(guān)聯(lián)（「已擁有制定部門的權(quán)利且未占用」 ），獲取該登錄用戶所屬的部門id

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

4. 數(shù)據(jù)權(quán)限用戶已經(jīng)分配且已經(jīng)擁有的部門（「已擁有制定部門的權(quán)利且已占用」 ），「作用是選擇了一個(gè)一級部門，那么一級部門所包含的二級部門，三級部門等也要賦值給用戶，也就是說擁有的部門下面還有子部門，那么也具有該部門以及子部門的擁有權(quán)，使用遞歸算法全部遍歷獲得。」 如下圖所示

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

5. 將當(dāng)前登錄用戶所擁有的部門id通過逗號進(jìn)行拼接

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

用戶新增彈框中的部門列表的數(shù)據(jù)權(quán)限

同樣調(diào)用的是SysDepartController中的depart/list的方法，邏輯見2.3節(jié)

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

角色管理中新增彈框中的部門列表的數(shù)據(jù)權(quán)限

同樣調(diào)用的是SysDepartController中的depart/list的方法，邏輯見2.3節(jié)

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

操作案例

1. 例如用戶debug用戶的角色為操作權(quán)限角色，分配部門為開發(fā)一部下面的測試部門

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

2. 使用超級管理員，給操作權(quán)限角色分配數(shù)據(jù)權(quán)限，這里選擇新分配一個(gè)開發(fā)二部下面的測試部，如下圖所示：

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

3. 使用debug用戶登錄查詢

用戶登錄查詢

關(guān)于數(shù)據(jù)范圍權(quán)限的設(shè)計(jì)與實(shí)現(xiàn)，你有什么好的方案？歡迎留言評論！

---

---