中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

用戶權限管理是指在B端后臺中，需要給用戶賦予角色和訪問權限等，是很多后臺系統建設的基礎。那我們應如何入手進行搭建呢？作者結合實際工作中的經驗，將這部分的理解梳理出來，希望能對你有所幫助。

一、為什么要進行用戶權限設計？

用戶權限設計的目的是對不同的人訪問資源進行權限的控制，避免因權限控制缺失或操作不當引發的風險問題，如操作錯誤，隱私數據泄露等問題。

在B端系統中，不同角色的用戶對于系統功能和數據的需求是不同的，因此需要對用戶進行分類，并為每個分類分配相應的角色和權限。

這里我們以OA系統為例，系統提供了100多個菜單頁面，但是有多種不同身份的使用者，這時，我們就需要對不同的員工，相同部門級別不同的員工分配權限，這就要求我們必須在后臺系統中引入用戶權限設計。

例如：

HR和行政人員可以看到【員工信息頁面】，但HR的頁面有【入職】按鈕，而行政卻沒有；

再比如：

財務部有2名員工，員工A負責研發部的財務預算支出，員工B負責銷售部的預算支出，雖然他們倆都能訪問【預算支出頁面】，但卻只能看到自己管轄的部門的，不能看到其他人的。而財務總監，可以看到全公司的預算數據。

二 、系統權限

在講完了為什么需要進行用戶權限設計之后，我們再來講下常見的權限。

1. 菜單權限

菜單權限是指用戶登錄系統后可以訪問的菜單項，我們可以將菜單授權給用戶，擁有該授權的用戶則可以使用該菜單下相關功能。菜單權限相較于其他權限而言，是最基礎的權限，其他權限基于菜單權限展開拓展。

常見的功能菜單以一級菜單 → 二級菜單 → 三級菜單依次排列，勾選上對應的菜單，即擁有該菜單的訪問權限。

2. 按鈕權限

按鈕權限一般也可理解為操作權限，是指用戶登錄系統后可以進行的操作，例如查看、編輯、刪除等。我們一般將操作權限賦予到按鈕上，當需要給某類用戶某種特定的按鈕權限時，將按鈕權限賦予用戶，那么用戶即擁有操作權限。例如銷售部門可以查看、編輯客戶信息、訂單信息，而運營部門只能查看。

以下是我們公司的一些常見的按鈕權限的配置樣式，我們一般喜歡將按鈕權限配置在某個菜單之下，當勾選中該按鈕時，則表示對應的角色有該按鈕權限。

3. 數據權限

數據展示權限是指用戶登錄系統后可以查看的數據范圍，即能查看多少數據，什么類型的數據。例如，管理員能查看所有坐席人員的質檢記錄，而坐席人員只能查看自己的質檢記錄。

最常見的數據權限一般是基于“組織架構樹”展開的，即可以設置該數據可以給組織結構中的哪些人員可見，或者指定給某個組織可見。

數據權限的設置一般會根據公司規模，事業線的多少做區分，當公司規模比較小，沒有復雜的多事業線時，一般采用以下方式，決定用戶能看到是本人，還是本部門，還是本公司的數據。

當公司規模較大，且公司下有多個子事業部時，這時可以將數據權限按組織架構進行指定，指定xx事業部下xx部門可進行查看該數據權限。

上述說的2種數據權限，一般更多指的是數據的查看權限，那如果想控制某些部門不僅可以查看，還可以擁有編輯的權限。除了可以通過按鈕權限實現以外，還可以將數據權限的增刪改權限賦予給某個某部門，那擁有該權限的部門則可進行編輯等權限。

參考以下示例（一般不建議這種數據權限控制）。

那除了對某個頁面進行整體的數據權限控制以外，我們還可以針對某一列某一行進行權限控制。例如【員工信息頁面】，人事可以身份證號列，而行政卻看不到。

4. 應用權限

應用權限是功能組的衍生，可以把應用權限理解功能模塊的集合，一般更多的用于saas產品上。例如，我們可以把功能合并一下：包含戰略管理、財務管理、人事管理、訂單管理幾個模塊整合成幾個大的應用，然后根據企業的需求，直接將該應用的權限分配到用戶上。

三、角色

講完了系統的角色，接下來需要解決用戶的問題。系統有很多用戶，那如何給每一個用戶分配合適的權限？一般有2種方式。

1. 直接分配

直接分配就是直接將權限分配給具體的某一個用戶。這種方式就是比較靈活，能最大化的滿足每個用戶的個性化需求。但這種方式的缺點也比較明顯，一旦用戶量多起來，這種工作量就很大，不適合于大規模的公司。

舉個簡單的例子：當公司入職了10名銷售部的新員工，需要給他們分配銷售專員的角色，那這時如果用直接分配的方式，那么就得重復操作10次，這種方式工作量太大，相信到時候分配權限的員工，肯定會吐槽你。

2. 基于角色RBAC模型進行分配

RBAC（Role-BasedAccess Control）基于角色的訪問控制方式：該模型首先定義一些組織內的角色，如局長、科長、職員；再根據管理規定給這些角色分配相應的權限，最后對組織內的每個人根據具體業務和職位分配一個或多個角色。

