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

2021-09-06 07:27:33 字數 1531 閱讀 7485

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

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

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

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

使用者資訊表:

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的審核(就相當於是乙個欄目的責任編輯)。

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

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

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

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

基於角色的許可權設計 一

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