国外亚洲成av人片在线观看,热99re久久精品这里都是精品,天堂网在线最新版www,国产成人av区一区二区三,51久久成人国产精品麻豆

隨著使用者類型越來越豐富，導(dǎo)致權(quán)限系統(tǒng)必可不少。本文詳細(xì)的跟大家說說，為什么會(huì)有權(quán)限系統(tǒng)？或者換個(gè)說法，為什么需要權(quán)限系統(tǒng)？

權(quán)限系統(tǒng)其實(shí)不只是應(yīng)用于電商領(lǐng)域，各個(gè)領(lǐng)域都有可能用到。一旦公司系統(tǒng)做大，系統(tǒng)使用者的類型越來越豐富，權(quán)限系統(tǒng)就必不可少了。也就是說，小公司可能會(huì)沒有權(quán)限系統(tǒng)，一般用一個(gè)admin賬號(hào)供所有成員使用。

這里需要注意，我說的使用者類型越來越豐富，導(dǎo)致權(quán)限系統(tǒng)必可不少。很簡單，假設(shè)一個(gè)系統(tǒng)只有一類使用者，這一類人必然有相同的使用權(quán)限，那就無所謂有沒有權(quán)限系統(tǒng)了。

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

看權(quán)限兩個(gè)字，可以通俗的理解為權(quán)力限制，即不同的人由于擁有不同權(quán)力，他所看到的、能使用的可能不一樣。對應(yīng)到一個(gè)應(yīng)用系統(tǒng)，其實(shí)就是一個(gè)用戶可能擁有不同的數(shù)據(jù)權(quán)限（看到的）和操作權(quán)限（使用的）?；蛘叽蠹铱梢园褭?quán)限看成資源獲取權(quán)，B/S結(jié)構(gòu)里，你通過瀏覽器有沒有向服務(wù)器請求某項(xiàng)資源的權(quán)力。

很多公司喜歡做用戶白名單這種事，其實(shí)道理和權(quán)限系統(tǒng)一致，給白名單用戶開方便之門，讓他們訪問非白名單用戶訪問不到的資源。總結(jié)來說就是，我需要通過權(quán)限決定誰可以訪問我的資源。

另外，現(xiàn)在大部分文章沒有把數(shù)據(jù)權(quán)限和操作權(quán)限說明白，我會(huì)試圖在本文中講明白這個(gè)問題。

更多的鋪墊就不說了，全文將會(huì)以這個(gè)節(jié)奏進(jìn)行：

1. 權(quán)限系統(tǒng)的背景，從這一部分你會(huì)知道為什么需要誕生權(quán)限系統(tǒng)。
2. 權(quán)限系統(tǒng)經(jīng)典模型，這一部分我會(huì)簡單介紹一下RBAC模型。
3. 操作和數(shù)據(jù)權(quán)限，在這一部分，我會(huì)把大部分文章沒有講清楚的數(shù)據(jù)權(quán)限和操作權(quán)限講明白。
4. 權(quán)限系統(tǒng)實(shí)操，在這一部分我會(huì)簡單說下做一個(gè)權(quán)限系統(tǒng)的底層邏輯，讓你很快能”復(fù)制”一個(gè)權(quán)限系統(tǒng)。

二、權(quán)限系統(tǒng)的背景

為什么會(huì)有權(quán)限系統(tǒng)？或者換個(gè)說法，為什么需要權(quán)限系統(tǒng)？

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

權(quán)限系統(tǒng)起源是提供企業(yè)級(jí)應(yīng)用軟件解決方案的公司，如SAP、PeopleSoft等，也是這類公司最早開始探索高內(nèi)聚低耦合系統(tǒng)。

舉個(gè)可能不恰當(dāng)?shù)睦樱寒?dāng)客戶只想要WMS的時(shí)候，你說OMS和WMS不可分割，想買WMS就必須買OMS，顯然是不合理的。

這和權(quán)限系統(tǒng)有什么關(guān)系呢？

