@

• 1. 權(quán)限顆粒度
• 2. 權(quán)限表
• 3. 后端權(quán)限判斷
• 4. 角色與權(quán)限4.1 RBAC 簡(jiǎn)介4.2 RBAC 的提出4.3 RBAC 三原則4.4 RBAC 模型分類4.5 擴(kuò)展
• 5. 表設(shè)計(jì)
• 6. 代碼實(shí)現(xiàn)

因?yàn)閷懥瞬簧?Spring Security 文章的緣故，所以總是有小伙伴來問松哥：按鈕級(jí)別的權(quán)限怎么實(shí)現(xiàn)？甚至有一些看過 vhr 的小伙伴也問這種問題，其實(shí)有的時(shí)候搞得我確實(shí)挺郁悶的，最近剛好要做 TienChin 項(xiàng)目，我就再把這個(gè)問題拎出來和小伙伴們仔細(xì)捋一捋。

1. 權(quán)限顆粒度

首先小伙伴們都知道權(quán)限有不同的顆粒度，在 vhr 項(xiàng)目中，整體上我是基于請(qǐng)求地址去處理權(quán)限的，這個(gè)粒度算粗還是算細(xì)呢？

有的小伙伴們可能認(rèn)為這個(gè)權(quán)限粒度太粗，所謂細(xì)粒度的權(quán)限應(yīng)該是基于按鈕的。

如果有小伙伴們做過前后端不分的開發(fā)，應(yīng)該會(huì)有這樣的體會(huì)：在 Shiro 或者 Spring Security 框架中，都提供了一些標(biāo)簽，通過這些標(biāo)簽可以做到在滿足某種角色或者權(quán)限的情況下，顯示某個(gè)按鈕；當(dāng)用戶不具備某種角色或者權(quán)限的時(shí)候，按鈕則會(huì)自動(dòng)隱藏起來。

但是大家想想，按鈕的顯示與隱藏不過是前端頁面為了提高用戶體驗(yàn)而作出的樣式的變化而已，本質(zhì)上，當(dāng)你點(diǎn)擊一個(gè)按鈕的時(shí)候，還是發(fā)送了一個(gè) HTTP 請(qǐng)求，那么服務(wù)端處理該請(qǐng)求的接口，必須要進(jìn)行權(quán)限控制。既然要在接口上進(jìn)行權(quán)限控制，那么跟 vhr 的區(qū)別在哪里呢？

現(xiàn)在流行前后端分離開發(fā)，所以 Shiro 或者 Spring Security 中的那些前端標(biāo)簽現(xiàn)在基本上都不用了，取而代之的做法是用戶在登錄成功之后，向服務(wù)端發(fā)送請(qǐng)求，獲取當(dāng)前登錄用戶的權(quán)限以及角色信息，然后根據(jù)這些權(quán)限、角色等信息，在前端自動(dòng)的去判斷一個(gè)菜單或者按鈕應(yīng)該是顯示還是隱藏，這么做的目的是為了提高用戶體驗(yàn)，避免用戶點(diǎn)擊一個(gè)沒有權(quán)限的按鈕。前端的顯示或者隱藏僅僅只是為了提高用戶體驗(yàn)，真正的權(quán)限控制還是要后端來做。

后端可以在接口或者業(yè)務(wù)層對(duì)權(quán)限進(jìn)行處理，具體在哪里做，就要看各自的項(xiàng)目了。

所以，vhr 中的權(quán)限，從設(shè)計(jì)上來說，粒度并不算粗，也是細(xì)粒度的，只不過跟菜單表放在了一起，小伙伴們可能感覺有點(diǎn)粗。但是，菜單表是可以繼續(xù)細(xì)化的，我們可以繼續(xù)在菜單表中添加新的記錄，新記錄的 hidden 字段為 true，則菜單是隱藏的，就單純只是細(xì)化權(quán)限而已。

如下圖可以繼續(xù)添加新的訪問規(guī)則，只不過把 enabled 字段設(shè)置為 false 即可（這樣菜單就不會(huì)顯示出來了，單純就只是權(quán)限的配置）。

