設計一個靈活、通用、友善的權限管理系統。
在這個系統中,我們需要對系統的所有資源進行權限控制,那麼系統中的資源包括哪些呢?我們可以把這些資源簡單概括為靜态資源(功能操作、資料列)和動态資源(資料),也分别稱為對象資源和資料資源,後者是我們在系統設計與實作中的叫法。
系統的目标就是對應用系統的所有對象資源和資料資源進行權限控制,比如應用系統的功能菜單、各個界面的按鈕、資料顯示的列以及各種行級資料進行權限的操控。
三.相關對象及其關系
大概理清了一下權限系統的相關概念,如下所示:
1. 權限
系統的所有權限資訊。權限具有上下級關系,是一個樹狀的結構。下面來看一個例子
系統管理
使用者管理
檢視使用者
新增使用者
修改使用者
删除使用者
對于上面的每個權限,又存在兩種情況,一個是隻是可通路,另一種是可授權,例如對于“檢視使用者”這個權限,如果使用者隻被授予“可通路”,那麼他就不能将他所具有的這個權限配置設定給其他人。
2. 使用者
應用系統的具體操作者,使用者可以自己擁有權限資訊,可以歸屬于0~n個角色,可屬于0~n個組。他的權限集是自身具有的權限、所屬的各角色具有的權限、所屬的各組具有的權限的合集。它與權限、角色、組之間的關系都是n對n的關系。
3. 角色
為了對許多擁有相似權限的使用者進行分類管理,定義了角色的概念,例如系統管理者、管理者、使用者、訪客等角色。角色具有上下級關系,可以形成樹狀視圖,父級角色的權限是自身及它的所有子角色的權限的綜合。父級角色的使用者、父級角色的組同理可推。
4. 組
為了更好地管理使用者,對使用者進行分組歸類,簡稱為使用者分組。組也具有上下級關系,可以形成樹狀視圖。在實際情況中,我們知道,組也可以具有自己的角色資訊、權限資訊。這讓我想到我們的QQ使用者群,一個群可以有多個使用者,一個使用者也可以加入多個群。每個群具有自己的權限資訊。例如檢視群共享。QQ群也可以具有自己的角色資訊,例如普通群、進階群等。
針對上面提出的四種類型的對象,讓我們通過圖來看看他們之間的關系。

