作者|小菜

Hello，大家好，今天給大家講講使用者許可權。可能有人會覺得使用者許可權有什麼好講的，市面上通用的RBAC許可權模型多了去了，還需要你個小菜鳥來講。說這話的，可能沒看到我背上紋的小豬佩奇，信不信我這個社會人給你來點狠的——求著你看完。咳咳…嚴肅嚴肅，**相信我，看完你會有收穫的，沒有收穫的來砍我，千萬不要砍需求。**

### 一、什麼是許可權

不管是B端產品還是C端產品，許可權基本都會出現。常見的比如說知乎、簡書等內容類產品，你只有登入才能評論、點贊，不登入你只能瀏覽；再比如知識付費或影片類產品中，你只有付費了才能完整檢視專欄裡的內容，不付費你只能試看幾分鐘；再複雜一點的，**就是企業級產品中，各部門，各崗位，不同使用者能操作的許可權都不盡相同。**

百度百科中對許可權的解釋是：“為了保證職責的有效履行，任職者必須具備的，對某事項進行決策的範圍和程度”。有點拗口，用我的話來理解就是“能不能幹”。想汙了的同學請遵守交通規則，繫好安全帶，謹防疲勞駕駛。

許可權按型別劃分為三類：頁面許可權、操作許可權和資料許可權。頁面許可權很好理解就是能不能進這個頁面；操作許可權就是對於這個頁面中的增刪改查按鈕以及其他按鈕能不能操作；至於資料許可權，就是不同使用者進來看到的資料不一樣，比如說研發部門只能看到研發部的資料，產品部只能看到產品部的資料。

使用者許可權實際上是控制使用者可用的功能點。換句話說，許可權的最小單元是功能點。如果把一個產品或者系統比作一幢房子，那功能點就是房子裡的一個個上了鎖的房間，使用者只有拿到相應的鑰匙才可以使用產品。

瞭解以上資訊後，我們開始以產品化的思維去設計這個產品，根據MVP原理先推出個使用者許可權1.0版本。

### 二、使用者許可權V1.0

**最簡單的使用者許可權，就是把使用者和功能點直接關聯起來。**

![](https://user-gold-cdn.xitu.io/2019/8/6/16c64c4959265c40?w=786&h=454&f=jpeg&s=19694)

透過這種方式我們可以很靈活的控制使用者許可權。使用者想要什麼許可權，我們就把對應的功能點分配給使用者，使用者拿著對應的鑰匙就可以開啟一個個房間。

這種許可權模型在實際應用場景中，往往適合功能點較少的產品，比如說只有登入限制、付費限制等。如果一個產品的功能點過多，那麼這種模型就會給使用者帶來非常繁瑣的操作。

想象這樣一個場景，假設你的一幢5層樓酒店有50間上了鎖的房間，每一層都是不同的保潔員負責房間衛生。你每次都要從一堆鑰匙中找到對應樓層房間的鑰匙，交給對應樓層的保潔員，光是找找就非常麻煩了。如果房間再多一些，你的操作就會被幾何倍數放大，到時候你就會崩潰了。

難道就沒有更聰明的方法了嗎？

自然是有的，基於這個需求我們對原有的許可權模型進行迭代。

### 三、使用者許可權V2.0

作為酒店負責人，我可以把一樓所有房間鑰匙串在一起，交給一樓的保潔員；二樓的串在一起，交給二樓的保潔員；後面的依次類推，這樣我就不需要每次那麼費勁地從一堆鑰匙裡去找了。

![](https://user-gold-cdn.xitu.io/2019/8/6/16c64c653bfdfe09?w=1080&h=428&f=jpeg&s=23566)

我們把一些功能點的集合叫做角色，再把相應的角色分配給使用者，從而讓使用者擁有相應的功能許可權。這種模型就是市面上常見的RBAC許可權模型。

這種許可權模型在實際應用場景中，適合功能點較多但使用者規模不大的產品。功能點較少，用V1.0版本的更方便更靈活，那為什麼說適合使用者規模不大呢？

再來想象一個場景，還是那個酒店，現在每層保潔員投訴你壓榨他們勞動力，工作七天，全年無休，太累了。為了平息眾怒，你決定每層都由10個保潔員來負責房間衛生，這樣一來你就要分配50次鑰匙串。如果每層20個呢，50個呢，100個呢，你馬上又會吐槽了，TMD破產品，把這個產品經理給我拖出去祭天。

別急別急，馬上迭代。

### 四、使用者許可權V3.0

為了減少你的工作量，你決定把1樓的所有鑰匙串都放在1樓保潔員工作室，2樓的放在2樓保潔員工作室…依次類推（當然每個樓層的保潔員只能進本樓層的工作室）。這樣只要是某個樓層工作室的保潔員，都可以快速拿到負責區域的鑰匙串，而不再需要你耗費精力去分配了。

![](https://user-gold-cdn.xitu.io/2019/8/6/16c64c6afd3debb8?w=1080&h=426&f=jpeg&s=21927)

我們把擁有相同許可權的使用者進行組合，叫做使用者組，之後只要對使用者組分配角色就好了，這樣一來，只要是這個使用者組下的使用者就具備了相同的許可權，減少使用者繁瑣的配置過程。

這種許可權模型適合功能點比較多、使用者規模比較大，而且產品單一的情況。為什麼要強調產品比較單一呢？

好我們再來想象一下…為什麼我要想，再想寶寶就要有脾氣了，我刀呢。

OKOKOK，Anyway，我講一個真實的案例。

去年我接手過一個湖北某市的專案，整個專案包含20多個教育類應用，給整個城市下的1000多所學校上百萬學生、教師、家長使用。實施同學在配許可權的時候直接崩潰了，每所學校20多個應用都要配對應的角色，而每次配的角色還是一模一樣。你可以算一算，大概要操作多少次，反正我的手指頭是不夠用的。

同學同學，不要激動不要激動，馬上迭代，現在可以把刀拿走了嗎！

### 五、使用者許可權V4.0

**我們把不同產品下的角色進行組合，叫做角色組，透過把角色組賦予使用者組，達到快速配置許可權的目的。**

![](https://user-gold-cdn.xitu.io/2019/8/6/16c64c709cba319c?w=1080&h=402&f=jpeg&s=29383)

這種許可權模型適合使用者規模較大，產品線眾多，功能點較多的情況。放心放心，我就不再繼續假設，再假設下去估計刀就砍下來了。

### 六、總結

分析了那麼多，其實大家可以發現，**永遠不存在通用的許可權模型，只有最合適的，做產品也一樣，不基於使用者需求出發，隨意套用公式模板，帶來的危害是難以想象的。**

細心的同學應該會發現，哪怕多麼複雜的場景，使用者許可權V1.0版本都可以解決，無非使用者需要多操作罷了。但是**我們做產品的，永遠是把複雜的留給自己，簡單的留給使用者，所以請相信數瀾，這一直都是我們的最低產出標準。**

最後，再想象一個場景，實際應用中，同一個部門（使用者組）不同人員許可權是不一樣的，比如說產品總監和普通產品經理的許可權就會不一樣，怎麼解決？

2分鐘快速瞭解企業使用者許可權

相關文章