基于角色RBAC模型的分配方式，就是間接分配方式，這是將用戶跟權限之間建立一個集合，然后將用戶通過角色與權限進行管理，這就是我們傳說的用戶角色權限模型。

這種方式就只需要將用戶跟角色建立關聯，在給用戶分配權限時，只需要給用戶關聯角色即可。當角色權限需要變更時，直接調整角色權限即可，擁有該角色的用戶權限也會同步進行動態調整。

RBAC模型可以分為：RBAC0、RBAC1、RBAC2、RBAC3 四種。

RBAC0：最基本模型，它包括用戶、角色和權限三個基礎組成部分，其中用戶和角色之間的關系是多對一的關系，而角色和權限之間的關系是多對多的關系（大部分后臺系統都采用了RBAC0這種方式），

• 多對一：即一個角色被多個用戶充當；
• 多對多：即一個角色可以擁有多種權限。

那么，什么時候該使用多對一的權限體系，什么時候又該使用多對多的權限體系呢？

如果系統功能比較單一，使用人員較少，崗位權限相對清晰且確保不會出現兼崗的情況，此時可以考慮用多對一的權限體系。其余情況盡量使用多對多的權限體系，保證系統的可擴展性。如：張三既是行政，也負責財務工作，那張三就同時擁有行政和財務兩個角色的權限。

RBAC1:角色分層模型，RBAC1是在RBAC0的基礎上增加了角色分層的概念，引入繼承概念，即高層級高的角色可以繼承低等級的角色的所有權限。

例如針對銷售部門，不同的區域銷售經擁有不同的角色，顯然全國區經理的權限是不能大于華南區經理的，如果這時候采用RBAC0的方式的話，就有可能出現配置出錯的問題，會導致華南區經理擁有了全股區經理都沒有的權限。

那如果這時引入RBAC1角色分層，配置好廣東區經理的角色外，華南區經理的角色就自動繼承了廣東區經理的角色，這時候再給華南區經理分配該角色特有的權限就可。

RBAC2：角色限制模型，RBAC2是在RBAC0的基礎上增加了對角色的限制，包含基數約束、角色互斥、先決條件、運行互斥等。

• 基數約束：基數約束是指給一個角色被分配給多少個用戶是有上限的，不能無限制的添加，即如果創建了總經理的角色，那這個角色被賦予的用戶數是有限的，當超過時，該角色將不能再分配給用戶。
• 角色互斥：角色互斥是指一個用戶不可能同時擁有多個互斥的角色，就像財務系統種，一個用戶不能同時擁有財務和會計的角色。
• 先決條件：先決條件是指用戶要想獲得高層級的權限，必須先擁有低層級的權限，好比如必須先擁有財務助理的權限，才能擁有財務經理的權限。
• 運行互斥：運行互斥是指使用時只能選擇一個角色進行使用，好比如老師和家長，一個用戶即可能家長也可能是老師，那在使用時，只能選擇使用家長的角色或者時老師的角色，不能2個角色同時使用。

RBAC3:統一模型，基于RBAC0進行設計，同時包含了RBAC1和RBAC2模型的特點。但一般后臺系統中，使用RBAC3的情況很少，大部分公司都是采用了RBAC0。

四、用戶、角色、權限之間的關系

在講完了RBAC模型之后，再跟大家分享一下用戶、角色、權限以及他們對應的組別。

• 用戶：即系統訪問的操作者，可以理解為登錄系統的用戶；
• 權限：即被允許訪問或某種操作的授權資格，一般可以理解為對系統的增刪改查權限；
• 角色：即具有同類相同操作權限的用戶。

例如：用戶張三，他在OA系統中被賦予了HR的角色，那他則可以操作【員工入職】的權限。

在某些用戶數量或者系統功能復雜的后臺系統中，為了方便統一管理，還會引入組的概念，即用戶組，權限組，角色組。

• 用戶組：用戶的集合。當用戶數量較多時，可以給用戶進行分組。當公司有新員工入職或者需要給員工分配其他角色時，只需要將用戶加入用戶組，那么該用戶就自動擁有了該用戶組的權限，無需再一一設置了。
• 角色組：角色的集合，當多個角色均需擁有相同的權限時，可以采用角色組，例如行政人員，HR均需看到公司的員工信息，那么此時可以將HR、行政建立一個角色組，再將查看員工信息的權限賦予該用戶組，那么用戶組內的角色就自動擁有了這些權限。
• 權限組：權限的集合，可以給權限設置一個權限組，例如可以將查看查看員工業績、查看客戶信息關聯成一個權限組，當下次需要給用戶賦予權限時，直接選擇該權限組即可，就不需要一一去設置多個權限了。

五、總結

1. 根據需要設計用戶權限體系

我們應根據公司的實際需要，設計最適合的用戶權限體系，不應過分的追求功能的大而全，最適合的才是最好的。

2. 需要考慮使用者的感受

在設計前端樣式及使用情況時，需考慮用戶的使用成本，應盡可能的確保設計的系統簡單通俗易用。