OMS和WMS，一個(gè)是訂單管理系統(tǒng)，一個(gè)是倉庫管理系統(tǒng)。假設(shè)OMS的使用者是公司客服，WMS的使用者是公司倉庫管理員。這里出現(xiàn)了兩個(gè)系統(tǒng)，兩類使用者，客服應(yīng)該看到并使用WMS么？

最早的一批提供企業(yè)級(jí)應(yīng)用軟件服務(wù)的公司，也面臨著同樣的問題，隨著客戶公司的業(yè)務(wù)拓展，首先是客戶公司對各子系統(tǒng)的需求量增大，可能不僅僅只需要一個(gè)HRMS，其次是對系統(tǒng)的使用安全、保密性，系統(tǒng)操作人員的權(quán)責(zé)關(guān)系界定上越來越嚴(yán)格，最后是B/S結(jié)構(gòu)出現(xiàn)后帶來的便捷性（需要注意的是這一點(diǎn)并不是初期探索權(quán)限系統(tǒng)的原因）。

關(guān)于這一點(diǎn)簡單畫了一個(gè)圖來說明，如下：

從圖中可以看出來，所有資源都統(tǒng)一存放在一處，當(dāng)用戶需要請求資源的時(shí)候，先經(jīng)過資源表判斷該用戶是否有對應(yīng)權(quán)限，如果有則返回結(jié)果。

沒有B/S結(jié)構(gòu)，一個(gè)軟件服務(wù)公司可能需要為客戶組裝各種本地化的系統(tǒng)（如sys1和sys2打一個(gè)包，sys1單獨(dú)打一個(gè)包，……），這就是B/S結(jié)構(gòu)帶來的便捷性，而權(quán)限系統(tǒng)在這中間起了至關(guān)重要的作用。

三、權(quán)限系統(tǒng)經(jīng)典模型

需要先說明一點(diǎn)，在權(quán)限系統(tǒng)文章里強(qiáng)調(diào)RBAC模型，只是為了讓大家對這個(gè)經(jīng)典模型重視起來，再強(qiáng)調(diào)一下RBAC模型的基本結(jié)構(gòu)：用戶-?角色-?權(quán)限，卻不僅限于此，更多細(xì)節(jié)需要大家親自去摸索。

RBAC模型可以分為：RBAC 0、RBAC 1、RBAC 2、RBAC 3 四個(gè)階段，一般公司使用RBAC0的模型就可以。另外，RBAC 0相當(dāng)于底層邏輯，后三者都是在RBAC 0模型上的拔高。

我先簡單介紹下這四個(gè)RBAC模型：

RBAC 0模型：用戶和角色、角色和權(quán)限多對多關(guān)系。

簡單來說就是一個(gè)用戶擁有多個(gè)角色，一個(gè)角色可以被多個(gè)用戶擁有，這是用戶和角色的多對多關(guān)系；同樣的，角色和權(quán)限也是如此。

RBAC 0模型如下圖：沒有畫太多線，但是已經(jīng)能夠看出多對多關(guān)系。

RBAC 1模型：相對于RBAC 0模型，增加了角色分級(jí)的邏輯，類似于樹形結(jié)構(gòu)，下一節(jié)點(diǎn)繼承上一節(jié)點(diǎn)的所有權(quán)限，如role1根節(jié)點(diǎn)下有role1.1和role1.2兩個(gè)子節(jié)點(diǎn)。

角色分級(jí)的邏輯可以有效的規(guī)范角色創(chuàng)建（主要得益于權(quán)限繼承邏輯），我之前做過BD工具（類CRM），BD之間就有分級(jí)（經(jīng)理、主管、專員），如果采用RBAC 0模型做權(quán)限系統(tǒng)，我可能需要為經(jīng)理、主管、專員分別創(chuàng)建一個(gè)角色（角色之間權(quán)限無繼承性），極有可能出現(xiàn)一個(gè)問題，由于權(quán)限配置錯(cuò)誤，主管擁有經(jīng)理都沒有權(quán)限。

而RBAC 1模型就很好解決了這個(gè)問題，創(chuàng)建完經(jīng)理角色并配置好權(quán)限后，主管角色的權(quán)限繼承經(jīng)理角色的權(quán)限，并且支持針對性刪減主管權(quán)限。

