rbac（role-based access control，基於角色的訪問控制），就是使用者通過角色與許可權進行關聯。簡單地說，乙個使用者擁有若干角色，每乙個角色擁有若干許可權。這樣，就構造成「使用者-角色-許可權」的授權模型。在這種模型中，使用者與角色之間，角色與許可權之間，一般者是多對多的關係。（如下圖）
角色是什麼？可以理解為一定數量的許可權的集合，許可權的載體。例如：乙個論壇系統，「超級管理員」、「版主」都是角色。版主可管理版內的帖子、可管理版內的使用者等，這些是許可權。要給某個使用者授予這些許可權，不需要直接將許可權授予使用者，可將「版主」這個角色賦予該使用者。
當使用者的數量非常大時，要給系統每個使用者逐一授權（授角色），是件非常煩瑣的事情。這時，就需要給使用者分組，每個使用者組內有多個使用者。除了可給使用者授權外，還可以給使用者組授權。這樣一來，使用者擁有的所有許可權，就是使用者個人擁有的許可權與該使用者所在使用者組擁有的許可權之和。（下圖為使用者組、使用者與角色三者的關聯關係）
在應用系統中，許可權表現成什麼？對功能模組的操作，對上傳檔案的刪改，選單的訪問，甚至頁面上某個按鈕、某個的可見性控制，都可屬於許可權的範疇。有些許可權設計，會把功能操作作為一類，而把檔案、選單、頁面元素等作為另一類，這樣構成「使用者-角色-許可權-資源」的授權模型。而在做資料表建模時，可把功能操作和資源統一管理，也就是都直接與許可權表進行關聯，這樣可能更具便捷性和易擴充套件性。（見下圖）
請留意許可權表中有一列「許可權型別」，我們根據它的取值來區分是哪一類許可權，如「menu」表示選單的訪問許可權、「operation」表示功能模組的操作許可權、「file」表示檔案的修改許可權、「element」表示頁面元素的可見性控制等。
這樣設計的好處有二。其一，不需要區分哪些是許可權操作，哪些是資源，（實際上，有時候也不好區分，如選單，把它理解為資源呢還是功能模組許可權呢？）。其二，方便擴充套件，當系統要對新的東西進行許可權控制時，我只需要建立乙個新的關聯表「許可權xx關聯表」，並確定這類許可權的許可權型別字串。
這裡要注意的是，許可權表與許可權選單關聯表、許可權選單關聯表與選單表都是一對一的關係。（檔案、頁面許可權點、功能操作等同理）。也就是每新增乙個選單，就得同時往這三個表中各插入一條記錄。這樣，可以不需要許可權選單關聯表，讓許可權表與選單表直接關聯，此時，須在許可權表中新增一列用來儲存選單的id，許可權表通過「許可權型別」和這個id來區分是種型別下的哪條記錄。
到這裡，rbac許可權模型的擴充套件模型的完整設計圖如下：
rbac就是每個不同的人員擁有不同的角色，不同的角色可以看到不同的頁面
public function left()else
$info=implode(',',$data);
//例項化role表
$role=m('role');
$str=$role->join("role_privileges on role.rid=role_privileges.rid")
->join("privileges on role_privileges.pid=privileges.pid")
->where("role.rid in($info)")
->field("privileges.pid,privileges.pname,privileges.pcontroller,privileges.paction,privileges.p_fid")
->select();
if($str)else
$this->display();}}
關於亂碼的那點事
首先如果不編碼，那些非英文abc等字元會被瀏覽器按照網頁當前的字符集進行編碼傳到伺服器去，而伺服器則只會按照伺服器配置的字符集編碼 有預設的好像就是iso x 進行解碼，所以如果網頁的字符集和伺服器字符集解碼一致那麼就不會出亂碼！但是往往對於我們來說是不一致的。所以一般情況會出現亂碼，所以就有人想到...
關於樹的那點事。
突發奇想的想寫一些關於樹的用法，以後把經常用到的或者覺得重要的用法都給整理下來，好複習用。因為用得比較多的是二叉樹，所以先說一些二叉樹的性質 性質1 二叉樹第i層上的結點數目最多為2i 1 i 1 性質2 深度為k的二叉樹至多有2k 1個結點 k 1 性質3 包含n個結點的二叉樹的高度 k 至少為 ...
關於Json的那點事
說明 說明一點js是直接支援json的 所以可以直接如下寫 var a 直接是json物件 而不必 寫成 var a 這樣寫是字串 反而錯誤 所以 在.aspx 頁面輸出json的時候可以直接 前端 json格式當做回傳資料時請使用 jquery.getjson url,data callback ...