所以 vhr 的權(quán)限設(shè)計(jì)是 OK 的。

當(dāng)你理解了 vhr 中的權(quán)限設(shè)計(jì)，再來看 TienChin 這個(gè)項(xiàng)目，或者說看 RuoYi-Vue 這個(gè)腳手架，就會(huì)發(fā)現(xiàn)非常 easy 了。

2. 權(quán)限表

首先我們來看看資源表的定義，也就是 sys_menu。

CREATE TABLE `sys_menu` ( `menu_id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT ‘菜單ID’, `menu_name` varchar(50) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT ‘菜單名稱’, `parent_id` bigint(20) DEFAULT ‘0’ COMMENT ‘父菜單ID’, `order_num` int(4) DEFAULT ‘0’ COMMENT ‘顯示順序’, `path` varchar(200) COLLATE utf8mb4_unicode_ci DEFAULT ” COMMENT ‘路由地址’, `component` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT ‘組件路徑’, `query` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT ‘路由參數(shù)’, `is_frame` int(1) DEFAULT ‘1’ COMMENT ‘是否為外鏈（0是 1否）’, `is_cache` int(1) DEFAULT ‘0’ COMMENT ‘是否緩存（0緩存 1不緩存）’, `menu_type` char(1) COLLATE utf8mb4_unicode_ci DEFAULT ” COMMENT ‘菜單類型（M目錄 C菜單 F按鈕）’, `visible` char(1) COLLATE utf8mb4_unicode_ci DEFAULT ‘0’ COMMENT ‘菜單狀態(tài)（0顯示 1隱藏）’, `status` char(1) COLLATE utf8mb4_unicode_ci DEFAULT ‘0’ COMMENT ‘菜單狀態(tài)（0正常 1停用）’, `perms` varchar(100) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT ‘權(quán)限標(biāo)識(shí)’, `icon` varchar(100) COLLATE utf8mb4_unicode_ci DEFAULT ‘#’ COMMENT ‘菜單圖標(biāo)’, `create_by` varchar(64) COLLATE utf8mb4_unicode_ci DEFAULT ” COMMENT ‘創(chuàng)建者’, `create_time` datetime DEFAULT NULL COMMENT ‘創(chuàng)建時(shí)間’, `update_by` varchar(64) COLLATE utf8mb4_unicode_ci DEFAULT ” COMMENT ‘更新者’, `update_time` datetime DEFAULT NULL COMMENT ‘更新時(shí)間’, `remark` varchar(500) COLLATE utf8mb4_unicode_ci DEFAULT ” COMMENT ‘備注’, PRIMARY KEY (`menu_id`)) ENGINE=InnoDB AUTO_INCREMENT=3054 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT=’菜單權(quán)限表’;

其實(shí)這里很多字段都和我們 vhr 項(xiàng)目項(xiàng)目很相似，我也就不重復(fù)啰嗦了，我這里主要和小伙伴們說一個(gè)字段，那就是 menu_type。

menu_type 表示一個(gè)菜單字段的類型，一個(gè)菜單有三種類型，分別是目錄（M）、菜單（C）以及按鈕（F）。這里所說的目錄，相當(dāng)于我們?cè)?vhr 中所說的一級(jí)菜單，菜單相當(dāng)于我們?cè)?vhr 中所說的二級(jí)菜單。

當(dāng)用戶從前端登錄成功后，要去動(dòng)態(tài)加載的菜單的時(shí)候，就查詢 M 和 C 類型的數(shù)據(jù)即可，F(xiàn) 類型的數(shù)據(jù)不是菜單項(xiàng)，查詢的時(shí)候直接過濾掉即可，通過 menu_type 這個(gè)字段可以輕松的過濾掉 F 類型的數(shù)據(jù)。小伙伴們想想，F(xiàn) 類型的數(shù)據(jù)過濾掉之后，剩下的數(shù)據(jù)不就是一級(jí)菜單和二級(jí)菜單了，那不就和 vhr 又一樣了么！

最后再來說說 F 類型的，F(xiàn) 類型的就是按鈕級(jí)別的權(quán)限了，前端每一個(gè)按鈕的執(zhí)行，需要哪些權(quán)限，現(xiàn)在就在這里定義好。

舉一個(gè)簡(jiǎn)單的例子大家來看下：

當(dāng)需要展示用戶管理這個(gè)菜單的時(shí)候，需要 system:user:list 這個(gè)權(quán)限，當(dāng)需要點(diǎn)擊用戶修改這個(gè)按鈕的時(shí)候，則需要 system:user:edit 這個(gè)權(quán)限。

其他相關(guān)的表基本上和 vhr 都是一樣的，用戶有用戶表 sys_user，角色有角色表 sys_role，用戶和角色關(guān)聯(lián)的表是 sys_user_role，資源和角色關(guān)聯(lián)的表是 sys_role_menu。

當(dāng)用戶登錄成功后，后端會(huì)提供一個(gè)接口，將當(dāng)前用戶的角色和權(quán)限統(tǒng)統(tǒng)返回給前端：

• 查詢角色思路：根據(jù)用戶 id，先去 sys_user_role 表中查詢到角色 id，再根據(jù)角色 id 去 sys_role 表中查詢到對(duì)應(yīng)的角色（這里為了方便大家理解這么描述，實(shí)際上一個(gè)多表聯(lián)合查詢即可）。
• 查詢權(quán)限思路：根據(jù)用戶 id，先去 sys_user_role 表中查詢到角色 id，再根據(jù)角色 id 去 sys_role 表中查詢到對(duì)應(yīng)的角色，再拿著角色 id 去 sys_role_menu 表中查詢到對(duì)應(yīng)的 menu_id，再根據(jù) menu_id 去 sys_menu 表中查詢到對(duì)應(yīng)的 menu 中的權(quán)限（這里為了方便大家理解這么描述，實(shí)際上一個(gè)多表聯(lián)合查詢即可）。

前端有了用戶的權(quán)限以及角色之后，就可以自行決定是否顯示某一個(gè)菜單或者是否展示某一個(gè)按鈕了。

3. 后端權(quán)限判斷

我先來說說這塊 TienChin 項(xiàng)目中是怎么做的（即 RuoYi 腳手架的實(shí)現(xiàn)方案），再來和 vhr 進(jìn)行一個(gè)對(duì)比。

在 TienChin 項(xiàng)目中是通過注解來控制權(quán)限的，接口的訪問權(quán)限都是通過注解來標(biāo)記的，例如下面這種：

@PreAuthorize(“@ss.hasPermi(‘system:menu:add’)”)@PostMappingpublic AjaxResult add(@Validated @RequestBody SysMenu menu) { //省略}/** * 修改菜單 */@PreAuthorize(“@ss.hasPermi(‘system:menu:edit’)”)@PutMappingpublic AjaxResult edit(@Validated @RequestBody SysMenu menu) { //省略}/** * 刪除菜單 */@PreAuthorize(“@ss.hasPermi(‘system:menu:remove’)”)@DeleteMapping(“/{menuId}”)public AjaxResult remove(@PathVariable(“menuId”) Long menuId) { //省略}

每一個(gè)接口需要什么權(quán)限，都是通過 @PreAuthorize 注解來實(shí)現(xiàn)的，關(guān)于這個(gè)注解的使用原理，松哥之前也有兩篇文章：

• 想要控制好權(quán)限，這八個(gè)注解你必須知道！
• Spring Security 中的權(quán)限注解很神奇嗎？

看懂了這兩篇文章，上面這個(gè)注解就懂了，我這里不贅述。

不過上面這種寫法說到底還是有一點(diǎn)“硬編碼”，因?yàn)樵L問哪個(gè)接口需要哪些權(quán)限，在代碼中固定了，如果接口和權(quán)限直接的關(guān)系能夠保存到數(shù)據(jù)庫中，那么用戶就可以在自己需要的時(shí)候，隨時(shí)進(jìn)行靈活修改，豈不美哉！

在 vhr 項(xiàng)目中，松哥利用 Spring Security 中自定義 FilterInvocationSecurityMetadataSource 和 AccessDecisionManager 實(shí)現(xiàn)了服務(wù)端動(dòng)態(tài)控制權(quán)限。這個(gè)具體的實(shí)現(xiàn)思路之前的文章中也和大家分享過了，傳送門：Spring Security 動(dòng)態(tài)權(quán)限實(shí)現(xiàn)方案！，這里就不贅述了。

相對(duì)來說，vhr 中的實(shí)現(xiàn)方案更靈活一些，因?yàn)榭梢耘渲媒涌诤蜋?quán)限之間的關(guān)系。不過怎么說呢？其實(shí)像 RuoYi-Vue 這樣硬編碼其實(shí)也不是不可以，畢竟接口和權(quán)限之間的映射關(guān)系還是稍顯“專業(yè)”一些，普通用戶可能并不懂該如何配置，這個(gè)加入說系統(tǒng)提供了這個(gè)功能，那么更多的還是面向程序員這一類專業(yè)人員的，那么程序員到底是否需要這個(gè)功能呢？我覺得還是得具體情況具體分析。

總之，小伙伴們可以結(jié)合自己項(xiàng)目的實(shí)際情況，來決定接口和權(quán)限之間的映射關(guān)系是否需要?jiǎng)討B(tài)管理，如果需要?jiǎng)討B(tài)管理，那么可以按照 vhr 中的方案來，如果不需要?jiǎng)討B(tài)管理，那么就按照 RuoYi-Vue 腳手架中的方式來就行了。

那么用戶的權(quán)限該如何設(shè)置？今天我們就來聊聊這個(gè)話題。

4. 角色與權(quán)限

首先我們先來看看角色與權(quán)限，該如何設(shè)計(jì)角色與權(quán)限，其實(shí)有很多非常成熟的理論，最為常見的莫過于 RBAC 了。

4.1 RBAC 簡(jiǎn)介

RBAC（Role-based access control）是一種以角色為基礎(chǔ)的訪問控制（Role-based access control，RBAC），它是一種較新且廣為使用的權(quán)限控制機(jī)制，這種機(jī)制不是直接給用戶賦予權(quán)限，而是將權(quán)限賦予角色。

RBAC 權(quán)限模型將用戶按角色進(jìn)行歸類，通過用戶的角色來確定用戶對(duì)某項(xiàng)資源是否具備操作權(quán)限。RBAC 簡(jiǎn)化了用戶與權(quán)限的管理，它將用戶與角色關(guān)聯(lián)、角色與權(quán)限關(guān)聯(lián)、權(quán)限與資源關(guān)聯(lián)，這種模式使得用戶的授權(quán)管理變得非常簡(jiǎn)單和易于維護(hù)。

4.2 RBAC 的提出

權(quán)限、角色這些東西，在早期 1970 年代的商業(yè)計(jì)算機(jī)程序中就可以找到相關(guān)的應(yīng)用，但是早期的程序相對(duì)簡(jiǎn)單，而且并不存在一個(gè)明確的、通用的、公認(rèn)的權(quán)限管理模型。

Ferraiolo 和 Kuhn 兩位大佬于 1992 年提出了一種基于通用角色的訪問控制模型（看來這個(gè)模型比松哥年齡還大），首次提出了 RBAC 權(quán)限模型用來代替?zhèn)鹘y(tǒng)的 MAC 和 DAC 兩種權(quán)限控制方案，并且就 RBAC 中的相關(guān)概念給出了解釋。

Ferraiolo，Cugini 和 Kuhn 于 1995 年擴(kuò)展了 1992 年提出的權(quán)限模型。該模型的主要功能是所有訪問都是通過角色進(jìn)行的，而角色本質(zhì)上是權(quán)限的集合，并且所有用戶只能通過角色獲得權(quán)限。在組織內(nèi)，角色相對(duì)穩(wěn)定，而用戶和權(quán)限都很多，并且可能會(huì)迅速變化。因此，通過角色控制權(quán)限可以簡(jiǎn)化訪問控制的管理和檢查。

到了 1996 年，Sandhu，Coyne，F(xiàn)einstein 和 Youman 正式提出了 RBAC 模型，該模型以模塊化方式細(xì)化了 RBAC，并提出了基于該理論的 RBAC0-RBAC3 四種不同模型。

今天，大多數(shù)信息技術(shù)供應(yīng)商已將 RBAC 納入其產(chǎn)品線，除了常規(guī)的企業(yè)級(jí)應(yīng)用，RBAC 也廣泛應(yīng)用在醫(yī)療、國防等領(lǐng)域。

目前網(wǎng)上關(guān)于 RBAC 理論性的東西松哥只找到英文的，感興趣的小伙伴可以看下，地址是：

• https://csrc.nist.gov/projects/Role-Based-Access-Control

如果小伙伴們有中文的資料鏈接，歡迎留言說明。

4.3 RBAC 三原則

4.4 RBAC 模型分類

說到 RBAC，我們就得從它的模型分類開始看起。

4.4.1 RBAC0

RBAC0 是最簡(jiǎn)單的用戶、角色、權(quán)限模型。RBAC0 是 RBAC 權(quán)限模型中最核心的一部分，后面其他模型都是在此基礎(chǔ)上建立。

圖片源自網(wǎng)絡(luò)

在 RBAC0 中，一個(gè)用戶可以具備多個(gè)角色，一個(gè)角色可以具備多個(gè)權(quán)限，最終用戶所具備的權(quán)限是用戶所具備的角色的權(quán)限并集。

4.4.2 RBAC1

RBAC1 則是在 RABC0 的基礎(chǔ)上引入了角色繼承，讓角色有了上下級(jí)關(guān)系。

圖片源自網(wǎng)絡(luò)

在本系列前面的文章中，松哥也曾多次向大家介紹過 Spring Security 中的角色繼承。

4.4.3 RBAC2

RBAC2 也是在 RBAC0 的基礎(chǔ)上進(jìn)行擴(kuò)展，引入了靜態(tài)職責(zé)分離和動(dòng)態(tài)職責(zé)分離。

圖片源自網(wǎng)絡(luò)

要理解職責(zé)分離，我們得先明白角色互斥。

在實(shí)際項(xiàng)目中，有一些角色是互斥的，對(duì)立的，例如財(cái)務(wù)這個(gè)角色一般是不能和其他角色兼任的，否則自己報(bào)賬自己審批，豈不是爽歪歪！

通過職責(zé)分離可以解決這個(gè)問題：

靜態(tài)職責(zé)分離

在設(shè)置階段就做好了限制。比如同一用戶不能授予互斥的角色，用戶只能有有限個(gè)角色，用戶獲得高級(jí)權(quán)限之前要有低級(jí)權(quán)限等等。

動(dòng)態(tài)職責(zé)分離

在運(yùn)行階段進(jìn)行限制。比如運(yùn)行時(shí)同一用戶下5個(gè)角色中只能同時(shí)有2個(gè)角色激活等等。

4.4.4 RBAC3

將 RBAC1 和 RBAC2 結(jié)合起來，就形成了 RBAC3。

圖片源自網(wǎng)絡(luò)

4.5 擴(kuò)展

我們?nèi)粘Ｒ姷降暮芏鄼?quán)限模型都是在 RBAC 的基礎(chǔ)上擴(kuò)展出來的。

例如在有的系統(tǒng)中我們可以見到用戶組的概念，就是將用戶分組，用戶同時(shí)具備自身的角色以及分組的角色。

我們 TienChin 項(xiàng)目所用的腳手架中的權(quán)限，就基本上是按照 RBAC 這套權(quán)限模型來的。

5. 表設(shè)計(jì)

我們來看下 RuoYi-Vue 腳手架中跟用戶、角色以及權(quán)限相關(guān)的表。

這里主要涉及到如下幾張表：

• sys_user：這個(gè)是用戶表。
• sys_role：這個(gè)是角色表。
• sys_user_role：這個(gè)是用戶角色關(guān)聯(lián)表。
• sys_menu：這個(gè)是菜單表，也可以理解為是資源表。
• sys_role_menu：這個(gè)是資源角色關(guān)聯(lián)表。

通過用戶的 id，可以去 sys_user_role 表中查詢到這個(gè)用戶具備的角色 id，再根據(jù)角色 id，去 sys_role_menu 表中查詢到這個(gè)角色可以操作的資源 id，再根據(jù)資源 id，去 sys_menu 表中查詢到對(duì)應(yīng)的資源，基本上就是這個(gè)樣一個(gè)流程。

那么 Java 代碼中該怎么做呢？

6. 代碼實(shí)現(xiàn)

首先定義了一個(gè) Java 類 SysUser，這個(gè)跟數(shù)據(jù)庫中的 sys_user 表是對(duì)應(yīng)的，我們來看 UserDetailsService 的具體實(shí)現(xiàn)：

@Servicepublic class UserDetailsServiceImpl implements UserDetailsService { private static final Logger log = LoggerFactory.getLogger(UserDetailsServiceImpl.class); @Autowired private ISysUserService userService; @Autowired private SysPermissionService permissionService; @Override public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException { SysUser user = userService.selectUserByUserName(username); if (StringUtils.isNull(user)) { log.info(“登錄用戶：{} 不存在.”, username); throw new ServiceException(“登錄用戶：” + username + ” 不存在”); } else if (UserStatus.DELETED.getCode().equals(user.getDelFlag())) { log.info(“登錄用戶：{} 已被刪除.”, username); throw new ServiceException(“對(duì)不起，您的賬號(hào)：” + username + ” 已被刪除”); } else if (UserStatus.DISABLE.getCode().equals(user.getStatus())) { log.info(“登錄用戶：{} 已被停用.”, username); throw new ServiceException(“對(duì)不起，您的賬號(hào)：” + username + ” 已停用”); } return createLoginUser(user); } public UserDetails createLoginUser(SysUser user) { return new LoginUser(user.getUserId(), user.getDeptId(), user, permissionService.getMenuPermission(user)); }}

從數(shù)據(jù)庫中查詢到的就是 SysUser 對(duì)象，然后對(duì)該對(duì)象稍作改造，將之改造成為一個(gè) LoginUser 對(duì)象，這個(gè) LoginUser 則是 UserDetails 接口的實(shí)現(xiàn)類，里邊保存了當(dāng)前登錄用戶的關(guān)鍵信息。

在創(chuàng)建 LoginUser 對(duì)象的時(shí)候，有一個(gè) permissionService.getMenuPermission 方法用來查詢用戶的權(quán)限，根據(jù)當(dāng)前用戶的 id，查詢到用戶的角色，再根據(jù)用戶角色，查詢到用戶的權(quán)限，另外，如果當(dāng)前用戶的角色是 admin，那么就設(shè)置用戶角色為 *:*:*，這是一段硬編碼。

我們?cè)賮砜纯?LoginUser 的設(shè)計(jì)：

public class LoginUser implements UserDetails { /** * 權(quán)限列表 */ private Set permissions; /** * 用戶信息 */ private SysUser user; public LoginUser(Long userId, Long deptId, SysUser user, Set permissions) { this.userId = userId; this.deptId = deptId; this.user = user; this.permissions = permissions; } @JSONField(serialize = false) @Override public String getPassword() { return user.getPassword(); } @Override public String getUsername() { return user.getUserName(); } /** * 賬戶是否未過期,過期無法驗(yàn)證 */ @JSONField(serialize = false) @Override public boolean isAccountNonExpired() { return true; } /** * 指定用戶是否解鎖,鎖定的用戶無法進(jìn)行身份驗(yàn)證 * * @return */ @JSONField(serialize = false) @Override public boolean isAccountNonLocked() { return true; } /** * 指示是否已過期的用戶的憑據(jù)(密碼),過期的憑據(jù)防止認(rèn)證 * * @return */ @JSONField(serialize = false) @Override public boolean isCredentialsNonExpired() { return true; } /** * 是否可用 ,禁用的用戶不能身份驗(yàn)證 * * @return */ @JSONField(serialize = false) @Override public boolean isEnabled() { return true; } @Override public Collection getAuthorities() { return null; }}

有一些屬性我省略掉了，大家可以文末下載源碼查看。

小伙伴們看到，這個(gè) LoginUser 實(shí)現(xiàn)了 UserDetails 接口，但是和 vhr 中有一個(gè)很大的不同，就是這里沒有處理 getAuthorities 方法，也就是說當(dāng)系統(tǒng)想要去獲取用戶權(quán)限的時(shí)候，二話不說直接返回一個(gè) null。這是咋回事呢？

因?yàn)樵谶@個(gè)腳手架中，將來進(jìn)行權(quán)限校驗(yàn)的時(shí)候，是按照下面這樣來的：

@PreAuthorize(“@ss.hasPermi(‘system:menu:add’)”)@PostMappingpublic AjaxResult add(@Validated @RequestBody SysMenu menu) { //省略}

@PreAuthorize 注解中的 @ss.hasPermi(‘system:menu:add’) 表達(dá)式，表示調(diào)用 Spring 容器中一個(gè)名為 ss 的 Bean 的 hasPermi 方法，去判斷當(dāng)前用戶是否具備一個(gè)名為 system:menu:add 的權(quán)限。一個(gè)名為 ss 的 Bean 的 hasPermi 方法如下：

@Service(“ss”)public class PermissionService { /** * 所有權(quán)限標(biāo)識(shí) */ private static final String ALL_PERMISSION = “*:*:*”; /** * 管理員角色權(quán)限標(biāo)識(shí) */ private static final String SUPER_ADMIN = “admin”; private static final String ROLE_DELIMETER = “,”; private static final String PERMISSION_DELIMETER = “,”; /** * 驗(yàn)證用戶是否具備某權(quán)限 * * @param permission 權(quán)限字符串 * @return 用戶是否具備某權(quán)限 */ public boolean hasPermi(String permission) { if (StringUtils.isEmpty(permission)) { return false; } LoginUser loginUser = SecurityUtils.getLoginUser(); if (StringUtils.isNull(loginUser) || CollectionUtils.isEmpty(loginUser.getPermissions())) { return false; } return hasPermissions(loginUser.getPermissions(), permission); } /** * 判斷是否包含權(quán)限 * * @param permissions 權(quán)限列表 * @param permission 權(quán)限字符串 * @return 用戶是否具備某權(quán)限 */ private boolean hasPermissions(Set permissions, String permission) { return permissions.contains(ALL_PERMISSION) || permissions.contains(StringUtils.trim(permission)); }}

由于這里是純手工操作，在比較的時(shí)候，直接獲取到當(dāng)前登錄用戶對(duì)象 LoginUser，再手動(dòng)調(diào)用他的 hasPermissions 方法去判斷權(quán)限是否滿足，由于都是自定義操作，所以是否實(shí)現(xiàn) UserDetails#getAuthorities 方法已經(jīng)不重要了，不過按照這里的比對(duì)方案，是不支持通配符的比對(duì)的。

例如用戶具備針對(duì)字典表的所有操作權(quán)限，表示為 system:dict:*，但是當(dāng)和 system:dict:list 進(jìn)行比較的時(shí)候，發(fā)現(xiàn)比較結(jié)果為 false，這塊想要比對(duì)成功也是可以的，例如可以通過正則表達(dá)式或者其他方式來操作，反正都是字符串比較，相信大家都能自己搞得定。

現(xiàn)在，前端提供操作頁面，也可以配置每一個(gè)用戶的角色，也可以配置每一個(gè)角色可以操作的權(quán)限就行了，這個(gè)就比較簡(jiǎn)單了，不多說。

好啦，這就是 TienChin 項(xiàng)目中的 RBAC 權(quán)限實(shí)現(xiàn)方案，后面松哥也會(huì)錄制相關(guān)的視頻教程，對(duì)視頻感興趣的小伙伴戳這里：TienChin 項(xiàng)目配套視頻來啦。