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

作者|小菜

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

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

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

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

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

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

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

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

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

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

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

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

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

別急別急，馬上迭代。

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

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

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

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

okokok，anyway，我講乙個真實的案例。

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

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

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

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

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

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

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