99精品人妻无码专区在线视频,亚洲精品成人片在线观看

搜索

APP

起點課堂會員權益

職業體系課特權

線下行業大會特權

個人IP打造特權

30+門專項技能課

1300+專題課程

12場職場軟技能直播

12場求職輔導直播

12場專業技能直播

會員專屬社群

榮耀標識

發布

注冊 | 登錄

電商入門（5）：權限系統

QJQ

2018-07-23

3 評論 13595 瀏覽 133 收藏

16 分鐘

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

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

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

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

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

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

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

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

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

二、權限系統的背景

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

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

權限系統起源是提供企業級應用軟件解決方案的公司，如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系統中的組織結構樹，從而確定數據輸出范圍。當然我們在開發過程中，也可以直接把組織結構樹置于權限系統之中，這種方式適用于組織架構相對固化的組織（如國企），但一般不建議這樣做，系統的靈活配置、高可拓展性是開發想要的，也是產品需要考慮的。

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