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