許可權在日常辦公系統中算是乙個比較常見的基本功能，對於存在有許可權模組的系統中規定了登入使用者能夠操作哪些資源，不能夠操作哪些資源。借助許可權模組可以有效的控制參與到系統不同身份人員要具體做的操作，可以說乙個成熟的後端系統離不開乙個比較完善的許可權管理系統。
rbac模型（role-based access control：基於角色的訪問控制）模型是比較早期提出的許可權實現模型，在多使用者計算機時期該思想即被提出，其中以美國george mason大學資訊保安技術實驗室（list）提出的rbac96模型最具有代表，並得到了普遍的公認。
rbac認為許可權授權的過程可以抽象地概括為：who是否可以對what進行how的訪問操作，並對這個邏輯表示式進行判斷是否為true的求解過程，也即是將許可權問題轉換為who、what、how的問題，who、what、how構成了訪問許可權三元組，具體的理論可以參考rbac96。
在rbac模型裡面，有3個基礎組成部分，分別是：使用者、角色和許可權
基本模型rbac0
rbac0是基礎，很多產品只需基於rbac0就可以搭建許可權模型了。在這個模型中，我們把許可權賦予角色，再把角色賦予使用者。使用者和角色，角色和許可權都是多對多的關係。使用者擁有的許可權等於他所有的角色持有許可權之和。
舉個栗子:
譬如我們做一款企業管理產品，如果按傳統許可權模型，給每乙個使用者賦予許可權則會非常麻煩，並且做不到批量修改使用者許可權。這時候，可以抽象出幾個角色，譬如銷售經理、財務經理、市場經理等，然後把許可權分配給這些角色，再把角色賦予使用者。這樣無論是分配許可權還是以後的修改許可權，只需要修改使用者和角色的關係，或角色和許可權的關係即可，更加靈活方便。此外，如果乙個使用者有多個角色，譬如王先生既負責銷售部也負責市場部，那麼可以給王先生賦予兩個角色，即銷售經理、市場經理，這樣他就擁有這兩個角色的所有許可權。
角色分層模型rbac1
rbac1建立在rbac0基礎之上，在角色中引入了繼承的概念。簡單理解就是，給角色可以分成幾個等級，每個等級許可權不同，從而實現更細粒度的許可權管理。
舉個栗子:
基於之前rbac0的例子，我們又發現乙個公司的銷售經理可能是分幾個等級的，譬如除了銷售經理，還有銷售副經理，而銷售副經理只有銷售經理的部分許可權。這時候，我們就可以採用rbac1的分級模型，把銷售經理這個角色分成多個等級，給銷售副經理賦予較低的等級即可。
角色限制模型rbac2
rbac2同樣建立在rbac0基礎之上，僅是對使用者、角色和許可權三者之間增加了一些限制。這些限制可以分成兩類，即靜態職責分離ssd(static separation of duty)和動態職責分離dsd(dynamic separation of duty)。具體限制如下圖：
[外鏈轉存失敗,源站可能有防盜煉機制,建議將儲存下來直接上傳(img-4p8n9dza-1607671635193)(
舉個栗子:
還是基於之前rbac0的例子，我們又發現有些角色之間是需要互斥的，譬如給乙個使用者分配了銷售經理的角色，就不能給他再賦予財務經理的角色了，否則他即可以錄入合同又能自己審核合同；再譬如，有些公司對角色的公升級十分看重，乙個銷售員要想公升級到銷售經理，必須先公升級到銷售主管，這時候就要採用先決條件限制了。
統一模型rbac3
rbac3是rbac1和rbac2的合集，所以rbac3既有角色分層，也包括可以增加各種限制。
[外鏈轉存失敗,源站可能有防盜煉機制,建議將儲存下來直接上傳(img-xwcytvnh-1607671635194)(
通過以上分析看到rbac存在四種模型，後面三種均在rbac0基礎模型延伸而來，這裡主要來考慮基礎模型rbac0表設計，有了基礎表結構後在其基礎之上進行公升級改造即可。
使用者-角色-資源實體間對應關係圖分析如下
這裡使用者與角色實體對應關係為多對多，角色與資源對應關係同樣為多對多關係，所以在實體設計上使用者與角色間增加使用者角色實體，將多對多的對應關係拆分為一對多，同理，角色與資源多對多對應關係拆分出中間實體物件許可權實體。
從上面實體對應關係分析，許可權表設計分為以下基本的五張表結構：使用者表(t_user)，角色表(t_role)，t_user_role(使用者角色表)，資源表(t_module)，許可權表(t_permission)，表結構關係如下：
[外鏈轉存失敗,源站可能有防盜煉機制,建議將儲存下來直接上傳(img-nkkc9j6p-1607671635197)(
t_user
使用者表字段
字段型別
字段限制
字段描述
主鍵id
int(11)
自增主鍵id
user_name
varchar(20)
非空使用者名稱
user_pwd
varchar(100)
非空使用者密碼
true_name
varchar(20)
可空真實姓名
varchar(30)
可空郵箱
phone
varchar(20)
可空**
is_valid
int(4)
可空有效狀態
create_date
datetime
可空建立時間
update_date
datetime
可空更新時間
t_role
角色表字段
字段型別
字段限制
字段描述
主鍵id
int(11)
自增主鍵id
role_name
varchar(20)
非空角色名
role_remarker
varchar(100)
可空角色備註
is_valid
int(4)
可空有效狀態
create_date
datetime
可空建立時間
update_date
datetime
可空更新時間
t_user_role
使用者角色表
欄位字段型別
字段限制
字段描述
主鍵id
int(11)
自增主鍵id
user_id
int(4)
非空使用者id
role_id
int(4)
角色id
角色id
create_date
datetime
可空建立時間
update_date
datetime
可空更新時間
t_module
資源表字段
字段型別
字段限制
字段描述
主鍵id
int(11)
自增資源id
module_name
varchar(20)
可空資源名
module_style
varchar(100)
可空資源樣式
urlvarchar(20)
可空資源url位址
parent_id
int(11)
非空上級資源id
parent_opt_value
varchar(20)
非空上級資源許可權碼
grade
int(11)
非空層級
opt_value
varchar(30)
可空許可權碼
orders
int(11)
非空排序號
is_valid
int(4)
可空有效狀態
create_date
datetime
可空建立時間
update_date
datetime
可空更新時間
t_permission
許可權表字段
字段型別
字段限制
字段描述
主鍵id
int(11)
自增主鍵id
role_id
int(11)
非空角色id
module_id
int(11)
非空資源id
acl_value
varchar(20)
非空許可權碼
create_date
datetime
可空建立時間
update_date
datetime
可空更新時間
從表結構設計可以看出：這裡有三張主表(t_user，t_role，t_module)，功能實現上這裡劃分為三大模組：
使用者管理
角色管理
資源管理基於rbac模型，還可以適當延展，使其更適合我們的產品。譬如增加使用者組概念，直接給使用者組分配角色，再把使用者加入使用者組。這樣使用者除了擁有自身的許可權外，還擁有了所屬使用者組的所有許可權。
舉個栗子:
譬如，我們可以把乙個部門看成乙個使用者組，如銷售部，財務部，再給這個部門直接賦予角色，使部門擁有部門許可權，這樣這個部門的所有使用者都有了部門許可權。使用者組概念可以更方便的給群體使用者授權，且不影響使用者本來就擁有的角色許可權。
在上海樂位元組學習的第十六天（持續更新中）
很多css3屬性 最初的預覽版沒有形成最終的正式版，但是瀏覽器為了對這些新屬性形成支援，主流瀏覽器提供屬於自己的語法規則 瀏覽器字首 webkit 谷歌 蘋果 瀏覽器字首 moz 火狐瀏覽器字首 ms ie瀏覽器字首 o 歐鵬瀏覽器 注 新增瀏覽器字首 相容模式 不新增瀏覽器字首 標準模式 1.漸變...
學習前端的第三十六天
嚴格模式的開啟方式 全域性嚴格 配合匿名函式 嚴格模式開啟之後的變更 宣告變數必須加關鍵字 var 不允許引數名重複 沒有明確隸屬物件的函式中的this 執行了 指向undefined arguments的內容不會被形參的改變而影響 arguments.callee被禁止使用 foreach map...
在上海樂位元組學習的的第六天（持續更新中）
今天是學習前端的第六天，主要學習內容為 圓角邊框 盒子陰影以及浮動。圓角邊框 我們可以使用border radius屬性來設定元素的外邊框圓角，其語法為 border radius length 引數可以為數值或是百分比的形式，該語法為複寫形式，其後可跟乙個值 四個圓角相同 兩個值 左上角和右下角為...