RBAC 1模型如下圖：多對多關(guān)系仍舊沒有改變，只增加角色分級(jí)邏輯。

RBAC 2模型：基于RBAC 0模型，對角色增加了更多約束條件。

如角色互斥，比較經(jīng)典的案例是財(cái)務(wù)系統(tǒng)中出納不得兼管稽核，那么在賦予財(cái)務(wù)系統(tǒng)操作人員角色時(shí)，同一個(gè)操作員不能同時(shí)擁有出納和稽核兩個(gè)角色。

如角色數(shù)量限制，例如：一個(gè)角色專門為公司CEO創(chuàng)建的，最后發(fā)現(xiàn)公司有10個(gè)人擁有CEO角色，一個(gè)公司有10個(gè)CEO？

這就是對角色數(shù)量的限制，它指的是有多少用戶能擁有這個(gè)角色。

RBAC 2?模型主要是為了增加角色賦予的限制條件，這也符合權(quán)限系統(tǒng)的目標(biāo)：權(quán)責(zé)明確，系統(tǒng)使用安全、保密。

RBAC 3模型：同樣是基于RBAC0模型，但是綜合了RBAC 1和RBAC 2的所有特點(diǎn)。這里就不在多描述，讀者返回去看RBAC 1和RBAC 2模型的描述即可。

四、操作和數(shù)據(jù)權(quán)限

寫在之前，這一部分，我主要是講自己的理解，讀者們需要辯證的去看這一部分。

用戶在使用操作系統(tǒng)時(shí)能進(jìn)行的增刪改查我都?xì)w為操作權(quán)限，有很多人將增刪改歸為數(shù)據(jù)權(quán)限，因?yàn)檫@是在更改數(shù)據(jù)庫某張表里的記錄，必然是數(shù)據(jù)權(quán)限，真的是這樣么？例如：商品中心里新增加一個(gè)商品，這到底是操作權(quán)限還是數(shù)據(jù)權(quán)限？

在我看來，凡是在操作系統(tǒng)中的任何動(dòng)作、交互以及結(jié)果都是操作權(quán)限。那么，我說的數(shù)據(jù)權(quán)限是什么呢？

上文提到過我做的BD工具，再用這個(gè)例子：

先簡單介紹我們的業(yè)務(wù)模式：BD專員負(fù)責(zé)拓展客戶，BD主管直接管理推動(dòng)專員作業(yè)，主管上級(jí)是經(jīng)理，經(jīng)理負(fù)責(zé)組織管理主管作業(yè)，這條業(yè)務(wù)線基本上如下圖：

從上圖很容易能看出來我說的數(shù)據(jù)權(quán)限是什么了，如果以客戶作為最小數(shù)據(jù)單元往上看，你會(huì)發(fā)現(xiàn)：客戶2.1.1和客戶2.1.2只屬于專員2.1，只屬于主管2，再往上就是經(jīng)理。

這個(gè)屬于關(guān)系換另外一句話就是：我的客戶只有我和我的直屬上級(jí)以及直屬上級(jí)的領(lǐng)導(dǎo)能看到，這也就是我說的數(shù)據(jù)權(quán)限。為什么這么說呢？

我們在作業(yè)過程中，銷售數(shù)據(jù)是客戶這個(gè)最小單元產(chǎn)生的，沒有客戶就沒有銷售數(shù)據(jù)，那么我的客戶產(chǎn)生的銷售數(shù)據(jù)誰可見呢？

這就是我說的數(shù)據(jù)權(quán)限。

簡單說下，在實(shí)現(xiàn)數(shù)據(jù)權(quán)限時(shí)至少有兩種方式：

