權限系統表設計探討

場景:

A用戶只能訪問 a b c資源 B用戶只能訪問abc資源 C用戶只能訪問abcde資源

最初的選擇

最簡單的權限設計 user 表  privilege表
然後再建一個user_privilege表 把 Aa Ab Ac ....對應起來.

優點:直觀簡單
缺點:脫離生活實際,生活中不可能每個人的權限不一樣.肯定大多數人的權限是一個樣的.就比如AB.所以這樣設計造成了數據庫的冗餘.

權限5表:

既然AB的權限一樣,那麼是有相同身份地位的人才有可能有相同的權限,也就是我們生活中角色的概念.

• user
• role
• privilege
• user_role
• role_privilege

我們舉個實際的例子.比如人員管理的一些權限.
新增人員 查看人員列表 查看人員詳細信息 審批請假三個權限

人事主管    新增人員
           查看人員列表
           查看人員詳細信息
           審批請假

人事專員    新增人員
           查看人員列表
           查看人員詳細信息

那麼我們來看,其實在這裏的體現就是部門+職位來判斷角色

繼續擴張:

• dept 比如銷售 研發等
• postion 比如 經理 副經理 總經理 總監 一般員工等
• user 關聯到dept postion
• role 關聯到 dept postion
• privilege
• role_privilege

權限表如果一旦角色一旦擁有了人員管理的新增操作.那麼肯定應該可以有查看的權限,而且不僅可以查看列表,還可以查看詳情,所以權限大類無非增刪改查.所以可以減少privilege中數據的量只需要人員管理的權限一條記錄而在role_privilege中還需要新增4個字段來記錄是否有增刪改查的權限.

再演變:

如果新增一個功能,但是這個功能只能對某些個人開放.這部分人並不遵循常規的dept與postion來定義角色.
所以還是需要user_role這張表來處理.哪些並不是有dept與postion來決定的角色.

web如何做權限控制

1. ###展示的權限控制

1.1 菜單的展示(jsp過濾掉)
1.2 超鏈接與按鈕的展示(jsp過濾掉,或者通過對按鈕增加attr,然後返回html頁面時攔截.判斷attr.再做處理.)
1.3 字段的展示不展示(後臺邏輯代碼控制)

1. ###後臺權限嚴格控制

2.1 url的訪問權限控制(spring可以通過註解配置來實現)
2.2 內部方法互相調用的權限控制(spring的註解.當調用領一個有權限註解的方法時候.需要再驗證一次)
2.3 代碼內部業務權限(根據不同權限做不同的業務事情.比如)

WEB具體實現:

1.class的control中增加
@Controller
@RequestMapping("/user")
public class UserController{
    //方法add中增加
    @privilege(code="user.add")
    @RequestMapping(value = "/add", method = RequestMethod.GET)
    @ResponseBody
    public User add(){} 
}
所以出現了三個對應關係
方法   請求url   權限碼

2.menu增加權限控制
在menu表中直接增加一個權限碼column

3.頁面按鈕增加權限控制
<button value="新增" privilegeCode="user.add"></button>

如果什麼不明白的地方,或者什麼問題.私信我.