文章結(jié)合具體業(yè)務(wù)場景對(duì)電商后臺(tái)設(shè)計(jì)中的系統(tǒng)權(quán)限設(shè)計(jì)的業(yè)務(wù)邏輯展開了梳理說明，并對(duì)相關(guān)問題展開了分析，希望通過此文能夠加深你對(duì)電商后臺(tái)設(shè)計(jì)的認(rèn)識(shí)。

在說權(quán)限設(shè)計(jì)前我們先來看個(gè)現(xiàn)實(shí)中的實(shí)例，大家在電影里面應(yīng)該都見過這樣的場景，當(dāng)一個(gè)客戶想進(jìn)入銀行倉庫查看自己的私人保險(xiǎn)柜信息時(shí)，通常都需要經(jīng)過幾個(gè)步驟：

1. ?首先進(jìn)入銀行并說明自己是銀行的客戶以及來意
2. 由業(yè)務(wù)經(jīng)理帶領(lǐng)進(jìn)入對(duì)應(yīng)的保險(xiǎn)箱倉庫(倉庫應(yīng)該不止一個(gè),猜得啊，我也沒有進(jìn)去過^_^)
3. 業(yè)務(wù)經(jīng)理帶著客戶在眾多保險(xiǎn)箱中找到屬于客戶的私人保險(xiǎn)箱
4. 客戶輸入密碼自己打開保險(xiǎn)箱查看內(nèi)部物品

在上面的實(shí)例中，客戶在看到保險(xiǎn)箱的物品之前，他需要有這么幾個(gè)必要條件：

1. 在銀行有開戶信息，能證明自己是銀行客戶
2. 有進(jìn)入保險(xiǎn)箱倉庫的權(quán)利
3. 在眾多的保險(xiǎn)箱中找到屬于自己的那一個(gè)
4. 有打開保險(xiǎn)箱的鑰匙

了解了上面的過程，對(duì)于我們理解一個(gè)系統(tǒng)的權(quán)限就會(huì)容易很多，我們再來梳理一下用戶在系統(tǒng)中看到數(shù)據(jù)的過程：

1. 用戶需要進(jìn)入系統(tǒng)，這需要后臺(tái)管理員給用戶分配賬號(hào)(后臺(tái)系統(tǒng)是沒有注冊功能的)
2. 用戶進(jìn)入系統(tǒng)能看到哪些菜單導(dǎo)航，需要后臺(tái)給配置
3. 通過菜單進(jìn)入到具體的頁面，在頁面內(nèi)能訪問多少數(shù)據(jù)量也是有訪問限制的
4. 看到數(shù)據(jù)了，能對(duì)數(shù)據(jù)做多少操作也是有操作限制的

在上面的過程中，除了第一步的分配賬號(hào)是由管理員操作的，剩下的三步都和用戶所擁有的權(quán)限相關(guān)。通過具體操作對(duì)象的不同，上面三步可以分為兩類：

• 功能：對(duì)功能的限制也稱功能權(quán)限，主要是對(duì)訪問區(qū)域以及對(duì)應(yīng)操作的管理，如上面的倉庫、頁面以及頁面操作按鈕。
• 數(shù)據(jù)：對(duì)數(shù)據(jù)的限制也稱數(shù)據(jù)權(quán)限，主要是對(duì)數(shù)據(jù)資源的訪問控制，如保險(xiǎn)箱和頁面顯示數(shù)據(jù)。

知道了需要對(duì)哪些對(duì)象進(jìn)行管控限制，那么設(shè)計(jì)功能也就有了針對(duì)性，接下來我們一一分析。

01 功能權(quán)限

功能權(quán)限指的是用戶具體能訪問哪些菜單，以及對(duì)菜單頁面中的哪些按鈕有操作權(quán)限。把多個(gè)菜單和對(duì)應(yīng)的功能按鈕組織到一起就行程了一個(gè)權(quán)限列表，具體的組織方式如下圖：

對(duì)于用戶來說，它又是如何獲得這些權(quán)限列表的呢？通常有以下幾種方案：

方案一：ACL(Access control list), 權(quán)限訪問列表

通過直接將用戶和權(quán)限列表綁定在一起，實(shí)現(xiàn)的權(quán)限管理

• 優(yōu)點(diǎn)：可以為每個(gè)用戶個(gè)性化的設(shè)置訪問權(quán)限。
• 缺點(diǎn)：當(dāng)用戶數(shù)量多，并且擁有相同職能的用戶較多時(shí)，修改一次權(quán)限，就需要耗費(fèi)很大力氣。如銷售部有很多的銷售專員，因?yàn)樗麄兊穆毼幌嗤?，所有獲得的操作權(quán)限相同，但后期添加或者刪除一個(gè)訪問權(quán)限，那么需要給所有人相同職位的人都操作一遍，管理員估計(jì)得累死。所以這種設(shè)計(jì)方案在開發(fā)中使用的頻率很低。

