Spring Security許可權想要細化到按鈕實現範例

2022-07-18 18:04:43

引言

因為寫了不少 Spring Security 文章的緣故，所以總是有小夥伴來問鬆哥：按鈕級別的許可權怎麼實現？甚至有一些看過 vhr 的小夥伴也問這種問題，其實有的時候搞得我確實挺鬱悶的，最近剛好要做 TienChin 專案，我就再把這個問題拎出來和小夥伴們仔細捋一捋。

1. 許可權顆粒度

首先小夥伴們都知道許可權有不同的顆粒度，在 vhr 專案中，整體上我是基於請求地址去處理許可權的，這個粒度算粗還是算細呢？

有的小夥伴們可能認為這個許可權粒度太粗，所謂細粒度的許可權應該是基於按鈕的。

如果有小夥伴們做過前後端不分的開發，應該會有這樣的體會：在 Shiro 或者 Spring Security 框架中，都提供了一些標籤，通過這些標籤可以做到在滿足某種角色或者許可權的情況下，顯示某個按鈕；當用戶不具備某種角色或者許可權的時候，按鈕則會自動隱藏起來。

但是大家想想，按鈕的顯示與隱藏不過是前端頁面為了提高使用者體驗而作出的樣式的變化而已，本質上，當你點選一個按鈕的時候，還是傳送了一個 HTTP 請求，那麼伺服器端處理該請求的介面，必須要進行許可權控制。既然要在介面上進行許可權控制，那麼跟 vhr 的區別在哪裡呢？

現在流行前後端分離開發，所以 Shiro 或者 Spring Security 中的那些前端標籤現在基本上都不用了，取而代之的做法是使用者在登入成功之後，向伺服器端傳送請求，獲取當前登入使用者的許可權以及角色資訊，然後根據這些許可權、角色等資訊，在前端自動的去判斷一個選單或者按鈕應該是顯示還是隱藏，這麼做的目的是為了提高使用者體驗，避免使用者點選一個沒有許可權的按鈕。前端的顯示或者隱藏僅僅只是為了提高使用者體驗，真正的許可權控制還是要後端來做。

後端可以在介面或者業務層對許可權進行處理，具體在哪裡做，就要看各自的專案了。

所以，vhr 中的許可權，從設計上來說，粒度並不算粗，也是細粒度的，只不過跟選單表放在了一起，小夥伴們可能感覺有點粗。但是，選單表是可以繼續細化的，我們可以繼續在選單表中新增新的記錄，新記錄的 hidden 欄位為 true，則選單是隱藏的，就單純只是細化許可權而已。

如下圖可以繼續新增新的存取規則，只不過把 enabled 欄位設定為 false 即可（這樣選單就不會顯示出來了，單純就只是許可權的設定）。

所以 vhr 的許可權設計是 OK 的。

當你理解了 vhr 中的許可權設計，再來看 TienChin 這個專案，或者說看 RuoYi-Vue 這個腳手架，就會發現非常 easy 了。

2. 許可權表

首先我們來看看資源表的定義，也就是 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 '路由引數',
  `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 '選單狀態（0顯示 1隱藏）',
  `status` char(1) COLLATE utf8mb4_unicode_ci DEFAULT '0' COMMENT '選單狀態（0正常 1停用）',
  `perms` varchar(100) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT '許可權標識',
  `icon` varchar(100) COLLATE utf8mb4_unicode_ci DEFAULT '#' COMMENT '選單圖示',
  `create_by` varchar(64) COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '建立者',
  `create_time` datetime DEFAULT NULL COMMENT '建立時間',
  `update_by` varchar(64) COLLATE utf8mb4_unicode_ci DEFAULT '' COMMENT '更新者',
  `update_time` datetime DEFAULT NULL COMMENT '更新時間',
  `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='選單許可權表';

其實這裡很多欄位都和我們 vhr 專案專案很相似，我也就不重複囉嗦了，我這裡主要和小夥伴們說一個欄位，那就是 menu_type。

menu_type 表示一個選單欄位的型別，一個選單有三種型別，分別是目錄（M）、選單（C）以及按鈕（F）。這裡所說的目錄，相當於我們在 vhr 中所說的一級選單，選單相當於我們在 vhr 中所說的二級選單。

當用戶從前端登入成功後，要去動態載入的選單的時候，就查詢 M 和 C 型別的資料即可，F 型別的資料不是選單項，查詢的時候直接過濾掉即可，通過 menu_type 這個欄位可以輕鬆的過濾掉 F 型別的資料。小夥伴們想想，F 型別的資料過濾掉之後，剩下的資料不就是一級選單和二級選單了，那不就和 vhr 又一樣了麼！

最後再來說說 F 型別的，F 型別的就是按鈕級別的許可權了，前端每一個按鈕的執行，需要哪些許可權，現在就在這裡定義好。

舉一個簡單的例子大家來看下：

當需要展示使用者管理這個選單的時候，需要 system:user:list 這個許可權，當需要點選使用者修改這個按鈕的時候，則需要 system:user:edit 這個許可權。

其他相關的表基本上和 vhr 都是一樣的，使用者有使用者表 sys_user，角色有角色表 sys_role，使用者和角色關聯的表是 sys_user_role，資源和角色關聯的表是 sys_role_menu。

當用戶登入成功後，後端會提供一個介面，將當前使用者的角色和許可權統統返回給前端：

查詢角色思路：根據使用者 id，先去 sys_user_role 表中查詢到角色 id，再根據角色 id 去 sys_role 表中查詢到對應的角色（這裡為了方便大家理解這麼描述，實際上一個多表聯合查詢即可）。
查詢許可權思路：根據使用者 id，先去 sys_user_role 表中查詢到角色 id，再根據角色 id 去 sys_role 表中查詢到對應的角色，再拿著角色 id 去 sys_role_menu 表中查詢到對應的 menu_id，再根據 menu_id 去 sys_menu 表中查詢到對應的 menu 中的許可權（這裡為了方便大家理解這麼描述，實際上一個多表聯合查詢即可）。

前端有了使用者的許可權以及角色之後，就可以自行決定是否顯示某一個選單或者是否展示某一個按鈕了。

3. 後端許可權判斷

我先來說說這塊 TienChin 專案中是怎麼做的（即 RuoYi 腳手架的實現方案），再來和 vhr 進行一個對比。

在 TienChin 專案中是通過註解來控制許可權的，介面的存取許可權都是通過註解來標記的，例如下面這種：

@PreAuthorize("@ss.hasPermi('system:menu:add')")
@PostMapping
public AjaxResult add(@Validated @RequestBody SysMenu menu) {
    //省略
}
/**
 * 修改選單
 */
@PreAuthorize("@ss.hasPermi('system:menu:edit')")
@PutMapping
public AjaxResult edit(@Validated @RequestBody SysMenu menu) {
    //省略
}
/**
 * 刪除選單
 */
@PreAuthorize("@ss.hasPermi('system:menu:remove')")
@DeleteMapping("/{menuId}")
public AjaxResult remove(@PathVariable("menuId") Long menuId) {
    //省略
}

每一個介面需要什麼許可權，都是通過 @PreAuthorize 註解來實現的，關於這個註解的使用原理，鬆哥之前也有兩篇文章：

SpringSecurity怎樣使用註解控制許可權

Spring Security 中的許可權註解

看懂了這兩篇文章，上面這個註解就懂了，我這裡不贅述。

不過上面這種寫法說到底還是有一點“寫死”，因為存取哪個介面需要哪些許可權，在程式碼中固定了，如果介面和許可權直接的關係能夠儲存到資料庫中，那麼使用者就可以在自己需要的時候，隨時進行靈活修改，豈不美哉！