有上圖中可以看出,這四者的關系很複雜,而實際的情況比這個圖還要複雜,權限、角色、組都具有上下級關系,權限管理是應用系統中比較棘手的問題,要設計一個通用的權限管理系統,工作量也着實不小。
當然對于有些項目,權限問題并不是那麼複雜。有的隻需要牽涉到權限和使用者兩種類型的對象,隻需要給使用者配置設定權限即可。
在另一些情況中,引入了角色對象,例如基于角色的權限系統,隻需要給角色配置設定權限,使用者都隸屬于角色,不需要單獨為使用者配置設定角色資訊。
通用權限管理設計篇(二)——資料庫設計
國慶前整的通用權限設計的資料庫初步設計部分,現在貼上來。
理清了對象關系之後,讓我們接着來進行資料庫的設計。在資料庫模組化時,對于N對N的
關系,一般需要加入一個關聯表來表示關聯的兩者的關系。初步估計一下,本系統至少需要十張表,分别為:權限表、使用者表、角色表、組表、使用者權限關聯表、用
戶角色關聯表、角色權限關聯表、組權限關聯表、組角色關聯表、使用者屬組關聯表。當然還可能引出一些相關的表。下面讓我們在PowerDesigner中畫出各表吧。
各表及其關系如下:
1. 使用者表
使用者表(TUser) | |||
字段名稱 | 字段 | 類型 | 備注 |
記錄辨別 | tu_id | bigint | pk, not null |
所屬組織 | to_id | bigint | fk, not null |
登入帳号 | login_name | varchar(64) | not null |
使用者密碼 | password | varchar(64) | not null |
使用者姓名 | vsername | varchar(64) | not null |
手機号 | mobile | varchar(20) | |
電子郵箱 | varchar(64) | ||
建立時間 | gen_time | datetime | not null |
登入時間 | login_time | datetime | |
上次登入時間 | last_login_time | datetime | |
登入次數 | count | bigint | not null |
2. 角色表
角色表(TRole) | |||
字段名稱 | 字段 | 類型 | 備注 |
角色ID | tr_id | bigint | pk, not null |
父級角色ID | parent_tr_id | bigint | not null |
角色名稱 | role_name | varchar(64) | not null |
建立時間 | gen_time | datetime | not null |
角色描述 | description | varchar(200) |
3. 權限表
權限表(TRight) | |||
字段名稱 | 字段 | 類型 | 備注 |
權限ID | tr_id | bigint | pk, not null |
父權限 | parent_tr_id | bigint | not null |
權限名稱 | right_name | varchar(64) | not null |
權限描述 | description | varchar(200) |
4. 組表
組表(TGroup) | |||
字段名稱 | 字段 | 類型 | 備注 |
組ID | tg_id | bigint | pk, not null |
組名稱 | group_name | varchar(64) | not null |
父組 | parent_tg_id | bigint | not null |
建立時間 | gen_time | datetime | not null |
組描述 | description | varchar(200) |
5. 角色權限表
角色權限表(TRoleRightRelation) | |||
字段名稱 | 字段 | 類型 | 備注 |
記錄辨別 | trr_id | bigint | pk, not null |
角色 | Role_id | bigint | fk, not null |
權限 | right_id | bigint | fk, not null |
權限類型 | right_type | int | not null(0:可通路,1:可授權) |
6. 組權限表
組權限表(TGroupRightRelation) | |||
字段名稱 | 字段 | 類型 | 備注 |
記錄辨別 | tgr_id | bigint | pk, not null |
組 | tg_id | bigint | fk, not null |
權限 | tr_id | bigint | fk, not null |
權限類型 | right_type | int | not null(0:可通路,1:可授權) |
7. 組角色表
組角色表(TGroupRoleRelation) | |||
字段名稱 | 字段 | 類型 | 備注 |
記錄辨別 | tgr_id | bigint | pk, not null |
組 | tg_id | bigint | fk, not null |
角色 | tr_id | bigint | pk, not null |
8. 使用者權限表
使用者權限表(TUserRightRelation) | |||
字段名稱 | 字段 | 類型 | 備注 |
記錄辨別 | tur_id | bigint | pk, not null |
使用者 | tu_id | bigint | fk, not null |
權限 | tr_id | bigint | fk, not null |
權限類型 | right_type | int | not null(0:可通路,1:可授權) |
9. 使用者角色表
使用者角色表(TUserRoleRelation) | |||
字段名稱 | 字段 | 類型 | 備注 |
記錄辨別 | tur_id | bigint | pk, not null |
使用者 | tu_id | bigint | fk, not null |
角色 | tr_id | bigint | fk, not null |
10. 使用者組表
使用者組表(TUserGroupRelation) | |||
字段名稱 | 字段 | 類型 | 備注 |
記錄辨別 | tug_id | bigint | pk, not null |
使用者 | tu_id | bigint | fk, not null |
組 | tg_id | bigint | fk, not null |
11. 組織表
組織表(TOrganization) | |||
字段名稱 | 字段 | 類型 | 備注 |
組織id | to_id | bigint | pk, not null |
父組 | parent_to_id | bigint | not null |
組織名稱 | org_name | varchar(64) | not null |
建立時間 | gen_time | datetime | not null |
組織描述 | description | varchar(200) |
12. 記錄檔表
記錄檔表(TLog) | |||
字段名稱 | 字段 | 類型 | 備注 |
日志ID | log_id | bigint | pk, not null |
操作類型 | op_type | int | not null |
操作内容 | content | varchar(200) | not null |
操作人 | tu_id | bigint | fk, not null |
操作時間 | gen_time | datetime | not null |
1. 權限資源
系統的所有權限資訊。權限具有上下級關系,是一個樹狀的結構。下面來看一個例子
系統管理
使用者管理
檢視使用者
新增使用者
修改使用者
删除使用者
對于上面的每個權限,又存在兩種情況,一個是隻是可通路,另一種是可授權,例如對于“檢視使用者”這個權限,如果使用者隻被授予“可通路”,那麼他就不能将他所具有的這個權限配置設定給其他人。
2. 使用者
應用系統的具體操作者,使用者可以自己擁有權限資訊,可以歸屬于0~n個角色,可屬于0~n個組。他的權限集是自身具有的權限、所屬的各角色具有的權限、所屬的各組具有的權限的合集。它與權限、角色、組之間的關系都是n對n的關系。
3. 角色
為了對許多擁有相似權限的使用者進行分類管理,定義了角色的概念,例如系統管理者、管理者、使用者、訪客等角色。角色具有上下級關系,可以形成樹狀視圖,父級角色的權限是自身及它的所有子角色的權限的綜合。父級角色的使用者、父級角色的組同理可推。
4. 組
為
了更好地管理使用者,對使用者進行分組歸類,簡稱為使用者分組。組也具有上下級關系,可以形成樹狀視圖。在實際情況中,我們知道,組也可以具有自己的角色資訊、
權限資訊。這讓我想到我們的QQ使用者群,一個群可以有多個使用者,一個使用者也可以加入多個群。每個群具有自己的權限資訊。例如檢視群共享。QQ群也可以具有
自己的角色資訊,例如普通群、進階群等。
針對如上提出的四種對象,我們可以整理得出它們之間的關系圖,如下所示:
總體設計思路是将系統分為組權限管理、角色權限管理、使用者權限管理、組織管理和記錄檔管理五部分。
其中組權限管理包括包含使用者、所屬角色、組權限資源群組總權限資源四部分,某個組的權限資訊可用公式表示:組權限 = 所屬角色的權限合集 + 組自身的權限。
角色權限管理包括包含使用者、包含組和角色權限三部分,某個角色的權限的計算公式為:角色權限 = 角色自身權限。
使用者權限管理包括所屬角色、所屬組、使用者權限、使用者總權限資源群組織管理五部分。某個使用者總的權限資訊存在如下計算公式:使用者權限 = 所屬角色權限合集 + 所屬組權限合集 + 使用者自身權限。
組織管理即對使用者所屬的組織進行管理,組織以樹形結構展示,組織管理具有組織的增、删、改、查功能。
記錄檔管理用于管理本系統的記錄檔。
注意:因為組和角色都具有上下級關系,是以下級的組或角色的權限隻能在自己的直屬上級的權限中選擇,下級的組或者角色的總的權限都不能大于直屬上級的總權限。
2.5 子產品結構設計
本系統的具有的功能子產品結構如下圖所示:
2.6 尚未解決的問題
無。
3. 接口設計(暫略)
3.1 使用者接口(暫略)
3.2 外部接口(暫略)
3.3 内部接口(暫略)
4. 界面總體設計
本節将闡述使用者界面的實作,在此之前對頁面元素做如下約定:
序号 | 頁面元素 | 約定 |
1 | 按鈕 | 未選中時:[按鈕名稱] 選中時:[按鈕名稱] |
2 | 單選框 | ○ 選項 |
3 | 複選框 | □ 選項 |
4 | 下拉框 | [選項,…,] ▽ |
5 | 文本框 | |________| |
6 | TextArea | |…………| |
7 | 頁簽 | 未選中時:選項名稱 選中時:選項名稱 |
8 | 未選中連結 | 連結文字 |
9 | 選中連結 | 連結文字 |
10 | 說明資訊 | 說明資訊 |
4.1 組權限管理
4.1.1包含使用者
組資訊 組1 組11 組12 組… 組2 組21 組22 組… | 所選擇組:組1 [包含使用者] [所屬角色] [組權限] [總權限] [修改] 使用者名 姓名 手機号 最近登入時間 登入次數 阿蜜果 謝星星 13666666666 2007-10-8 66 sterning xxx 13555555555 2007-10-8 10 …… |
當使用者選擇“修改”按鈕時,彈出使用者清單,操作人可以通過勾選或取消勾選來修改該組所包含的使用者。
4.1.2所屬角色
組資訊 組1 組11 組12 組… 組2 組21 組22 組… | 所選擇組:組1 [包含使用者] [所屬角色] [組權限] [總權限] [修改] 角色ID 角色名稱 角色描述 1 訪客 -- 2 初級使用者 -- |
當使用者選擇“修改”按鈕時,彈出角色樹形結構,操作人可以通過勾選或取消勾選來修改該組所屬的角色。
4.1.3組權限
組資訊 組1 組11 組12 組… 組2 組21 組22 組… | 所選擇組:組1 [包含使用者] [所屬角色] [組權限] [總權限] [儲存] [取消] |
4.1.4總權限
組資訊 組1 組11 組12 組… 組2 組21 組22 組… | 所選擇組:組1 [包含使用者] [所屬角色] [組權限] [總權限] [儲存] [取消] |
通過對已具有的權限取消勾選,或為某權限添加勾選,來修改組的權限資訊,點選“儲存”按鈕儲存修改資訊。
4.1.5組管理
在下圖中,選中組1的時候,右鍵點選可彈出組的操作清單,包括添加、删除和修改按鈕,進而完成在該組下添加子組,删除該組以及修改該組的功能。
組資訊 組1 組11 組12 組… 組2 組21 組22 組… | 所選擇組:組1 [包含使用者] [所屬角色] [組權限] [總權限] [修改] 使用者名 姓名 手機号 最近登入時間 登入次數 阿蜜果 謝星星 13666666666 2007-10-8 66 sterning xxx 13555555555 2007-10-8 10 …… |
4.2 角色權限管理
4.2.1包含使用者
角色資訊 角色1 角色11 角色12 角色… 角色2 角色21 角色22 角色… | 所選擇角色:角色1 [包含使用者] [包含組] [角色權限] [修改] 使用者名 姓名 手機号 最近登入時間 登入次數 阿蜜果 謝星星 13666666666 2007-10-8 66 sterning xxx 13555555555 2007-10-8 10 …… |
當使用者選擇“修改”按鈕時,彈出使用者清單,操作人可以通過勾選或取消勾選來修改該角色所包含的使用者。
4.2.2包含組
角色資訊 角色1 角色11 角色12 角色… 角色2 角色21 角色22 角色… | 所選擇角色:角色1 [包含使用者] [包含組] [角色權限] [修改] 組ID 組名稱 組描述 1 xxx1 -- 2 xxx2 -- …… |
當使用者選擇“修改”按鈕時,彈出使用者清單,操作人可以通過勾選或取消勾選來修改該角色所包含的組。
4.2.3角色權限
角色資訊 角色1 角色11 角色12 角色… 角色2 角色21 角色22 角色… | 所選擇角色:角色1 [包含使用者] [包含組] [角色權限] [儲存] [取消] |
通過對已具有的權限取消勾選,或為某權限添加勾選,來修改角色的權限資訊,點選“儲存”按鈕儲存修改資訊。
4.2.4管理角色
在下圖中,選中組1的時候,右鍵點選可彈出組的操作清單,包括添加、删除和修改按鈕,進而完成在該組下添加子組,删除該組以及修改該組的功能。
角色資訊 角色1 角色11 角色12 角色… 角色2 角色21 角色22 角色… | 所選擇角色:角色1 [包含使用者] [包含組] [角色權限] [修改] 使用者名 姓名 手機号 最近登入時間 登入次數 阿蜜果 謝星星 13666666666 2007-10-8 66 sterning xxx 13555555555 2007-10-8 10 …… |
4.3 使用者權限管理
4.3.1所屬角色
使用者權限資訊 xx公司 廣州分公司 阿蜜果 肖xx yy… 北京分公司 zz1 zz2 zz3… | 所選擇使用者:阿蜜果 [所屬角色] [所屬組] [使用者權限] [總權限] [修改] 角色ID 角色名稱 角色描述 1 訪客 -- 2 初級使用者 -- … |
當使用者選擇“修改”按鈕時,彈出角色樹形結構,操作人可以通過勾選或取消勾選來修改該使用者所屬的角色。
4.3.2所屬組
使用者資訊 xx公司 廣州分公司 阿蜜果 肖xx yy… 北京分公司 zz1 zz2 zz3… | 所選擇使用者:阿蜜果 [所屬角色] [所屬組] [使用者權限] [總權限] [修改] 組ID 組名稱 組描述 1 組1 -- 2 組2 -- … |
當使用者選擇“修改”按鈕時,彈出組的樹形結構,操作人可以通過勾選或取消勾選來修改該使用者所屬的組。
4.3.3使用者權限
使用者資訊 xx公司 廣州分公司 阿蜜果 肖xx yy… 北京分公司 zz1 zz2 zz3… | 所選擇使用者:阿蜜果 [所屬角色] [所屬組] [使用者權限] [總權限] [儲存] [取消] |
通過對已具有的權限取消勾選,或為某權限添加勾選,來修改使用者的權限資訊,點選“儲存”按鈕儲存修改資訊。
4.3.4總權限
使用者資訊 xx公司 廣州分公司 阿蜜果 肖xx yy… 北京分公司 zz1 zz2 zz3… | 所選擇使用者:阿蜜果 [所屬角色] [所屬組] [使用者權限] [總權限] [儲存] [取消] |
通過對已具有的權限取消勾選,或為某權限添加勾選,來修改使用者的權限資訊,點選“儲存”按鈕儲存修改資訊。
4.3.5使用者管理
當選擇了某使用者時,點選右鍵,彈出菜單清單:修改、删除、取消,點選修改和删除按鈕可以實作使用者的删除和修改功能。
選擇某個組織,例如下表中的“廣州分公司”,彈出菜單清單:添加子組織、删除組織、修改組織、添加使用者、取消,點選添加使用者按鈕可以實作使用者的添加功能。
使用者權限資訊 xx公司 廣州分公司 阿蜜果 肖xx yy… 北京分公司 zz1 zz2 zz3… | 所選擇使用者:阿蜜果 [所屬角色] [所屬組] [使用者權限] [總權限] [修改] 角色ID 角色名稱 角色描述 1 訪客 -- 2 初級使用者 -- … |
4.3.6組織管理
選擇某個組織,例如下表中的“廣州分公司”,彈出菜單清單:添加子組織、删除組織、修改組織、添加使用者、取消,點選添加子組織、删除組織、修改組織按鈕可以實作組織的添加、删除和修改功能。
使用者權限資訊 xx公司 廣州分公司 阿蜜果 肖xx yy… 北京分公司 zz1 zz2 zz3… | 所選擇使用者:阿蜜果 [所屬角色] [所屬組] [使用者權限] [總權限] [修改] 角色ID 角色名稱 角色描述 1 訪客 -- 2 初級使用者 -- … |
4.4 記錄檔管理
4.4.1查詢記錄檔
操作名稱:|________| 操作人:|________| 操作時間從 |________| 到 |________| [查詢] [重置] [删除] 編号 操作名稱 操作内容 操作人 操作時間 1 xx1 -- Amigo 2007-10-8 2 xx2 -- xxyy 2007-10-8 … |
輸入上圖表單中的查詢資訊後,點選“查詢”按鈕,可查詢出符合條件的資訊。
4.4.2删除記錄檔
操作名稱:|________| 操作人:|________| 操作時間從 |________| 到 |________| [查詢] [重置] [删除] 編号 操作名稱 操作内容 操作人 操作時間 1 xx1 -- Amigo 2007-10-8 2 xx2 -- xxyy 2007-10-8 … |
輸入上圖表單中的查詢資訊後,點選“查詢”按鈕,可查詢出符合條件的資訊。而後點選“删除”按鈕,可删除符合查詢條件的記錄檔。
5. 資料結構設計
資料庫設計的模型請參見《通用權限管理系統_資料庫模型.pdm》。表的說明請參見《通用權限管理系統資料庫設計說明書》。
5.1 設計原則
5.1.1命名的規範
資料庫中表、主鍵、外鍵、索引的命名都以統一的規則,采用大小寫敏感的形式,各種對象命名長度不要超過30個字元,這樣便于應用系統适應不同的資料庫平台。
5.1.2資料的一緻性和完整性
為了保證資料庫的一緻性和完整性,往往通過表間關聯的方式來盡可能的降低資料的備援。表間關聯是一種強制性措施,建立後,對父表(Parent Table)和子表(Child Table)的插入、更新、删除操作均要占用系統的開銷。如果資料備援低,資料的完整性容易得到保證,但增加了表間連接配接查詢的操作,為了提高系統的響應時間,合理的資料備援也是必要的。使用規則(Rule)和限制(Check)來防止系統操作人員誤輸入造成資料的錯誤是設計人員的另一種常用手段,但是,不必要的規則和限制也會占用系統的不必要開銷,需要注意的是,限制對資料的有效性驗證要比規則快。所有這些,需要在設計階段應根據系統操作的類型、頻度加以均衡考慮。
5.2 資料庫環境說明
資料庫:MySql5.0
設計庫模組化工具:PowerDesigner12.0
5.3 資料庫命名規則
表名以T開頭,外鍵以FK開頭,索引以INDEX開頭。
5.4 邏輯結構
pdm檔案的名稱為:《通用權限管理系統_資料庫模型》。
5.5 實體存儲
通過資料庫模組化工具PowerDesigner12可以将pdm導出為文本檔案,将資料庫腳本放入文本檔案中儲存。
5.6 資料備份和恢複
資料庫需定期備份(每天備份一次),備份檔案格式為backup_yyyyMMdd,資料庫被破壞時,利用最新的備份檔案進行恢複。
6. 系統出錯處理設計
6.1 出錯資訊
錯誤分類 | 子項及其編碼 | 錯誤名稱 | 錯誤代碼 | 備注 |
資料庫錯誤 | 連接配接 | 連接配接逾時 | 100001001 | |
連接配接斷開 | 100001002 | |||
資料庫本身錯誤代碼 | 資料庫本身錯誤代碼 | 100002+資料庫錯誤代碼 | ||
TCP連接配接錯誤 | 連接配接 | 連接配接逾時 | 101001001 | |
連接配接斷開 | 101001002 | |||
其它TCP連接配接錯誤(socket自身錯誤代碼) | 101002+ socket錯誤代碼 | |||
配置資訊錯誤 | 未配置輸入參數 | 102001 | ||
未配置輸出參數 | 102002 | |||
組管理部分自定義錯誤 | 103001——103999 | |||
角色管理部分自定義錯誤 | 104001——104999 | |||
使用者管理部分自定義錯誤 | 105001——105999 | |||
記錄檔管理 | 106001——106999 |
6.2 補救措施
為了當某些故障發生時,對系統進行及時的補救,提供如下補救措施:
a.後備技術 定期對資料庫資訊進行備份(每天一次),當資料庫因某種原因被破壞時,以最新的資料庫腳本進行恢複;。
7. 系統安全設計
7.1 資料傳輸安全性設計
SSH可以通過将聯機的封包加密的技術進行資料的傳遞; 使用SSH可以把傳輸的所有資料進行加密,即使有人截獲到資料也無法得到有用的資訊。同時資料經過壓縮,大大地加快了傳輸的速度。通過SSH的使用,可以確定資料傳輸比較安全并且傳輸效率較高。
7.2 應用系統安全性設計
操作人的操作資訊需要提供操作記錄。對系統的異常資訊需進行記錄,已備以後檢視。隻有授權使用者才能登入系統,對于某個操作,需要具有相應權限才能進行操作。
7.3 資料存儲安全性設計
對于使用者的密碼等敏感資訊采用MD5進行加密。