方案二：RBAC(Role-Based Access Control)，基于角色的訪問控制

通過先創(chuàng)建一個(gè)角色，然后將權(quán)限列表在綁定在這個(gè)角色上，之后再將角色和綁定到用戶身上，用戶就可以獲得這個(gè)角色的所有權(quán)限。

• 優(yōu)點(diǎn)：首先多人可以公用一個(gè)角色；再者如果需要對(duì)權(quán)限進(jìn)行調(diào)整，只需要調(diào)整對(duì)應(yīng)角色的權(quán)限即可，也就是只需要一次操作，非常易于操作和管理。
• 缺點(diǎn)：上面優(yōu)點(diǎn)也是一個(gè)缺點(diǎn)，因?yàn)闄?quán)限的操作是按角色來完成的，所以每次修改含有相同角色的用戶都會(huì)被影響。

如對(duì)于同一職位的職員，正常來說大家的權(quán)限都是一樣的，但是也會(huì)有特殊情況發(fā)生，比如給其中一個(gè)添加或減少部分權(quán)限，這個(gè)時(shí)候就沒有辦法了。對(duì)于這種情況，在現(xiàn)有的設(shè)計(jì)功能上也是有辦法解決的。

通常的方案就是在給角色綁定權(quán)限時(shí)，先采用權(quán)限最小化原則，能少給就少給，然后再做一個(gè)角色綁定多余的權(quán)限，再把這個(gè)角色也綁定給職員，這個(gè)時(shí)候兩個(gè)角色的權(quán)限就合并到一起了，也就是用戶和角色之間是一對(duì)多的關(guān)系。

對(duì)于RBAC還有幾個(gè)擴(kuò)展模型：

• 第一種：在角色上加入了上下級(jí)關(guān)系，上級(jí)可以繼承下級(jí)的權(quán)限
• 第二種：在角色之間加入了多個(gè)約束關(guān)系，如角色互斥、用戶基數(shù)限制等

實(shí)際開發(fā)中這些擴(kuò)展模型，我們基本都不用，開發(fā)成本太多，實(shí)際意義和并不是很大，基本的模型已經(jīng)足夠完成我們的系統(tǒng)需要。如果想了解的同學(xué)，網(wǎng)上搜索一下RBAC，有很多教程我這里就不說了。

下面是基于RBAC的原型設(shè)計(jì)圖：

▲角色列表頁

▲角色授權(quán)頁

02 數(shù)據(jù)權(quán)限

對(duì)于數(shù)據(jù)權(quán)限的管理比較復(fù)雜，這個(gè)主要還是有具體的業(yè)務(wù)來決定的，下面我們就看幾種常見的數(shù)據(jù)場景以及解決方案。

場景一：分上下級(jí)的數(shù)據(jù)訪問

企業(yè)中通常都有銷售部，銷售部下又分各個(gè)大區(qū)，大區(qū)下又劃分小組。對(duì)于銷售人員來說，他們的薪資是和業(yè)績掛鉤的，所以沒有人會(huì)把自己的客戶資源讓你別人的，這就導(dǎo)致數(shù)據(jù)處理上，銷售專員通常只能看自己的(自愿共享的就不再這里討論)，而對(duì)于銷售主管則能看到手下所有的銷售專員的客戶資料，同理，大區(qū)經(jīng)理，和銷售總監(jiān)也都能看到自己手下所有人的客戶資源。

在這種場景下的數(shù)據(jù)，很明顯是能看出，這是根據(jù)企業(yè)的組織架構(gòu)，根據(jù)職員的職位高低來控制數(shù)據(jù)的訪問權(quán)限。所以它通常的解決方案是和組織架構(gòu)相關(guān)聯(lián)的，具體邏輯如下：

1. 在給職員分配賬號(hào)的時(shí)候，設(shè)置好對(duì)應(yīng)的部門和職位
2. 當(dāng)用戶獲取數(shù)據(jù)時(shí)，根據(jù)自己當(dāng)前的部門和職位，獲取到所有下屬的職員信息
3. 將屬于這些下屬職員的所有客戶信息顯示出來，這個(gè)數(shù)據(jù)控制就完成了

場景二：分區(qū)塊的數(shù)據(jù)訪問

分區(qū)塊的典型案列就是電商企業(yè)員工對(duì)多個(gè)倉庫的訪問問題，我們假設(shè)有一個(gè)大的電商平臺(tái)，它在全國有多個(gè)倉庫，如北京倉、上海倉、西安倉、甘肅倉。對(duì)于各個(gè)倉庫的職員來說，通常他們只有當(dāng)前倉庫的數(shù)據(jù)訪問權(quán)限，而對(duì)于總公司的買手、技術(shù)等人員來說，他們平時(shí)要巡檢查看各個(gè)倉庫數(shù)據(jù)，所以需要有全部倉庫的數(shù)據(jù)。而倉庫的組織架構(gòu)和買手、技術(shù)所屬部門并不存在上下級(jí)關(guān)系。