在 vhr 專案中，鬆哥利用 Spring Security 中自定義 FilterInvocationSecurityMetadataSource 和 AccessDecisionManager 實現了伺服器端動態控制許可權。這個具體的實現思路之前的文章中也和大家分享過了，傳送門：Spring Security 動態許可權實現方案！，這裡就不贅述了。

相對來說，vhr 中的實現方案更靈活一些，因為可以設定介面和許可權之間的關係。不過怎麼說呢？其實像 RuoYi-Vue 這樣寫死其實也不是不可以，畢竟介面和許可權之間的對映關係還是稍顯“專業”一些，普通使用者可能並不懂該如何設定，這個加入說系統提供了這個功能，那麼更多的還是面向程式設計師這一類專業人員的，那麼程式設計師到底是否需要這個功能呢？我覺得還是得具體情況具體分析。

總之，小夥伴們可以結合自己專案的實際情況，來決定介面和許可權之間的對映關係是否需要動態管理，如果需要動態管理，那麼可以按照 vhr 中的方案來，如果不需要動態管理，那麼就按照 RuoYi-Vue 腳手架中的方式來就行了。

那麼使用者的許可權該如何設定？今天我們就來聊聊這個話題。

4. 角色與許可權

首先我們先來看看角色與許可權，該如何設計角色與許可權，其實有很多非常成熟的理論，最為常見的莫過於 RBAC 了。

4.1 RBAC 簡介

RBAC（Role-based access control）是一種以角色為基礎的存取控制（Role-based access control，RBAC），它是一種較新且廣為使用的許可權控制機制，這種機制不是直接給使用者賦予許可權，而是將許可權賦予角色。

RBAC 許可權模型將使用者按角色進行歸類，通過使用者的角色來確定使用者對某項資源是否具備操作許可權。RBAC 簡化了使用者與許可權的管理，它將使用者與角色關聯、角色與許可權關聯、許可權與資源關聯，這種模式使得使用者的授權管理變得非常簡單和易於維護。

4.2 RBAC 的提出

許可權、角色這些東西，在早期 1970 年代的商業計算機程式中就可以找到相關的應用，但是早期的程式相對簡單，而且並不存在一個明確的、通用的、公認的許可權管理模型。

Ferraiolo 和 Kuhn 兩位大佬於 1992 年提出了一種基於通用角色的存取控制模型（看來這個模型比鬆哥年齡還大），首次提出了 RBAC 許可權模型用來代替傳統的 MAC 和 DAC 兩種許可權控制方案，並且就 RBAC 中的相關概念給出瞭解釋。

Ferraiolo，Cugini 和 Kuhn 於 1995 年擴充套件了 1992 年提出的許可權模型。該模型的主要功能是所有存取都是通過角色進行的，而角色本質上是許可權的集合，並且所有使用者只能通過角色獲得許可權。在組織內，角色相對穩定，而使用者和許可權都很多，並且可能會迅速變化。因此，通過角色控制許可權可以簡化存取控制的管理和檢查。

到了 1996 年，Sandhu，Coyne，Feinstein 和 Youman 正式提出了 RBAC 模型，該模型以模組化方式細化了 RBAC，並提出了基於該理論的 RBAC0-RBAC3 四種不同模型。

今天，大多數資訊科技供應商已將 RBAC 納入其產品線，除了常規的企業級應用，RBAC 也廣泛應用在醫療、國防等領域。

目前網上關於 RBAC 理論性的東西松哥只找到英文的，感興趣的小夥伴可以看下，地址是：

csrc.nist.gov/projects/Ro…

如果小夥伴們有中文的資料連結，歡迎留言說明。

4.3 RBAC 三原則

最小許可權：給角色設定的許可權是其完成任務所需要的最小許可權集合。
責任分離：通過相互獨立互斥的角色來共同完成任務。
資料抽象：通過許可權的抽象來體現，RBAC 支援的資料抽象程度與 RBAC 的實現細節有關。

