基於角色的許可權設計

2021-06-07 17:17:27 字數 3009 閱讀 5756

基於角色的許可權設計(一)

在任何系統中,許可權設計是最基礎的東西,本文給出乙個基於角色的許可權設計的循序漸進的設計方案。

在許可權系統中,功能(許可權)是最小的單位,比如起草新聞、編輯新聞、審核新聞、刪除新聞等,而角色是一類功能的集合,比如新聞編輯這個角色,他可能有起草新聞、編輯新聞等功能集合,而責任編輯他可能就有更多的許可權,比如除了新聞編輯的功能,還有審核新聞、刪除新聞等功能,給張三賦予新聞編輯的角色(其實我更願意說把張三加入到新聞編輯這個角色中去),張三就可以起草新聞、編輯新聞了,給李四賦予責任編輯的角色,李四就可以起草新聞、編輯新聞、審核新聞、刪除新聞了。

我們來看看版本一的解決方案:

我們來模擬一下上面的資料:

使用者資訊表:

userid

username

u1 張三

u2 李四

角色表:

roleid

rolename

r1 新聞編輯

r2 責任編輯

角色使用者表:

roleid

userid

r1 u1

r2 u2

功能表:

functionid

functionname

f1 起草新聞

f2 編輯新聞

f3 審核新聞

f4 刪除新聞

角色功能表:

roleid

functionid

r1 f1

r1 f2

r2 f1

r2 f2

r2 f3

r2 f4

我們來看看如何判斷乙個使用者具有某個功能許可權:

首先在使用者張三登入的時候,獲取張三的全部功能列表:

select functionid from 角色功能表 where roleid in (select roleid from 使用者角色表 where userid=』u1』)

這樣就可以得到張三的全部功能列表functions,在起草新聞的頁面我們就可以做如下判斷:

functions.contain(『f1』);//當然你可以把這個』f1』定義成乙個常量:newsfunction.draft

如果為true就說明張三有起草新聞的許可權。

當然對於web應用,您可以把functions 用session儲存起來,以避免每開啟乙個頁面都去資料庫中獲取。

似乎看起來是乙個不錯的解決方案。

還是新聞系統,最初新聞系統沒有分類,但是隨著新聞的增加,沒有分類的新聞看起來總是亂的,於是張三和李四給新聞新增了分類a、分類b,還是由張三負責起草,李四負責審核,以後又新增了更多的分類,並且也增加了人手,這個時候就有新的要求出來了:希望張三隻負責分類a的起草,分類b的起草交給其他人做,李四呢也只負責分類a的審核(就相當於是乙個欄目的責任編輯)。

許可權設計(二)

樣的需求,版本一就無能為力了(當然你也可以增加幾個功能:比如分類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語句就不是現在這麼簡單了)。在我現在的應用裡面沒有實現角色的繼承(雖然角色的編碼體現出了角色的父子關係)。

基於角色的許可權設計

在任何系統中,許可權設計是最基礎的東西,本文給出乙個基於角色的許可權設計的循序漸進的設計方案。在許可權系統中,功能 許可權 是最小的單位,比如起草新聞 編輯新聞 審核新聞 刪除新聞等,而角色是一類功能的集合,比如新聞編輯這個角色,他可能有起草新聞 編輯新聞等功能集合,而責任編輯他可能就有更多的許可權...

基於角色的許可權設計

基於角色的許可權設計 一 在任何系統中,許可權設計是最基礎的東西,本文給出乙個基於角色的許可權設計的循序漸進的設計方案。在許可權系統中,功能 許可權 是最小的單位,比如起草新聞 編輯新聞 審核新聞 刪除新聞等,而角色是一類功能的集合,比如新聞編輯這個角色,他可能有起草新聞 編輯新聞等功能集合,而責任...

基於角色的許可權設計(一)

基於角色的許可權設計 一 在任何系統中,許可權設計是最基礎的東西,本文給出乙個基於角色的許可權設計的循序漸進的設計方案。在許可權系統中,功能 許可權 是最小的單位,比如起草新聞 編輯新聞 審核新聞 刪除新聞等,而角色是一類功能的集合,比如新聞編輯這個角色,他可能有起草新聞 編輯新聞等功能集合,而責任...