在任何系統中，許可權設計是最基礎的東西，本文給出乙個基於角色的許可權設計的循序漸進的設計方案。
在許可權系統中，功能（許可權）是最小的單位，比如起草新聞、編輯新聞、審核新聞、刪除新聞等，而角色是一類功能的集合，比如新聞編輯這個角色，他可能有起草新聞、編輯新聞等功能集合，而責任編輯他可能就有更多的許可權，比如除了新聞編輯的功能，還有審核新聞、刪除新聞等功能，給張三賦予新聞編輯的角色（其實我更願意說把張三加入到新聞編輯這個角色中去），張三就可以起草新聞、編輯新聞了，給李四賦予責任編輯的角色，李四就可以起草新聞、編輯新聞、審核新聞、刪除新聞了。
我們來看看版本一的解決方案：
我們來模擬一下上面的資料：
使用者資訊表：
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的審核（就相當於是乙個欄目的責任編輯）。
基於角色的許可權設計（一）
基於角色的許可權設計 一 在任何系統中，許可權設計是最基礎的東西，本文給出乙個基於角色的許可權設計的循序漸進的設計方案。在許可權系統中，功能 許可權 是最小的單位，比如起草新聞 編輯新聞 審核新聞 刪除新聞等，而角色是一類功能的集合，比如新聞編輯這個角色，他可能有起草新聞 編輯新聞等功能集合，而責任...
基於角色的許可權設計 一
在任何系統中，許可權設計是最基礎的東西，本文給出乙個基於角色的許可權設計的循序漸進的設計方案。在許可權系統中，功能 許可權 是最小的單位，比如起草新聞 編輯新聞 審核新聞 刪除新聞等，而角色是一類功能的集合，比如新聞編輯這個角色，他可能有起草新聞 編輯新聞等功能集合，而責任編輯他可能就有更多的許可權...
基於角色的許可權設計（一）
在任何系統中，許可權設計是最基礎的東西，本文給出乙個基於角色的許可權設計的循序漸進的設計方案。在許可權系統中，功能 許可權 是最小的單位，比如起草新聞 編輯新聞 審核新聞 刪除新聞等，而角色是一類功能的集合，比如新聞編輯這個角色，他可能有起草新聞 編輯新聞等功能集合，而責任編輯他可能就有更多的許可權...