權限管理系統的應用者應該有三種不同性質上的使用,
A,使用權限
B,分配權限
C,授權權限
本文只從《使用權限》和《分配權限》這兩種應用層面分析,暫時不考慮《授權權限》這種。
說到權限管理,首先應該想到,當然要設計一個用戶表,一個權限表。這樣就決定了一個人有什麼樣的權限。
做著做著就會發現這樣設計太過繁瑣,如果公司裡面所有員工都有這樣的權限呢,每一個人都要配置?那是一件很痛苦的事情。因此再添加一個角色表,把某些人歸為一類,然後再把權限分配給角色。角色屬下的用戶也就擁有了權限。
用戶、角色之間的關系是一個用戶可以對應多個角色,一個角色可以對應多個用戶。多對多關系。
所以需要一個中間表,相信大家都很熟悉,自然不會有疑問。
有了用戶和角色以後,就需要設計應用場景,比如一個應用程序有幾大模塊(系統模塊、項目管理模塊、銷售模塊),
類似這樣的模塊就是一種應用場景,常見的還有 菜單 、 操作 等等。
假設現在我們設計好了,應用場景包括 模塊、菜單、和操作,那麼應該有以下六種關系
於是建立六張表來維護這六種關系。
這樣設計看起來沒什麼問題。是的,如果沒有加入新的關系的話,這樣是已經可以滿足大部分的需求了。可是如果就是如果,新的關系(需求)往往會加入到系統進來。這個時候就需要再建立一個新的表。系統的復雜度也隨著增加。
可以看出,這樣的設計有幾個問題:
不同的應用場合,你可能會想出不同的需求,提了一個新的需求以後,可能會發現原來的設計沒方法實現了,於是還要添加一個新的表。這也是上面所提到的問題。
其實不必想得那麼復雜,權限可以簡單描述為:
某某主體 在 某某領域 有 某某權限
1,主體可以是用戶,可以是角色,也可以是一個部門
2, 領域可以是一個模塊,可以是一個頁面,也可以是頁面上的按鈕
3, 權限可以是“可見”,可以是“只讀”,也可以是“可用”(如按鈕可以點擊)
其實就是Who、What、How的問題
因此上面所提到的六張表其實可以設計一張表:
下面用一個例子做設計說明。“用戶、角色在頁面上的是使用權限”
詳細設計:
1,把菜單的配置放在數據庫上,每一個菜單對於一個唯一的編碼MenuNo,每一個“葉節點”的菜單項對於一個頁面(url)。
2,把按鈕的配置放在數據庫上,並歸屬於一個菜單項上(其實就是掛在某一個頁面上)。應該一個頁面可能會有幾個按鈕組,比如說有兩個列表,這兩個列表都需要有“增加、修改、刪除”。所以需要增加一個按鈕分組的字段來區分。
3,把菜單權限分配給用戶/角色,PrivilegeMaster為"User"或"Role",PrivilegeMasterValue為UserID或RoleID,PrivilegeAccess為“Menu",PrivilegeAccessValue為MenuNo,PrivilegeOperation為"enabled"
4,把按鈕權限分配給用戶/角色,PrivilegeMaster為"User"或"Role",PrivilegeMasterValue為UserID或RoleID,PrivilegeAccess為“Button",PrivilegeAccessValue為BtnID,PrivilegeOperation為"enabled"
5,如果需要禁止單個用戶的權限,PrivilegeOperation 設置為"disabled"。
如果不清楚的可以看下圖:
數據庫設計:
說了這麼多,其實我推薦的只是Privilege的表設計。這個表是who、what、how問題原型的設計。不僅擴展性、靈活性都很好,而且將復雜的權限管理系統濃縮成一句話。
而PrivilegeOperation不僅僅只是使用和禁止兩種,包括分配權限、授權權限,都可以用這個字段定義。只是這無疑加大了應用程序的設計難度,但是對於表設計可以不做出任何的修改就可以完成,可以看出其靈活性。
獲取【下載地址】 【集成shiro安全框架】javaEE 後台框架 SpringMVC Mybatis Shiro druid Bootstrap HTML5