使用者許可權管理設計
使用者管理許可權設計一直是大家討論的熱點，因為幾乎涉及到每乙個開發的業務系統。我找了很多很多的資料，大家的核心基本上都是一樣的:基於角色管理. 使用者，角色，模組，許可權的相互組合，就可以形成乙個強大的許可權管理系統。
最近在乙個專案中設計的乙個使用者許可權的設計，很樂意與大家一起討論及分享.
設計思路
我的設計思路或者說是我想要實現的功能
1.使用者的許可權通過角色來控制,乙個使用者可以擁有多個角色.
2.使用者擁有不同角色時，其許可權應該是多個角色相互的補集.
3.乙個角色擁有多個模組
4.使用者的前台選單顯示根據角色所擁有的模組所決定，不同的使用者在前端顯示的操作選單是不一樣的。
5.頁面中的功能按鈕根據模組中所包含的功能所定義，通過模組及角色所擁有的許可權進行控制
6.可看某個模組有哪些使用者，哪些對應角色,並對其進行特殊許可權設定.
7.可以針對單個使用者進行特殊設定
我在我的project中，基本上達到了以上的效果及功能，但在實際過程中發現有些不足之處。因為整個許可權設計是基於資料庫來設計中，所以資料的讀取當資料量大時（我所說的資料量是以萬以上來計）可能對效能有一定的影響。但對於一般來說，幾千使用者之類的我想還是可以承受的。我會在後面說明不足之處。
資料庫設計
基本設計：
1.首先,設計資料庫.
資料庫的設計其實我估計大家都很熟悉了
基本表：使用者表，角色表，模組表，功能表,管理員表.如果涉及到企業性質的，可能會根據需要加上組織結構表，群組表等其它輔助表
使用者管理員
角色模組(我的模組表考慮了子模組的因素,所以會有深度，父模組id這兩個字段，在後來開發過中，由於思路的轉變,isrootmodule,functioncode我都沒有用到,為了讓整個許可權系統通變得更通用，我都將其單獨設計成了另乙個表）
功能表（功能表就是模組對應的功能：增加，刪除，修改，詳細，列表，瀏覽，匯出，匯入之類的）
業務表：使用者-角色表 模組-功能表 角色-模組表
要實現乙個使用者多個角色(1 to n),乙個角色多個模組(1 to n),乙個模組多個功能(1 to n)，那就得加上幾個相關的業務表，之前考慮用檢視去實現，我個人之見,檢視最好只用來讀取資料，不要用來進行資料操作.後來證明是不可取的，這裡要注意的就是在實際的業務操作中，應該盡量避免重複的資料錄入. 這些表都很簡單，但卻很關鍵
使用者-角色:
角色-模組：
模組-功能:
大家可以看到，表結構很簡單，欄位也很少，設計也差不多。都是將相關聯的字段id取出來做資料訪問。
檢視：使用者-角色-模組-功能檢視
可能大家會覺得很奇怪，為什麼這裡出現member_role呢。因為我們在資料表中只訪問了id值，而對應的rolename欄位並沒有包含其中，這裡的檢視就是獲取關聯表中其他所需要的字段資料了。另外兩個檢視大家看名字應該就知道他的用處了。
儲存過程：各自表的增加，刪除，修改，及列表資料. 判斷是否存在相同的資料
（cudlis-create, update,delete,ifexist,show,list)
儲存過程我就不一一列出了，很簡單的，你只要寫出下面這些基本上你在開發過程就不會有太多問題了. 注意的是：在相互關聯的業務表中，最好能對資料插入進行重複資料判斷（使用者角色表，模組功能表，角色模組表，盡量避免重複的資料插入）我把大致需要實現的業務列個表給大家參考:
使用者表:(insert ,update ,ifexist ,show, delete)
使用者角色表:(insert ,update,ifexist,delete,rolelistbyuserid,userlistbyroleid)
角色表:(insert,update,ifexist,show,delete)
角色模組表:(insert,ifexist,delete,show,rolelistbymoduleid,modulistbyroleid)
模組表:(insert,update,ifexist,show,dlete,listbyrootmoduleid,listbymodulelevel)
模組功能表:(insert,update,delete,functionlistbymoduleid)
針對使用者直接獲取其所有的許可權時，應該有個單獨的procedure從檢視中member_role_module_function中獲取其對應的資料，這樣就可以得到想要的東西了。
資料庫設計部分應該就這樣差不多了。我想這應該是通用的。在實際運用過程中，我個人認為應該有一些改進點：
1.模組與功能部分，可以用字串的形式將模組對應的功能存在乙個資料字段中，這樣可能在你的**編寫中可以省下較多的時間並帶來更多的便利（主要是可以用split()來代替頻繁的資料獲取業務）這個我在最初設計中沒有想到這點，有點失策.
2.針對n級模組的許可權展現問題，如何讓父模組繼承子模組的許可權這個是我沒有考慮到的，不過我想應該可以用isrootmodule這個欄位來作文章，可惜我還沒想到如何去整這個字段。當子模組很多時，在前端ui展示的時候是否會出現很慢的情況？這個我沒有去做測試，帶有一定的風險。
但在前端ui展示我還沒想到或實現好的辦法，我能想到的應該是像gridviewtree那種不錯。
這個許可權設計已經在我的project中運用，暫時沒有發現什麼問題，而且為我以後對其它系統整合也很有幫助。至於如何在c#中實現業務，個人認為只要知道資料庫如何整的，那c#中的業務實現只是乙個取數操作過程。
rbac許可權管理設計 RBAC使用者角色許可權設計方案
rbac role based access control，基於角色的訪問控制 就是使用者通過角色與許可權進行關聯。簡單地說，乙個使用者擁有若干角色，每乙個角色擁有若干許可權。這樣，就構造成 使用者 角色 許可權 的授權模型。在這種模型中，使用者與角色之間，角色與許可權之間，一般者是多對多的關係。...
使用者許可權管理
1.2 使用者許可權管理 可以執行以下命令完成解除安裝 chmod 777 r sh 1.3.0 cd sh 1.3.0 uninstall.sh linux 系統中三種基本許可權 使用者屬主 使用者屬組及其它人許可權 rw r r 1 root root 762 11 11 20 34 a.out...
PHP之後臺使用者許可權管理設計
關於許可權管理資料庫需要用到多少張表這個問題，網上有的說是建立六張表，有的說建立五張表，其實大同小異，根據你自己設計的表字段。不過建立五張表 使用者表，角色表，許可權表 即後來的選單表 使用者角色表，許可權角色表。是最容易讓新人理解的。我是建立了四張表。使用者表 我把後面的使用者角色表整合到乙個使用...