常見模塊設計--權限管理（一）

1.基於 RBAC（Role-based Access Control）權限訪問控制。也就是說一個用戶能夠有多個角色，一個角色能夠有多個權限，經過將角色和權限分離開來提升設計的可擴展性，一般一個用戶有多個角色，一個角色也會屬於多個用戶（多對多），一個角色有多個權限，一個權限也會屬於多個角色（多對多）。

2.最簡單版本
假設：咱們拿到一個用戶對象，
能夠經過：用戶id –>角色id–>角色名稱（什麼角色）–>權限id –> 權限標識 –>獲取權限。最終獲取權限獲取角色信息。

角色：能夠簡單理解爲許多權限的集合。好比二級管理員，三級管理員。

3.用戶組模式
若是用戶數量比較龐大，能夠加入用戶組模式。須要給用戶分組，每一個用戶組內有多個用戶，能夠給用戶受權外，也能夠給用戶組受權。最終用戶擁有的全部權限 = 用戶我的擁有的權限+該用戶所在用戶組擁有的權限。（這個設計相似 svn 中的用戶權限，好比，將一個svn用戶加入到 group中，而後設置group的權限，之後加入更多的用戶，就不用再一一設置用戶的權限了。）

 

4.權限分類
大部分是針對功能模塊，好比對信息記錄的增刪改（信息狀態修改，文件的刪除修改等），菜單的訪問，輸入框，按鈕的可見性，是否能夠新增下級管理員等。有些權限設計，會把功能操做做爲一類，而把文件、菜單、頁面元素等做爲另外一類，這樣構成「用戶-角色-權限-資源」的受權模型。而在作數據表建模時，可把功能操做和資源統一管理，也就是都直接與權限表進行關聯，這樣可能更具便捷性和易擴展性。

 

5.完整版
請留意權限表中有一列「權限類型」，咱們根據它的取值來區分是哪一類權限，如「MENU」表示菜單的訪問權限、「OPERATION」表示功能模塊的操做權限、「FILE」表示文件的修改權限、「ELEMENT」表示頁面元素的可見性控制等。

優勢：（1）不須要區分哪些是權限操做，哪些是資源，（實際上，有時候也很差區分，如菜單，把它理解爲資源呢仍是功能模塊權限呢？）。
（2）方便擴展，當系統要對新的東西進行權限控制時，我只須要創建一個新的關聯表「權限XX關聯表」，並肯定這類權限的權限類型字符串。

這裏要注意的是，權限表與權限菜單關聯表、權限菜單關聯表與菜單表都是一對一的關係。（文件、頁面權限點、功能操做等同理）。也就是每添加一個菜單，就得同時往這三個表中各插入一條記錄。這樣，能夠不須要權限菜單關聯表，讓權限表與菜單表直接關聯，此時，須在權限表中新增一列用來保存菜單的ID，權限表經過「權限類型」和這個ID來區分是種類型下的哪條記錄。