權限控制方案

* permission : 權限

ps : 自我感受寫的還算清楚,比較容易理解,不用框架,手動實現好像也...

一:粗粒度(URL級別權限控制)

• 用戶表(customer)

id	name
1	jim
2	tom

• 權限表(permission)

id	url
1	../../xxxQuery
2	../../xxxSave
3	../../xxxUpdate
4	../../xxxDelete

• 中間表customer_permission

c_id	p_id
1	1
1	2
1	3
1	4
2	1

• 能夠基於filter實現,當用戶訪問一個URL地址,查詢數據庫判斷用戶當前具備的權限是否包含這個URL,若是包含,容許訪問,若是不包含,則權限不足

二:細粒度(方法級別權限控制)

• 用戶表(customer)

id	name
1	jim
2	tom

• 權限表(permission)

id	desc
1	xxx_query
2	xxx_save
3	xxx_update
4	xxx_delete

• 中間表customer_permission

c_id	p_id
1	1
1	2
1	3
1	4
2	1

• 看着好像差很少,其實並非

@Permission("xxx_save")
save(){
     dao.save();
}

• 咱們經過在方法上添加自定義註解,這個註解能夠描述權限信息,當咱們要訪問目標對象的方法時,對目標對象建立代理對象,經過反射拿到權限描述,在代理對象中查詢數據庫判斷其是否具備註解上描述的權限,若是有該訪問權限,則訪問目標對象的方法,反之則攔截,並提示權限不足

三:權限控制常規模型(5張表)

(一)表結構

1. 用戶(User)

字段	類型	描述
id	Integer	主鍵
name	String	用戶姓名
...	...	其餘

2. 角色(role)

字段	類型	描述
id	Integer	主鍵
name	String	角色名稱
keyword	String	角色關鍵字，用於權限控制
description	String	描述

3. 用戶角色中間表(user_role)

字段	類型	描述
user_id	Integer	用戶ID
role_id	Integer	角色ID

4. 權限(permission)

字段	類型	描述
id	Integer	主鍵
name	String	權限名稱
keyword	String	權限關鍵字，用於權限控制
description	String	描述

5. 角色權限中間表(role_permission)

字段	類型	描述
role_id	Integer	角色ID
permission_id	Integer	權限ID

(二)簡單聊一下角色表

• 咱們發現這五張表(三張主表)是以角色爲中心分別以多對多的形式關聯用戶和權限,而不是由用戶和權限直接關聯,這並非說用戶和權限直接關聯不能夠,只是爲了方便咱們對用戶進行受權
• 打個比方:陸軍上將能夠管陸軍,空軍上將能夠管空軍,海軍上將能夠管海軍,若是你是陸海空三軍上將,是否是什麼兵均可以管了呢?
• 也就是說,咱們爲用戶分配角色,爲角色分配權限,從而達到爲用戶分配權限的目的,角色的存在就是爲了方便對用戶受權也能夠理解爲,角色就是權限的集合

(三)補充:動態菜單管理

• 在後臺管理系統中,咱們一般須要進行動態菜單管理,即爲不一樣的用戶指定不一樣的系統菜單
• 菜單表(menu)

字段	類型	描述
id	Integer	主鍵
name	String	菜單名稱
page	String	訪問路徑
priority	Integer	優先級
description	String	描述

• 咱們仍然不直接和用戶關聯,那樣太累了,咱們選擇經過角色進行管理(其實就是粗粒度url控制)
• 角色菜單表(role_menu)

字段	類型	描述
role_id	Integer	角色ID
menu_id	Integer	菜單ID