4.4 RBAC 模型分類

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

4.4.1 RBAC0

RBAC0 是最簡單的使用者、角色、許可權模型。RBAC0 是 RBAC 許可權模型中最核心的一部分，後面其他模型都是在此基礎上建立。

在 RBAC0 中，一個使用者可以具備多個角色，一個角色可以具備多個許可權，終端使用者所具備的許可權是使用者所具備的角色的許可權並集。

4.4.2 RBAC1

RBAC1 則是在 RABC0 的基礎上引入了角色繼承，讓角色有了上下級關係。

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

4.4.3 RBAC2

RBAC2 也是在 RBAC0 的基礎上進行擴充套件，引入了靜態職責分離和動態職責分離。

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

在實際專案中，有一些角色是互斥的，對立的，例如財務這個角色一般是不能和其他角色兼任的，否則自己報賬自己審批，豈不是爽歪歪！

通過職責分離可以解決這個問題：

靜態職責分離

在設定階段就做好了限制。比如同一使用者不能授予互斥的角色，使用者只能有有限個角色，使用者獲得高階許可權之前要有低階許可權等等。

動態職責分離

在執行階段進行限制。比如執行時同一使用者下5個角色中只能同時有2個角色啟用等等。

4.4.4 RBAC3

將 RBAC1 和 RBAC2 結合起來，就形成了 RBAC3。

4.5 擴充套件

我們日常見到的很多許可權模型都是在 RBAC 的基礎上擴充套件出來的。

例如在有的系統中我們可以見到使用者組的概念，就是將使用者分組，使用者同時具備自身的角色以及分組的角色。

我們 TienChin 專案所用的腳手架中的許可權，就基本上是按照 RBAC 這套許可權模型來的。

5. 表設計

我們來看下 RuoYi-Vue 腳手架中跟使用者、角色以及許可權相關的表。

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

sys_user：這個是使用者表。

sys_role：這個是角色表。

sys_user_role：這個是使用者角色關聯表。

sys_menu：這個是選單表，也可以理解為是資源表。

sys_role_menu：這個是資源角色關聯表。

通過使用者的 id，可以去 sys_user_role 表中查詢到這個使用者具備的角色 id，再根據角色 id，去 sys_role_menu 表中查詢到這個角色可以操作的資源 id，再根據資源 id，去 sys_menu 表中查詢到對應的資源，基本上就是這個樣一個流程。

那麼 Java 程式碼中該怎麼做呢？

6. 程式碼實現

首先定義了一個 Java 類 SysUser，這個跟資料庫中的 sys_user 表是對應的，我們來看 UserDetailsService 的具體實現：

@Service
public 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("對不起，您的賬號：" + username + " 已被刪除");
        } else if (UserStatus.DISABLE.getCode().equals(user.getStatus())) {
            log.info("登入使用者：{} 已被停用.", username);
            throw new ServiceException("對不起，您的賬號：" + username + " 已停用");
        }
        return createLoginUser(user);
    }
    public UserDetails createLoginUser(SysUser user) {
        return new LoginUser(user.getUserId(), user.getDeptId(), user, permissionService.getMenuPermission(user));
    }
}

從資料庫中查詢到的就是 SysUser 物件，然後對該物件稍作改造，將之改造成為一個 LoginUser 物件，這個 LoginUser 則是 UserDetails 介面的實現類，裡邊儲存了當前登入使用者的關鍵資訊。

在建立 LoginUser 物件的時候，有一個 permissionService.getMenuPermission 方法用來查詢使用者的許可權，根據當前使用者的 id，查詢到使用者的角色，再根據使用者角色，查詢到使用者的許可權，另外，如果當前使用者的角色是 admin，那麼就設定使用者角色為 *:*:*，這是一段寫死。

我們再來看看 LoginUser 的設計：

public class LoginUser implements UserDetails {
    /**
     * 許可權列表
     */
    private Set<String> permissions;

