"瞭解這幾點,權限管理其實很簡單"

本文作者從工作實踐出發,結合案例等分享了關於權限設計相關的知識,供大家一同參考和學習。

最近一段時間,我們的系統在做一個新功能,其中涉及到一些與權限相關的功能,之前也接觸過權限相關的設計,這篇文章就來對關於權限設計的進行一次總結。對於各種產品,不管是C端產品或者是B端產品,每個產品當中都有著權限控制,權限管理是系統中的基礎模塊,在搭建系統的時候,系統架構式就需要將權限搭建完成。好的權限管理,對於後續的系統擴展可以提供極大的兼容性。

一、常見的權限分類

1. 登錄權限

在我們日常使用APP的時候,有時候也會遇到一些權限控制,比如在阿裡零售通APP(下圖1)的首頁,在未登錄的情況下,用戶只能看到部分商品的價格,只有當我們登錄之後才能看到商品的價格。這種權限控制也比較簡單,需要前端開髮根據用戶當前的登錄狀態做判斷即可,但是這個是針對每個商品的價格,單獨配置了是否對未登錄用戶開放的權限。

2. 認證權限

而有的產品的權限校驗會更嚴格一點,例如京東掌柜寶APP(下圖)的首頁,即使登錄以後也是看不到商品價格的,必須在認證成為店鋪的掌柜才能看到商品價格。而且這個產品裡面,是所有的價格都看不到,這種是做了一種全局的配置,無論是哪件商品,只要用戶未認證,都是看不到商品價格的。

3. 會員權限

另外還有一些權限,是我必須成為會員才能進行操作的。例如下圖中的QQ音樂會員,當我們是非會員的時候,只能試聽其中的片段,頁面也會直接提示我們需要開通權限才能播放完整的歌曲。同樣還有一些其他的工具類APP也會使用相同的套路,可以先讓用戶免費試用一段時間,如果想要繼續使用的話,就需要付費。有的是基礎功能免費,使用全部功能的話,需要付費。這些都是一樣的邏輯,前端都需要校驗當前登錄的用戶是否有會員權限。

4. 菜單權限

我們上面說的這些都是一些我們在自己手機APP,即用戶端的一些權限校驗邏輯,而在我們的管理後管也會經常有其他一些權限,其中最常見的就是菜單權限。顧名思義,在後臺管理的頁面,我們經常會有一些菜單,每個菜單上面都有對應的權限,只有滿足權限的人才能進行訪問。例如下圖當中,左邊菜單會有不同的菜單,但是不同的人員會賦予不同的權限,所以對於不同的人來說,能夠看到的菜單也不一樣。

另外在一些移動端的APP上面 ,也會有不同的身份,例如boss直聘上面,可以切換身份,作為求職者和招聘者,不同的身份看到的頁面也是不一樣的。

5. 操作權限

操作權限是指用戶進行某個操作的權限。比如在我們的商品管理裡面,商品上架、下架功能的操作需要有專門的人去操作,而查看商品詳情的權限則可以放開給更多的人,所以查看商品詳情和操作商品上下架的權限就會區分開。

6. 數據權限

數據權限,會控制用戶訪問頁面的時候,能有查看到的數據。這種一般會在公司團隊較大的時候會需要有這樣的需求區分,如果公司團隊人數很少,一般不會有這種需求。當公司人員多的時候,一般會有很多業務部門,每個業務部門會負責不同的業務,根據管理需要,這些業務部門之間的數據有時候會進行需求。

例如我們最近在做的庫存分倉庫管理,在庫存管理的頁面,每個倉庫的庫管員只能看到自己管理的倉庫的庫存數據,而無法看到其他倉庫的庫存數據。這是對於業務部門,但是一個公司裡面還會有一些管理部門,這些部門的人員是能夠看到所有業務部門的數據的,所以又會需要有一個權限需要能夠看到所有部門的業務數據。除了這種的數據權限以外,還有字段的數據權限。

比如在訂單列表,有些人沒有權限查看訂單的收件人信息的字段,包括收件人姓名、電話、地址信息,有些人沒有權限查看訂單的商品價格信息。這種數據權限的劃分,需要根據公司的管理要求具體來看待,當如果公司需要管理到這麼細的顆粒度的時候,再去做,一般的中小企業,正常情況下很少會有這種需求。

二、如何實現權限管理

上面大概介紹了在APP和管理後臺常見的一些權限,這些權限基本上能夠滿足我們對於用戶權限的控制。但是如何實現這種權限設計,這篇文章主要介紹上面第4、5、6種後臺權限是如何設計的。在我們一般的後臺權限設計當中,一般會用到這幾個概念:用戶、賬號、角色、權限

在我們的系統當中,用戶都會分配一個賬號,這個賬號不會與權限直接相關聯,而是中間有一個角色在牽線搭橋。賬號、角色和權限都是系統中最底層的概念,也是其他業務邏輯和功能邏輯的基礎,在系統的權限管理裡面這三者必不可少,下麵我們來說說這三者是如何實現權限管理的邏輯的:

1. 權限

根據業務需要,我們會向開發人員提出我們的需求,哪些地方需要做權限控制,技術人員會根據我們的需求創建一系列的權限標識,並對某些頁面、按鈕、數據等等加上對應的權限校驗,這樣管理人員就有權限可用了。

2. 角色

系統的管理人員,一般是超級管理員,他們會根據實際的需要,在系統中創建一個角色,這個角色只是一個概念,然後在這個角色上面加上上面開發人員創建的權限標識。這樣,這個角色就擁有了這個權限。而往往權限和角色之間是多對多的關係:

3. 賬號

最後,我們再將創建好的角色,賦予對應的賬號,這樣這個賬號就擁有了這個角色所擁有的權限了,如下圖所示。最終用戶在登錄他的賬號的時候,就擁有了這個賬號下麵的權限了

這樣做的方式是可以靈活配置賬號的權限,噹噹我們新增一個權限,只要我們將這個權限賦予需要這個權限的角色,那麼賦予了這個角色的所有賬號都可以擁有這個權限了,無需針對每個賬號單獨開通權限。

擴展當一個組織逐漸擴大以後,權限、角色、用戶不斷增多,很多時候,利用上面這個邏輯依然能夠滿足我們的需求,但是對於我們的配置仍然有點麻煩,所以又可以引入組織架構和權限組的概念。

當組織當中不斷加入新員工的時候,我們將他的新的賬號放到組織架構之下,又將角色按照一定的規則組合後,再關聯到組織架構,當用戶的賬號在這個組織機構之下,有擁有了這個角色組的裡面的所有權限,這樣,對於新員工,只需要將他放入對應的組織架構即可,而不需要再給他一一配置角色。

以上就是關於權限管理的總結,感謝您的閱讀~

作者:三點半先生;微信公眾號:曉言產品(ID:Xiao_PM)一名產品小學生,在這裡記錄每天工作的工作和學習中關於產品的一些想法。

本文由 @三點半先生 原創發佈於人人都是產品經理,未經作者許可,禁止轉載。

題圖來自Unsplash,基於CC0協議。

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *