基於 rbac（role-based access control）許可權訪問控制。也就是說乙個使用者可以有多個角色，乙個角色可以有多個許可權，通過將角色和許可權分離開來提高設計的可擴充套件性，通常乙個使用者有多個角色，乙個角色也會屬於多個使用者（多對多），乙個角色有多個許可權，乙個許可權也會屬於多個角色（多對多）。
2.最簡單版本
假設：我們拿到乙個使用者物件，
可以通過：使用者id –>角色id–>角色名稱（什麼角色）–>許可權id –> 許可權標識 –>獲取許可權。最終獲取許可權獲取角色資訊。
角色：可以簡單理解為許多許可權的集合。比如二級管理員，**管理員。
3.使用者組模式
如果使用者數量比較龐大，可以加入使用者組模式。需要給使用者分組，每個使用者組內有多個使用者，可以給使用者授權外，也可以給使用者組授權。終端使用者擁有的所有許可權 = 使用者個人擁有的許可權+該使用者所在使用者組擁有的許可權。（這個設計類似 svn 中的使用者許可權，比如，將乙個svn使用者加入到 group中，然後設定group的許可權，以後加入更多的使用者，就不用再一一設定使用者的許可權了。）
4.許可權分類
大部分是針對功能模組，比如對資訊記錄的增刪改（資訊狀態修改，檔案的刪除修改等），選單的訪問，輸入框，按鈕的可見性，是否可以新增下級管理員等。有些許可權設計，會把功能操作作為一類，而把檔案、選單、頁面元素等作為另一類，這樣構成「使用者-角色-許可權-資源」的授權模型。而在做資料表建模時，可把功能操作和資源統一管理，也就是都直接與許可權表進行關聯，這樣可能更具便捷性和易擴充套件性。
5.完整版
請留意許可權表中有一列「許可權型別」，我們根據它的取值來區分是哪一類許可權，如「menu」表示選單的訪問許可權、「operation」表示功能模組的操作許可權、「file」表示檔案的修改許可權、「element」表示頁面元素的可見性控制等。
優點：（1）不需要區分哪些是許可權操作，哪些是資源，（實際上，有時候也不好區分，如選單，把它理解為資源呢還是功能模組許可權呢？）。
（2）方便擴充套件，當系統要對新的東西進行許可權控制時，我只需要建立乙個新的關聯表「許可權xx關聯表」，並確定這類許可權的許可權型別字串。
這裡要注意的是，許可權表與許可權選單關聯表、許可權選單關聯表與選單表都是一對一的關係。（檔案、頁面許可權點、功能操作等同理）。也就是每新增乙個選單，就得同時往這三個表中各插入一條記錄。這樣，可以不需要許可權選單關聯表，讓許可權表與選單表直接關聯，此時，須在許可權表中新增一列用來儲存選單的id，許可權表通過「許可權型別」和這個id來區分是種型別下的哪條記錄。
使用者 許可權 使用者組 角色
使用者是系統的操作人員。使用者組和角色都是乙個許可權的集合。使用者組是縱向的資料許可權定義，你屬於某乙個使用者組才可以檢視相關的資料。角色是橫向的功能許可權定義，你是某個角色才能做某些操作。使用者組和角色的交集確定許可權。用乙個簡單的例子來說明他們之間的聯絡。乙個公司包含業務部 人力資源部 財務部三...
使用者 組 許可權
使用者 組 許可權 一 許可權 r,w,x 1.檔案許可權 r 可讀，可以使用類似cat等命令檢視檔案內容 w 可寫，可以編輯或刪除此檔案 x 可執行，exacutable，可以命令提示符下當作命令提交給核心執行 2.目錄許可權 r 可以對此目錄執行ls以列出內部的所有檔案 w 可以在此目錄建立檔案...
使用者組許可權
使用者user linux使用者 username uid 管理員 root，0 普通使用者 1 65535 組group 使用者和組的配置檔案 linux使用者和組的主要配置檔案 etc passwd 使用者及其屬性資訊 名稱 uid 駐足id等 etc group 組及其屬性資訊 etc sha...