    /**
     * 使用者資訊
     */
    private SysUser user;
    public LoginUser(Long userId, Long deptId, SysUser user, Set<String> 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();
    }
    /**
     * 賬戶是否未過期,過期無法驗證
     */
    @JSONField(serialize = false)
    @Override
    public boolean isAccountNonExpired() {
        return true;
    }
    /**
     * 指定使用者是否解鎖,鎖定的使用者無法進行身份驗證
     *
     * @return
     */
    @JSONField(serialize = false)
    @Override
    public boolean isAccountNonLocked() {
        return true;
    }
    /**
     * 指示是否已過期的使用者的憑據(密碼),過期的憑據防止認證
     *
     * @return
     */
    @JSONField(serialize = false)
    @Override
    public boolean isCredentialsNonExpired() {
        return true;
    }
    /**
     * 是否可用 ,禁用的使用者不能身份驗證
     *
     * @return
     */
    @JSONField(serialize = false)
    @Override
    public boolean isEnabled() {
        return true;
    }
    @Override
    public Collection<? extends GrantedAuthority> getAuthorities() {
        return null;
    }
}

有一些屬性我省略掉了，大家可以文末下載原始碼檢視。

小夥伴們看到，這個 LoginUser 實現了 UserDetails 介面，但是和 vhr 中有一個很大的不同，就是這裡沒有處理 getAuthorities 方法，也就是說當系統想要去獲取使用者許可權的時候，二話不說直接返回一個 null。這是咋回事呢？

因為在這個腳手架中，將來進行許可權校驗的時候，是按照下面這樣來的：

@PreAuthorize("@ss.hasPermi('system:menu:add')")
@PostMapping
public AjaxResult add(@Validated @RequestBody SysMenu menu) {
    //省略
}

@PreAuthorize 註解中的 @ss.hasPermi('system:menu:add') 表示式，表示呼叫 Spring 容器中一個名為 ss 的 Bean 的 hasPermi 方法，去判斷當前使用者是否具備一個名為 system:menu:add 的許可權。一個名為 ss 的 Bean 的 hasPermi 方法如下：

@Service("ss")
public class PermissionService {
    /**
     * 所有許可權標識
     */
    private static final String ALL_PERMISSION = "*:*:*";
    /**
     * 管理員角色許可權標識
     */
    private static final String SUPER_ADMIN = "admin";
    private static final String ROLE_DELIMETER = ",";
    private static final String PERMISSION_DELIMETER = ",";
    /**
     * 驗證使用者是否具備某許可權
     *
     * @param permission 許可權字串
     * @return 使用者是否具備某許可權
     */
    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);
    }
    /**
     * 判斷是否包含許可權
     *
     * @param permissions 許可權列表
     * @param permission  許可權字串
     * @return 使用者是否具備某許可權
     */
    private boolean hasPermissions(Set&lt;String&gt; permissions, String permission) {
        return permissions.contains(ALL_PERMISSION) || permissions.contains(StringUtils.trim(permission));
    }
}

由於這裡是純手工操作，在比較的時候，直接獲取到當前登入使用者物件 LoginUser，再手動呼叫他的 hasPermissions 方法去判斷許可權是否滿足，由於都是自定義操作，所以是否實現 UserDetails#getAuthorities 方法已經不重要了，不過按照這裡的比對方案，是不支援萬用字元的比對的。

例如使用者具備針對字典表的所有操作許可權，表示為 system:dict:*，但是當和 system:dict:list 進行比較的時候，發現比較結果為 false，這塊想要比對成功也是可以的，例如可以通過正規表示式或者其他方式來操作，反正都是字串比較，相信大家都能自己搞得定。

現在，前端提供操作頁面，也可以設定每一個使用者的角色，也可以設定每一個角色可以操作的許可權就行了，這個就比較簡單了，不多說。

更多Spring Security教學點選，希望大家以後多多支援it145.com！