本文由作者 Dennis_?發布于社區

近期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

• 支持選擇只讀、讀寫

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

↘好文推薦：

所有人問「貼吧之父」俞軍

產品經理邏輯學通識

干貨?|?產品經理要了解的技術類知識

👇歡迎關注：

點個“在看”吧

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的用户权限管理：最常用的架构模型介绍的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。