近期 PMCAFF 有好幾個帖子都在問權限如何管理，給大家分享下吧。

1. 角色權限管理

說起用戶權限管理，繞不開 RBAC 模型，

直接上圖：

RBAC（Role-Based Access Control，基於角色的訪問控制），就是用戶通過角色與權限（系統資源）進行關聯

簡單地說，一個用戶擁有若干角色，每一個角色擁有若干權限。這樣，就構造成 “用戶 - 角色 - 權限（系統資源）” 的授權模型。在這種模型中，用戶與角色之間，角色與權限（系統資源）之間，一般是多對多的關係

我們可管理的權限（系統資源）分爲功能權限、數據權限：

功能權限，管理 API 和頁面元素的可控與否、可見與否

數據權限，管理數據表 Key-Value 的可控與否、可見與否

上述模型主要體現的是對系統資源的權限管理，接下來說說對人的複雜權限管理：

對人的權限管理需求往往是權限繼承、權限隔離等，涉及：

• 公司體系結構（Company Architecture），例如集團公司的管理，涉及總部和子公司、股權往來公司、業務往來公司等

• 組織架構（Organization），例如部門和子部門、部門領導和員工等

• 域（Domain），例如中國域和歐洲域

• 多業態（Multiple formats），按照不同業態對角色進行分類，例如系統類角色、營銷渠道類角色等

如何實現呢？（實現方式很多，這裏僅簡單舉例）

• 在 RBAC 模型中引入用戶組的概念，爲用戶賦予用戶組，爲用戶組賦予角色，可考慮將用戶組按需關聯至公司體系結構層、組織架構層、域層

• 在 RBAC 模型中引入角色類型的概念，可考慮將其按需關聯至多業態層

• 引入角色上下級繼承等

RBAC 模型是目前最常用的用戶權限模型，但也有弊端，對權限管理粒度太細了，不一定所有業務場景都需要如此複雜的權限模型，酌情選用，也可以酌情調整模型

2. 功能權限的管理

前文說到，功能權限的管理，本質上是在管理系統資源，是在管理一個系統某個頁面中的 API 和頁面元素，比方說一個按鈕

我們有兩種做法，

• 一種是寫死，即頁面下有哪些 API 和元素，前端工程師直接寫死

• 一種是配置，即允許用戶自行可視化的配置這些元素

如需配置，即可引入菜單管理

菜單用來幹嘛？

• 於系統來說，菜單是我們用來管理系統資源（按鈕、頁面圖片、API 等）的載體，通過對菜單和依附菜單的系統資源做權限管控，可以實現細粒度的用戶權限管理。因此，菜單管理本身屬於 RBAC 權限管理的一部分

• 於用戶來說，菜單最基礎的作用是導航，通過菜單，用戶可以快速瞭解系統的功能模塊劃分、層級結構，也可以快速切換

菜單管理如何實現？

直接上圖：

菜單的管理：

• 菜單名稱

• 菜單編碼，即菜單的唯一標識

• 菜單圖標

• 所屬應用，即該菜單屬於哪個系統

• 父級菜單，即配置多級菜單

• 菜單狀態，即停啓用

• 跳轉方式，即站內跳轉和站外跳轉，影響跳轉路徑的配置

• 跳轉路徑，即菜單的 URL

• 打開方式，即跳轉後的頁面打開方式，在當前頁打開，還是新頁面

菜單內資源的管理：

• 資源名稱，即該資源的名稱，例如「新增用戶」

• 資源路徑，即該資源的調用路徑，例如「新增用戶」的路徑是 Add User API 的地址

• 資源類型，即 API，或頁面元素

• 頁面元素，例如一個前端綠色小按鈕靜態圖片

• 資源關聯，例如配置了一個 Add User API，又配置了一個綠色的新增用戶按鈕圖片，將其關聯起來

這樣，我們就可以實現系統資源的可視化配置

3. 數據權限的管理

我們對於數據權限的管理需求，無非是某些數據某個人能看，而另一個不能看之類的。前文正好也講到，實質上是在做數據表的 Key-Value 讀寫權限管理

這裏就不上圖了，

實現思路也不復雜，可考慮在角色引入

• 支持選擇數據表

• 支持選擇數據表下的 Key

• 支持選擇數據表下的 Key 的 Value

• 支持選擇只讀、讀寫

• 前端頁面的邏輯，不要忘記反選哦，很多時候我們的需求就是除了某某之外，其他都能看

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/wnCEXCZd_0gWkyH14AFUBQ