第一部分請參看:
針對這樣的需求,版本一就無能為力了(當然你也可以增加幾個功能:比如分類a的新聞起草和分類b的新聞起草,再把這個功能新增到相應的角色裡面去,但是這個應該不是我們要得解決方案吧,不過版本二也是基於這個思想來解決的)。
其實比新聞更好的例子是論壇板塊的版主。
下面是版本二的解決方案:
在版本二的功能表中加入了乙個resourcetype這個字段,這個字段用來表示對某個資源的分類(比如新聞),我們同樣來模擬一下(新聞分類a的resourcetype為:nta,分類b為:ntb):
功能表:
functionid
resourcetype
functionname f1
nta起草新聞:分類a f2
nta
f3 nta
審核新聞:分類a f4
nta刪除新聞:分類a f1
ntb起草新聞:分類b f2
ntb
f3 ntb
審核新聞:分類b f4
ntb刪除新聞:分類b
然後在角色表新增相應的角色,在角色功能表中新增對應的功能。
獲取functions的語句也相應地做變化:
select functionid +
『,』+ resourcetype from
角色功能表where roleid in (select roleid from
使用者角色表where userid=』u1』)
許可權的判斷也就變成:
functions.contain(『f1,nta』);
在新新增乙個分類的時候,同時也在功能表中增加相應的記錄(當然不是在資料庫裡面直接新增,由和功能相關的函式來新增)。
使用這種解決方案可以簡單地對有分類的應用(比如論壇系統)的每個分類實行不同的控制(比如vip板塊,就只能擁有vip角色的使用者才能瀏覽、發表等,而其他板塊只要是註冊使用者就可以使用了)。
在實際應用中functionid並不是隨便的乙個字串,而是進行了編碼,其編碼中包含了模組id以及能夠體現出父子關係,舉個例子來說:對於論壇系統,我們給它乙個模組id為」
30」,論壇的功能我們先分成2類,一類是管理類(比如刪除帖子),一類是使用類(比如發帖、回帖、瀏覽帖子等),給管理類乙個編碼:01,使用類乙個編碼:02,我們就對functionid進行如下的編碼:
300101:刪除帖子
300201:發帖
300202:回帖
300203:瀏覽帖子
對於資源(比如某個板塊1,板塊的id為:01),我們可以組合出如下的functions(當然這個組合你也可以不用逗號分隔,用其他的組合方式也可以,不過不要產生歧義):
300101,01:板塊1刪除帖子的功能
300201,01:板塊1發帖的功能 ……
對於roleid也是採用的編碼方式,也能體現角色的父子關係,也可以實現角色功能的繼承等(當然獲取角色功能列表的sql語句就不是現在這麼簡單了)。在我現在的應用裡面沒有實現角色的繼承(雖然角色的編碼體現出了角色的父子關係)。
許可權設計(二)
第一部分請參看 針對這樣的需求,版本一就無能為力了 當然你也可以增加幾個功能 比如分類 a的新聞起草和分類 b的新聞起草,再把這個功能新增到相應的角色裡面去,但是這個應該不是我們要得解決方案吧,不過版本二也是基於這個思想來解決的 其實比新聞更好的例子是論壇板塊的版主。下面是版本二的解決方案 在版本二...
基於角色的許可權設計(二)
針對這樣的需求,版本一就無能為力了 當然你也可以增加幾個功能 比如分類a的新聞起草和分類b的新聞起草,再把這個功能新增到相應的角色裡面去,但是這個應該不是我們要得解決方案吧,不過版本二也是基於這個思想來解決的 其實比新聞更好的例子是論壇板塊的版主。下面是版本二的解決方案 在版本二的功能表中加入了乙個...
常見模組設計 許可權管理(二)
許可權設計 基於角色的許可權設計 這種方案是最常見也是比較簡單的方案,不過通常有這種設計已經夠了,所以微軟就設計出這種方案的通用做法,這種方案對於每乙個操作不做控制,只是在程式中根據角色對是否具有操作的許可權進行控制 這裡我們就不做詳述 許可權設計 基於操作的許可權設計 這種模式下每乙個操作都在資料...