• 一種上文提到了，利用RBAC 1模型，角色分級(jí)來實(shí)現(xiàn)，我們需要的就是角色分級(jí)帶來的角色樹，利用樹形結(jié)構(gòu)去控制數(shù)據(jù)輸出。
• 另外一種方式，也就是我的實(shí)現(xiàn)方式，雷同于RBAC 1模型的角色樹，我利用HRMS中的人事組織架構(gòu)來實(shí)現(xiàn)數(shù)據(jù)輸出，也即是打通HRMS系統(tǒng)和對應(yīng)需要數(shù)據(jù)權(quán)限控制的系統(tǒng)，當(dāng)涉及到數(shù)據(jù)輸出時(shí)，會(huì)調(diào)用HRMS系統(tǒng)中的組織結(jié)構(gòu)樹，從而確定數(shù)據(jù)輸出范圍。當(dāng)然我們在開發(fā)過程中，也可以直接把組織結(jié)構(gòu)樹置于權(quán)限系統(tǒng)之中，這種方式適用于組織架構(gòu)相對固化的組織（如國企），但一般不建議這樣做，系統(tǒng)的靈活配置、高可拓展性是開發(fā)想要的，也是產(chǎn)品需要考慮的。

這就是我理解的操作權(quán)限和數(shù)據(jù)權(quán)限，再次希望大家辯證的去看，自己多思考。

五、權(quán)限系統(tǒng)實(shí)操

到這一部分，我相信絕大部分產(chǎn)品同學(xué)已經(jīng)有自己對權(quán)限系統(tǒng)的認(rèn)知了，特別是看到RBAC模型后，做一個(gè)簡單的權(quán)限系統(tǒng)應(yīng)該沒任何問題。

我說的實(shí)操的底層邏輯其實(shí)也是基于RBAC模型，再次強(qiáng)調(diào)下RBAC模型：用戶–?角色–?權(quán)限。

那么，一個(gè)簡單的權(quán)限系統(tǒng)應(yīng)該具備哪幾塊呢？

首先考慮一個(gè)問題，用戶從哪兒來？

很多權(quán)限系統(tǒng)直接在權(quán)限系統(tǒng)內(nèi)創(chuàng)建一個(gè)用戶，也可以打通HRMS系統(tǒng)，員工即用戶，省去專門創(chuàng)建用戶的一步。我想說的是后者，即打通HRMS系統(tǒng)。多說一句，這種設(shè)計(jì)一般需要在員工入職的時(shí)候?yàn)槠溥x擇相應(yīng)角色。

用戶已經(jīng)有了，在這個(gè)前提下，就可以考慮其他問題了。

在RBAC模型下，給這樣一個(gè)場景，創(chuàng)建一個(gè)角色，并為這個(gè)角色賦予相應(yīng)權(quán)限，最后將角色賦予用戶。那么，這個(gè)用戶就擁有了該角色所擁有的權(quán)限。

抽象一下這個(gè)問題：開始》創(chuàng)建角色》為角色賦予權(quán)限》添加用戶（調(diào)用HRMS）》將角色賦予用戶》結(jié)束。

底層邏輯已經(jīng)抽象出來了，那么該如何設(shè)計(jì)呢？

• 第一步，需要角色管理列表，在角色管理列表能快速創(chuàng)建一個(gè)角色；
• 第二步，角色管列表中能跳轉(zhuǎn)至為角色配置權(quán)限的頁面，也就是說有一個(gè)權(quán)限配置頁；
• 第三步，需要有用戶管理列表，在用戶管理列表能快速添加一個(gè)用戶，添加用戶的這一頁至少有讓用戶關(guān)聯(lián)角色的功能。

簡單來說權(quán)限系統(tǒng)設(shè)計(jì)至少有這三步，這樣就完成了之前場景預(yù)定的全部內(nèi)容，即：創(chuàng)建一個(gè)角色，并為這個(gè)角色賦予相應(yīng)權(quán)限，最后將角色賦予用戶。

到這里權(quán)限系統(tǒng)也算是講完了，希望大家能喜歡，歡迎大家一起交流！

相關(guān)閱讀

入門電商，先從線下到線上說起

電商入門（2）：購物車功能要點(diǎn)和背后邏輯

電商入門 （3）：電商CMS，一勞永逸的建站方案

電商入門（4）：如果我來負(fù)責(zé)搜狗云表情的搜索功能，會(huì)怎樣去優(yōu)化？

作者：QJQ，微信公眾號(hào)：倔牛的人生

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

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