本人在專案中關於使用者角色許可權的經驗

crycz發表於2009-10-28
》banq 我目前是把職務看成就是角色。
非常贊同職務就是角色這個說法
舉個現實中的例子：

一般公司：有總經理，部門經理，部門主管等等，這些是職務，對應角色。
總經理有炒人，籤合同職責，部門主管有審查簽到，這些是職責，對應許可權，職務包含很多職責，是職責的集合。
你進了一個公司，老闆說你是部門主管，你就知道你有哪些職責，能否炒人就看公司制度裡規定的部門主管有沒有炒人職責。
哪一天總經理出差，他出門說了一句：我出差這段時間你暫替一下我的工作。這句話的含義是他將總經理這個角色賦於你，
這段時間你可以炒人，籤專案合同，因為你有總經理角色，你是老大。他總不會說這段時間你可以炒人，籤合同，招人。。。

小公司：創業時就三個人，制度不完善，沒有這些職務，小張負責招人，小劉負責弄錢，小王負責專案。
這就將每一個使用者具體到職責了，就不存在職務（角色）的概念，所以小專案不需要角色。


我在這一口氣看了五個角色許可權的主題，從02，03年的文章看到09年
許可權角色的粗細真的是對不能系統而言，沒有通用的法則
我理解的概念是：（我在現有專案也是這樣做的）
使用者USER，是唯一的，體現在系統中登入id。
許可權privilege，是系統中定義好的function，固定有什麼，如：增，刪，改，查，稽核等
角色是許可權的集合，類似於公司的職務，如總經理
角色概念的使用不是必須的，但是經常會要有，
因為操作很多，不能直接將使用者和許可權關聯的。
使用者可以有組，角色可以有組
一個使用者可以有多個角色，但一次登入只有一個角色
開發部，市場部，是屬於組織結構範疇，通常表現為樹狀，有時也會網狀（網狀會比較複雜）

專案應用或舉例：
1：mysql的許可權控制，直接將使用者和許可權掛鉤，沒有角色的概念，因為他的許可權不多，只有增，刪，查，建立，drop。。。
表如下：
使用者 許可權 資源
user privilege table
2.oracle中是有角色概念的
3.角色的概念不是必須的，但為了方便賦於許可權，通常會有
舉例：總經理出差的舉例，他不會將他的職責全部列給你聽。
4.還有一點不知道哪一個貼子了，有人將功能和資源分開，說重用性比較大，如下：許可權（功能資源表）（多對多關聯表）
id 功能 資源
1 增 新聞
2 改 新聞
3 駁回 簡歷

角色許可權表
角色 功能許可權id
編輯 1
編輯 2
經理 1
經理 2
經理 3

但是這樣太細，使用者極有可能增加了一條 “4. 駁回 新聞”的許可權，顯然是錯誤的，你又是如何控制這條非法許可權的呢。
事實上，許可權就一列即可，系統定製的。
許可權表
id 功能許可權
1 增新聞
2 改新聞
3 駁回簡歷

角色許可權表同上（不用改），使用者需自定義角色時，只需將角色和許可權加到角色許可權表中即可。
這樣再將使用者和角色多對多關聯起來。

4. 至於開篇說的問題，市場部經理不能檢視和修改技術部的人員，這是屬於組織架構的問題，是資料過濾的許可權，也跟業務有關係了。
跟角色沒有必然聯絡。採用樹形過濾，就可以很好解決。

5. 至於還有人提出的包含排除的問題，角色許可權表設計成頭和明細的方式，更好，頭有角色，包含排除，明細有具體許可權。這樣可以減少大量資料和操作
例如：表頭
表Access
表頭id 角色 其他是否包含
1 總經理 是
2 編輯 否
表AccessLine
表頭id 功能許可權id 允許
1 1 否
2 1 是

這樣總經理只有all-1即除了“增新聞”的全部許可權。
編輯只具有0+1即只有“增新聞”的許可權


總之，使用者沒有直接跟許可權關聯（當然不是必須這樣設計），使用者與角色關聯，透過角色可以知道許可權。這樣角色可以複用，可以擴充套件，
操作簡易，至於角色的繼承是後一步具體實現的問題，還有使用者的組，角色的組，都是同理的。這樣才是一個比較好的解決方案。
我現在的專案就這樣做的，希望同道之人指出不妥之處。謝謝

本論壇中相關主題
http://www.jdon.com/jivejdon/thread/2897
http://www.jdon.com/jivejdon/thread/7309
http://www.jdon.com/jivejdon/thread/10122
http://www.jdon.com/jivejdon/thread/17652
http://www.jdon.com/jivejdon/thread/13450

[該貼被crycz於2009-10-28 13:33修改過]

相關文章