權限控制

用戶配置系統菜單，操做權限（菜單和操做按鈕有一套標碼規範，名稱、id等）-》用戶配置用戶角色的菜單、操做權限->後臺生成權限樹->用戶登陸業務系統，根據權限樹控制菜單和操做->後臺攔截器控制請求

 

做者：huiter
連接：https://www.zhihu.com/question/20313385/answer/118571022
來源：知乎
著做權歸做者全部，轉載請聯繫做者得到受權。

最近正好要重作權限系統的設計。
參考了RBAC（Role-Based Access Control，基於角色的訪問控制）
不過以爲過於複雜，因此整理了一套簡單的權限模型：

權限系統一般包括以下基本元素：
用戶、角色、 權限、 資源、操做 。


角色的本質是『權限的集合』， 我簡單分爲兩類：
身份角色：總經理、A項目負責人、B項目負責人、工程師、設計師
權限角色：A項目權限、B項目權限、若干文件權限

有的權限系統，一個用戶只能有一個身份。
但現實中即便身份角色，一我的也可能有多重身份，因此會帶來限制。
因此在簡化模型中，一個用戶能夠對應多個角色。

權限，我簡單分爲兩類：
批量權限，好比『訪問項目列表權限』、『刪除設備權限』、『組織架構管理』。
單一資源權限，好比『A文件的訪問權』，『A文件的刪除權』這類權限就是跟 資源、操做相關 。

批量權限，一般會有批量受權給一批用戶。
單一資源權限，一般會受權給指定用戶。


整理爲簡單的權限模型：
權限，分爲『批量權限』、『單一資源權限』。
角色，爲『批量權限』的集合。
用戶，能夠同時具備多個『角色』。
用戶，能夠同時具備多項『批量權限』。
用戶，能夠同時具備多項『單一資源權限』。

用戶的權限集 ＝ 用戶的『批量權限』 + 用戶的『單一資源權限』+ 用戶的全部『角色』的權限 
另外用戶建立的資源時，能夠得到對應『單一資源權限』的權限。

權限管理系統的迭代過程：

1. 用戶 <- 批量權限

2. 用戶 <- 角色 <- 批量權限
   用戶 <- 批量權限

3. 用戶 <- 角色 <- 批量權限
   用戶 <- 批量權限
   用戶 -> 單一資源權限

<- 箭頭指向表示關聯關係的存儲位置。

好比，系統中有門店管理、文件管理、22個應用。

咱們用模型 1，咱們能夠給一個用戶分配門店管理，一、2號應用權限。
但隨着用戶量增多至 1000 時，系統中新增 23 號應用，北京的用戶能夠得到 23號應用的權限。
這時，一個一個修改用戶的權限已經沒法知足的需求了，因此能夠引入模型 2，建立角色"北京"，並把用戶進行關聯。

這樣咱們能夠直接修改"北京"角色的權限集，就完成了多用戶的權限分配。
這裏角色能夠是用戶組、權限組，本質上仍是權限的集合。

進一步，咱們有1000個門店，可是要分爲10個大區，每一個大區都有管理員，他們本身看到本身有權限的門店。這時，咱們能夠用模型 3，記錄都有哪些用戶具備該門店的訪問權限。由於一個用戶可管理的資源可能不少，全部訪問權限能夠存儲在門店的結構中。這個場景中，直接使用了用戶與權限的關聯，避免了須要建立大量的角色。

再日後發展，可能會但願角色也能夠關聯單一資源權限、角色可繼承。
可是這些可能會使得權限管理變得複雜，提高商戶的操做門檻。
目前作過的項目，模式 3 都不多用到。

從商戶的視角，他能夠在權限管理中，管理子帳號的批量權限。
在門店管理中，分配每一個門店的訪問權限。
這樣時簡單可接受的。

系統管理員，來管理角色及角色的分配，時機成熟能夠將角色管理一部分下放給商戶。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

能夠提供一個簡化權限系統的設計例子。