随着使用者類型越來越豐富，導緻權限系統必可不少。本文詳細的跟大家說說，為什麼會有權限系統？或者換個說法，為什麼需要權限系統？

權限系統其實不隻是應用于電商領域，各個領域都有可能用到。一旦公司系統做大，系統使用者的類型越來越豐富，權限系統就必不可少了。也就是說，小公司可能會沒有權限系統，一般用一個admin賬号供所有成員使用。

這裡需要注意，我說的使用者類型越來越豐富，導緻權限系統必可不少。很簡單，假設一個系統隻有一類使用者，這一類人必然有相同的使用權限，那就無所謂有沒有權限系統了。

如果抽象一下，你可以看到：使用者 – 某一類使用者– 權限，如果某一類使用者唯一，我可以直接抽象為：使用者– 權限。這算是提前劇透，權限系統的經典模型：RBAC模型，即用戶– 角色– 權限。上文就是将用戶這個維度向上抽象出角色，某一類使用者對應一種角色。

看權限兩個字，可以通俗的理解為權力限制，即不同的人由于擁有不同權力，他所看到的、能使用的可能不一樣。對應到一個應用系統，其實就是一個用戶可能擁有不同的數據權限（看到的）和操作權限（使用的）。或者大家可以把權限看成資源獲取權，B/S結構裡，你通過浏覽器有沒有向服務器請求某項資源的權力。

很多公司喜歡做用戶白名單這種事，其實道理和權限系統一緻，給白名單用戶開方便之門，讓他們訪問非白名單用戶訪問不到的資源。總結來說就是，我需要通過權限決定誰可以訪問我的資源。

另外，現在大部分文章沒有把數據權限和操作權限說明白，我會試圖在本文中講明白這個問題。

更多的鋪墊就不說了，全文将會以這個節奏進行：

1. 權限系統的背景，從這一部分你會知道為什麼需要誕生權限系統。
2. 權限系統經典模型，這一部分我會簡單介紹一下RBAC模型。
3. 操作和數據權限，在這一部分，我會把大部分文章沒有講清楚的數據權限和操作權限講明白。
4. 權限系統實操，在這一部分我會簡單說下做一個權限系統的底層邏輯，讓你很快能”複制”一個權限系統。

二、權限系統的背景

為什麼會有權限系統？或者換個說法，為什麼需要權限系統？

正如前文說的，某些小公司不需要權限系統，原因也提到了使用者類型唯一，那麼，是不是說當我使用者類型豐富的時候，我就需要考慮權限問題了呢？答案是肯定的！

權限系統起源是提供企業級應用軟件解決方案的公司，如SAP、PeopleSoft等，也是這類公司最早開始探索高内聚低耦合系統。

舉個可能不恰當的例子：當客戶隻想要WMS的時候，你說OMS和WMS不可分割，想買WMS就必須買OMS，顯然是不合理的。

這和權限系統有什麼關系呢？

OMS和WMS，一個是訂單管理系統，一個是倉庫管理系統。假設OMS的使用者是公司客服，WMS的使用者是公司倉庫管理員。這裡出現了兩個系統，兩類使用者，客服應該看到并使用WMS麼？

最早的一批提供企業級應用軟件服務的公司，也面臨着同樣的問題，随着客戶公司的業務拓展，首先是客戶公司對各子系統的需求量增大，可能不僅僅隻需要一個HRMS，其次是對系統的使用安全、保密性，系統操作人員的權責關系界定上越來越嚴格，最後是B/S結構出現後帶來的便捷性（需要注意的是這一點并不是初期探索權限系統的原因）。

關于這一點簡單畫了一個圖來說明，如下：

從圖中可以看出來，所有資源都統一存放在一處，當用戶需要請求資源的時候，先經過資源表判斷該用戶是否有對應權限，如果有則返回結果。

沒有B/S結構，一個軟件服務公司可能需要為客戶組裝各種本地化的系統（如sys1和sys2打一個包，sys1單獨打一個包，……），這就是B/S結構帶來的便捷性，而權限系統在這中間起了至關重要的作用。

三、權限系統經典模型

需要先說明一點，在權限系統文章裡強調RBAC模型，隻是為了讓大家對這個經典模型重視起來，再強調一下RBAC模型的基本結構：用戶- 角色- 權限，卻不僅限于此，更多細節需要大家親自去摸索。

RBAC模型可以分為：RBAC 0、RBAC 1、RBAC 2、RBAC 3 四個階段，一般公司使用RBAC0的模型就可以。另外，RBAC 0相當于底層邏輯，後三者都是在RBAC 0模型上的拔高。

我先簡單介紹下這四個RBAC模型：

RBAC 0模型：用戶和角色、角色和權限多對多關系。

簡單來說就是一個用戶擁有多個角色，一個角色可以被多個用戶擁有，這是用戶和角色的多對多關系；同樣的，角色和權限也是如此。

RBAC 0模型如下圖：沒有畫太多線，但是已經能夠看出多對多關系。

RBAC 1模型：相對于RBAC 0模型，增加了角色分級的邏輯，類似于樹形結構，下一節點繼承上一節點的所有權限，如role1根節點下有role1.1和role1.2兩個子節點。

角色分級的邏輯可以有效的規範角色創建（主要得益于權限繼承邏輯），我之前做過BD工具（類CRM），BD之間就有分級（經理、主管、專員），如果采用RBAC 0模型做權限系統，我可能需要為經理、主管、專員分别創建一個角色（角色之間權限無繼承性），極有可能出現一個問題，由于權限配置錯誤，主管擁有經理都沒有權限。

