如何設計一個完美的權限管理模塊？

或許最好的人生，不在於詩和遠方，而在於平靜下來發現，眼前熟悉的一切皆是心之所向。

咱們比較常見的就是基於角色的訪問控制，用戶經過角色與權限進行關聯。簡單地說，一個用戶擁有多個角色，一個角色擁有多個權限。這樣，就構形成「用戶-角色-權限」的受權模型。在這種模型中，用戶與角色之間、角色與權限之間，一般都是多對多的關係。以下圖：

基於這個，得先了解角色究竟是什麼？咱們能夠理解它爲必定數量的權限的集合，是一個權限的載體。

例如：一個論壇的「管理員」、「版主」，它們都是角色。可是所能作的事情是不徹底同樣的，版主只能管理版內的貼子，用戶等，而這些都是屬於權限，若是想要給某個用戶授予這些權限，不用直接將權限授予用戶，只需將「版主」這個角色賦予該用戶便可。

可是經過上面咱們也發現問題了，若是用戶的數量很是大的時候，就須要給系統的每個用戶逐一受權(分配角色)，這是件很是繁瑣的事情，這時就能夠增長一個用戶組，每一個用戶組內有多個用戶，除了給單個用戶受權外，還能夠給用戶組受權，這樣一來，經過一次受權，就能夠同時給多個用戶授予相同的權限，而這時用戶的全部權限就是用戶我的擁有的權限與該用戶所在組所擁有的權限之和。用戶組、用戶與角色三者的關聯關係以下圖：

一般在應用系統裏面的權限咱們把它表現爲菜單的訪問(頁面級)、功能模塊的操做(功能級)、文件上傳的刪改，甚至頁面上某個按鈕、圖片是否可見等等都屬於權限的範疇。有些權限設計，會把功能操做做爲一類，而把文件、菜單、頁面元素等做爲另外一類，這樣構成「用戶-角色-權限-資源」的受權模型。而在作數據表建模時，可把功能操做和資源統一管理，也就是都直接與權限表進行關聯，這樣可能更具便捷性和易擴展性。以下圖：

這裏特別須要注意如下權限表中有一列「PowerType(權限類型)」，咱們根據它的取值來區分是哪一類權限，能夠把它理解爲一個枚舉，如「MENU」表示菜單的訪問權限、「OPERATION」表示功能模塊的操做權限、「FILE」表示文件的修改權限、「ELEMENT」表示頁面元素的可見性控制等。

這樣設計的好處有兩個：

1、不須要區分哪些是權限操做，哪些是資源，（實際上，有時候也很差區分，如菜單，把它理解爲資源呢仍是功能模塊權限呢？）；

2、方便擴展，當系統要對新的東西進行權限控制時，我只須要創建一個新的關聯表「權限XX關聯表」，並肯定這類權限的權限類型字符串便可。

須要注意的是，權限表與權限菜單關聯表、權限菜單關聯表與菜單表都是一對一的關係。（文件、頁面權限點、功能操做等同理）。也就是每添加一個菜單，就得同時往這三個表中各插入一條記錄。

這樣，能夠不須要權限菜單關聯表，讓權限表與菜單表直接關聯，此時，須在權限表中新增一列用來保存菜單的ID，權限表經過「權限類型」和這個ID來區分是種類型下的哪條記錄。最後擴展出來的模型完整設計以下圖：

注意上面額外增長了一個操做日誌表；

隨着系統的日益龐大，爲了方便管理，若是有須要可引入角色組對角色進行分類管理，跟用戶組不一樣，角色組不參與受權。

例如：當遇到有多個子公司，每一個子公司下有多個部門，這是咱們就能夠把部門理解爲角色，子公司理解爲角色組，角色組不參於權限分配。另外，爲方便上面各主表自身的管理與查找，可採用樹型結構，如菜單樹、功能樹等，固然這些可不須要參於權限分配。

數據字典：
1.用戶表：

2.角色表：

3.用戶與角色關聯表

4.用戶組表

5.用戶組與用戶信息關聯表

6.用戶組與角色關聯表

7．菜單表

8.頁面元素表

9.文件表

10.權限表

11.權限與菜單關聯表

12.權限與頁面元素關聯表

13.權限與文件關聯表

14.功能操做表

15.權限與功能操做關聯表

16.角色與權限關聯表

17.操做日誌表