隨著使用者類型越來越豐富，導致權限系統(tǒng)必可不少。本文詳細的跟大家說說，為什么會有權限系統(tǒng)？或者換個說法，為什么需要權限系統(tǒng)？

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

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

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

看權限兩個字，可以通俗的理解為權力限制，即不同的人由于擁有不同權力，他所看到的、能使用的可能不一樣。對應到一個應用系統(tǒng)，其實就是一個用戶可能擁有不同的數(shù)據(jù)權限（看到的）和操作權限（使用的）?；蛘叽蠹铱梢园褭嘞蘅闯少Y源獲取權，B/S結構里，你通過瀏覽器有沒有向服務器請求某項資源的權力。

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

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

更多的鋪墊就不說了，全文將會以這個節(jié)奏進行：

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

二、權限系統(tǒng)的背景

為什么會有權限系統(tǒng)？或者換個說法，為什么需要權限系統(tǒng)？

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

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

舉個可能不恰當?shù)睦樱寒斂蛻糁幌胍猈MS的時候，你說OMS和WMS不可分割，想買WMS就必須買OMS，顯然是不合理的。

這和權限系統(tǒng)有什么關系呢？

OMS和WMS，一個是訂單管理系統(tǒng)，一個是倉庫管理系統(tǒng)。假設OMS的使用者是公司客服，WMS的使用者是公司倉庫管理員。這里出現(xiàn)了兩個系統(tǒng)，兩類使用者，客服應該看到并使用WMS么？

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

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

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

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

三、權限系統(tǒng)經(jīng)典模型

需要先說明一點，在權限系統(tǒng)文章里強調(diào)RBAC模型，只是為了讓大家對這個經(jīng)典模型重視起來，再強調(diào)一下RBAC模型的基本結構：用戶-?角色-?權限，卻不僅限于此，更多細節(jié)需要大家親自去摸索。

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

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

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

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

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

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

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

而RBAC 1模型就很好解決了這個問題，創(chuàng)建完經(jīng)理角色并配置好權限后，主管角色的權限繼承經(jīng)理角色的權限，并且支持針對性刪減主管權限。

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

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

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

如角色數(shù)量限制，例如：一個角色專門為公司CEO創(chuàng)建的，最后發(fā)現(xiàn)公司有10個人擁有CEO角色，一個公司有10個CEO？

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

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

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

四、操作和數(shù)據(jù)權限

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

用戶在使用操作系統(tǒng)時能進行的增刪改查我都歸為操作權限，有很多人將增刪改歸為數(shù)據(jù)權限，因為這是在更改數(shù)據(jù)庫某張表里的記錄，必然是數(shù)據(jù)權限，真的是這樣么？例如：商品中心里新增加一個商品，這到底是操作權限還是數(shù)據(jù)權限？

在我看來，凡是在操作系統(tǒng)中的任何動作、交互以及結果都是操作權限。那么，我說的數(shù)據(jù)權限是什么呢？

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

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

從上圖很容易能看出來我說的數(shù)據(jù)權限是什么了，如果以客戶作為最小數(shù)據(jù)單元往上看，你會發(fā)現(xiàn)：客戶2.1.1和客戶2.1.2只屬于專員2.1，只屬于主管2，再往上就是經(jīng)理。

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

我們在作業(yè)過程中，銷售數(shù)據(jù)是客戶這個最小單元產(chǎn)生的，沒有客戶就沒有銷售數(shù)據(jù)，那么我的客戶產(chǎn)生的銷售數(shù)據(jù)誰可見呢？

這就是我說的數(shù)據(jù)權限。

簡單說下，在實現(xiàn)數(shù)據(jù)權限時至少有兩種方式：

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

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

五、權限系統(tǒng)實操

到這一部分，我相信絕大部分產(chǎn)品同學已經(jīng)有自己對權限系統(tǒng)的認知了，特別是看到RBAC模型后，做一個簡單的權限系統(tǒng)應該沒任何問題。

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

那么，一個簡單的權限系統(tǒng)應該具備哪幾塊呢？

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

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

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

在RBAC模型下，給這樣一個場景，創(chuàng)建一個角色，并為這個角色賦予相應權限，最后將角色賦予用戶。那么，這個用戶就擁有了該角色所擁有的權限。

抽象一下這個問題：開始》創(chuàng)建角色》為角色賦予權限》添加用戶（調(diào)用HRMS）》將角色賦予用戶》結束。

底層邏輯已經(jīng)抽象出來了，那么該如何設計呢？

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

簡單來說權限系統(tǒng)設計至少有這三步，這樣就完成了之前場景預定的全部內(nèi)容，即：創(chuàng)建一個角色，并為這個角色賦予相應權限，最后將角色賦予用戶。

到這里權限系統(tǒng)也算是講完了，希望大家能喜歡，歡迎大家一起交流！

相關閱讀

入門電商，先從線下到線上說起

電商入門（2）：購物車功能要點和背后邏輯

電商入門 （3）：電商CMS，一勞永逸的建站方案

電商入門（4）：如果我來負責搜狗云表情的搜索功能，會怎樣去優(yōu)化？

作者：QJQ，微信公眾號：倔牛的人生

本文由 @QJQ 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉載

題圖來自 Pixabay，基于 CC0 協(xié)議