而RBAC 1模型就很好解決了這個問題，創建完經理角色并配置好權限後，主管角色的權限繼承經理角色的權限，并且支持針對性删減主管權限。

RBAC 1模型如下圖：多對多關系仍舊沒有改變，隻增加角色分級邏輯。

RBAC 2模型：基于RBAC 0模型，對角色增加了更多約束條件。

如角色互斥，比較經典的案例是财務系統中出納不得兼管稽核，那麼在賦予财務系統操作人員角色時，同一個操作員不能同時擁有出納和稽核兩個角色。

如角色數量限制，例如：一個角色專門為公司CEO創建的，最後發現公司有10個人擁有CEO角色，一個公司有10個CEO？

這就是對角色數量的限制，它指的是有多少用戶能擁有這個角色。

RBAC 2 模型主要是為了增加角色賦予的限制條件，這也符合權限系統的目标：權責明确，系統使用安全、保密。

RBAC 3模型：同樣是基于RBAC0模型，但是綜合了RBAC 1和RBAC 2的所有特點。這裡就不在多描述，讀者返回去看RBAC 1和RBAC 2模型的描述即可。

四、操作和數據權限

寫在之前，這一部分，我主要是講自己的理解，讀者們需要辯證的去看這一部分。

用戶在使用操作系統時能進行的增删改查我都歸為操作權限，有很多人将增删改歸為數據權限，因為這是在更改數據庫某張表裡的記錄，必然是數據權限，真的是這樣麼？例如：商品中心裡新增加一個商品，這到底是操作權限還是數據權限？

在我看來，凡是在操作系統中的任何動作、交互以及結果都是操作權限。那麼，我說的數據權限是什麼呢？

上文提到過我做的BD工具，再用這個例子：

先簡單介紹我們的業務模式：BD專員負責拓展客戶，BD主管直接管理推動專員作業，主管上級是經理，經理負責組織管理主管作業，這條業務線基本上如下圖：

從上圖很容易能看出來我說的數據權限是什麼了，如果以客戶作為最小數據單元往上看，你會發現：客戶2.1.1和客戶2.1.2隻屬于專員2.1，隻屬于主管2，再往上就是經理。

這個屬于關系換另外一句話就是：我的客戶隻有我和我的直屬上級以及直屬上級的領導能看到，這也就是我說的數據權限。為什麼這麼說呢？

我們在作業過程中，銷售數據是客戶這個最小單元産生的，沒有客戶就沒有銷售數據，那麼我的客戶産生的銷售數據誰可見呢？

這就是我說的數據權限。

簡單說下，在實現數據權限時至少有兩種方式：

• 一種上文提到了，利用RBAC 1模型，角色分級來實現，我們需要的就是角色分級帶來的角色樹，利用樹形結構去控制數據輸出。
• 另外一種方式，也就是我的實現方式，雷同于RBAC 1模型的角色樹，我利用HRMS中的人事組織架構來實現數據輸出，也即是打通HRMS系統和對應需要數據權限控制的系統，當涉及到數據輸出時，會調用HRMS系統中的組織結構樹，從而确定數據輸出範圍。當然我們在開發過程中，也可以直接把組織結構樹置于權限系統之中，這種方式适用于組織架構相對固化的組織（如國企），但一般不建議這樣做，系統的靈活配置、高可拓展性是開發想要的，也是産品需要考慮的。

這就是我理解的操作權限和數據權限，再次希望大家辯證的去看，自己多思考。

五、權限系統實操

到這一部分，我相信絕大部分産品同學已經有自己對權限系統的認知了，特别是看到RBAC模型後，做一個簡單的權限系統應該沒任何問題。

我說的實操的底層邏輯其實也是基于RBAC模型，再次強調下RBAC模型：用戶– 角色– 權限。

那麼，一個簡單的權限系統應該具備哪幾塊呢？

首先考慮一個問題，用戶從哪兒來？

很多權限系統直接在權限系統内創建一個用戶，也可以打通HRMS系統，員工即用戶，省去專門創建用戶的一步。我想說的是後者，即打通HRMS系統。多說一句，這種設計一般需要在員工入職的時候為其選擇相應角色。

用戶已經有了，在這個前提下，就可以考慮其他問題了。

在RBAC模型下，給這樣一個場景，創建一個角色，并為這個角色賦予相應權限，最後将角色賦予用戶。那麼，這個用戶就擁有了該角色所擁有的權限。

抽象一下這個問題：開始》創建角色》為角色賦予權限》添加用戶（調用HRMS）》将角色賦予用戶》結束。

底層邏輯已經抽象出來了，那麼該如何設計呢？

• 第一步，需要角色管理列表，在角色管理列表能快速創建一個角色；
• 第二步，角色管列表中能跳轉至為角色配置權限的頁面，也就是說有一個權限配置頁；
• 第三步，需要有用戶管理列表，在用戶管理列表能快速添加一個用戶，添加用戶的這一頁至少有讓用戶關聯角色的功能。

簡單來說權限系統設計至少有這三步，這樣就完成了之前場景預定的全部内容，即：創建一個角色，并為這個角色賦予相應權限，最後将角色賦予用戶。

到這裡權限系統也算是講完了，希望大家能喜歡，歡迎大家一起交流！

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部