在這種場景下的數(shù)據(jù)，它就是按照分區(qū)塊的方式來劃分。要解決這個(gè)問題其實(shí)也很簡單，就是上面講的【用戶-角色-權(quán)限列表】，只是這里的權(quán)限列表內(nèi)容不再是菜單和操作按鈕，而是各個(gè)倉庫。

場景三：數(shù)據(jù)共享

數(shù)據(jù)共享的場景是很常見的，像我們經(jīng)常使用的協(xié)同文檔軟件，里面都會(huì)有將內(nèi)容共享給個(gè)人或者共享給某個(gè)組的功能。

這種場景下的的數(shù)據(jù)，我們需要通過單獨(dú)建表，維護(hù)共享者和被共享對(duì)象的關(guān)系，獲取數(shù)據(jù)時(shí)從對(duì)應(yīng)關(guān)系表中讀取對(duì)應(yīng)共享數(shù)據(jù)即可。

場景四：分狀態(tài)的數(shù)據(jù)訪問

分狀態(tài)的數(shù)據(jù)控制，這種場景比較少見，一般出現(xiàn)在流程比較長的業(yè)務(wù)中。如金融借貸系統(tǒng)中，比如一個(gè)用戶想要去借貸平臺(tái)上貸款，假設(shè)他們的流程如下圖：

通常要完成整個(gè)業(yè)務(wù)流程，需要多個(gè)部門相互配合的，由于整個(gè)業(yè)務(wù)涉及了許多客戶隱私信息，所以各個(gè)部門的職員一般只允許看到對(duì)應(yīng)步驟的數(shù)據(jù)，如審查組通常只能看到狀態(tài)為【待審核】的信息，風(fēng)控組只能看到【待評(píng)估】的信息，財(cái)務(wù)組只能看到【待放貸】的信息。

基于這種場景，有兩種解決方案：

1. 首先在代碼里面配置好部門和職位對(duì)應(yīng)的訪問狀態(tài)碼(也就是寫死在代碼里)，當(dāng)用戶訪問數(shù)據(jù)時(shí)，根據(jù)部門和職位獲得對(duì)應(yīng)狀態(tài)碼，再進(jìn)行數(shù)據(jù)過濾。優(yōu)點(diǎn)就是開發(fā)比較快寫幾行邏輯判斷就行了，缺點(diǎn)就是如果想給部分人(如公司領(lǐng)導(dǎo))設(shè)置個(gè)性化的訪問狀態(tài)碼，就很難做到了。
2. 還是參考【用戶-角色-權(quán)限列表】的方式，將權(quán)限列表里的數(shù)據(jù)更換成業(yè)務(wù)狀態(tài)碼，訪問數(shù)據(jù)時(shí)，先根據(jù)用戶設(shè)置的角色獲取分配的狀態(tài)碼，再根據(jù)狀態(tài)碼獲取數(shù)據(jù)。優(yōu)點(diǎn)是代碼開發(fā)完后，任意的個(gè)性化都可以手動(dòng)維護(hù)并快速配置。缺點(diǎn)就是開發(fā)量稍微大一點(diǎn)。

上面兩種方式其實(shí)內(nèi)部邏輯是一樣的，都是先根據(jù)用戶的部門和職位先獲取狀態(tài)碼再獲取數(shù)據(jù)，但是可操作性和擴(kuò)展性缺完全不一樣。

以上就是權(quán)限功能涉及的內(nèi)容，如果你的業(yè)務(wù)還有更多花樣，請(qǐng)?jiān)谙路搅粞?。最后再給出一張用戶綁定權(quán)限原型圖，大家根據(jù)自己的業(yè)務(wù)適當(dāng)調(diào)整：

小結(jié)

1. 系統(tǒng)權(quán)限模塊的設(shè)計(jì)時(shí)需要考慮兩點(diǎn)：功能權(quán)限和數(shù)據(jù)權(quán)限。功能權(quán)限和菜單以及菜單頁面內(nèi)的按鈕相關(guān)，而數(shù)據(jù)權(quán)限和業(yè)務(wù)相關(guān)。
2. 在處理一些有規(guī)則調(diào)整的功能時(shí)，最好設(shè)計(jì)可以手動(dòng)維護(hù)的，這樣對(duì)于后期的維護(hù)和擴(kuò)展會(huì)非常方便，否則運(yùn)營經(jīng)常會(huì)找研發(fā)修改配置，這樣的工作即沒有技術(shù)含量，時(shí)間長了還挺讓人煩的，這點(diǎn)我在工作中深有體會(huì)。

作者：JackLiu；個(gè)人微信公眾號(hào): 揚(yáng)帆去遠(yuǎn)航（ID:Jackai_liu)

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

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