勿以惡小而爲之，勿以善小而不爲--------------------------劉備

勸諸君，多行善事積福報，莫作惡

一. 權限管理

一.一什麼是權限管理?

權限，簡單理解就是功能，你是否具有某個權限，即你是否具有某個功能.

如，用戶兩個蝴蝶飛具有部門刪除的權限，那麼就可以說用戶兩個蝴蝶飛具有部門刪除的功能。

用戶嶽澤霖不具有部門刪除的權限,那麼就可以說用戶嶽澤霖不具有部門刪除的功能。

你具有某些權限，你就可以幹某些事情。

一.二. 爲什麼要進行權限控制?

生活和開發中進行權限管理，主要是爲了安全，保護數據。

現在的系統，無論是電腦，手機，Ipad, 網站，都支持多用戶登錄的情況，如老蝴蝶電腦上有兩個蝴蝶飛和嶽澤霖兩個用戶，那麼當我以兩個蝴蝶飛這個用戶登錄時，是不能看到嶽澤霖用戶裏面的相應信息的，同樣，以嶽澤霖這個身份登錄時，也不能看到兩個蝴蝶飛用戶裏面的相應信息，這樣就保護了用戶的隱私性，保障了數據的基本的安全。

就像在公司中，總裁下面有人事經理，財務經理，人事經理下面有兩個人事專員，財務經理下面也有兩個人事專員，

還有一個普通的小用戶，你。

那麼很顯然，總裁具有該公司所有的權限，可以進行登錄，可以查看自己的個人信息，也可以查看公司的報表統計，而人事經理只能看人員信息，用戶考勤等功能，是不能看到財務部相關的功能的。同時，人事部裏面人事經理的權限和人事專員的權限也可能是不一樣的，人事經理的權限要稍微大一些，人事專員的權限相對小一些。而你，一個普通的小用戶，是沒有辦法看到公司的人員信息，考勤信息的，更無法看到財務信息的，只能進行簡單的登錄，修改個人信息等功能。如果你能看見公司人事經理的功能，或者財務經理的功能，那麼很顯然，對於個人和公司來說，都是非常不安全的，所以需要進行權限控制。

一.三. 開發中常見的權限控制

實際開發中，有着很複雜的權限控制，需要授權申請，同意授權，移除授權申請，同意移除授權，暫時授權等。

我們平常開發中，遇到的權限控制有:

登錄認證。如果用戶沒有登錄，則不能進行操作，必須先進行登錄。如查看用戶的信息等。
權限授權。如果用戶沒有相應的權限，則不能進行相應的操作。如，用戶兩個蝴蝶飛只有部門刪除的權限，沒有部門添加的權限，那麼則只能進行刪除，不能進行添加。

然而，在進行權限管理時，還需要保證以下幾點:

對於跳轉到登錄頁面，登錄，註冊，靜態頁面等內容，是不需要進行認證操作的，可以直接訪問。
當用戶沒有登錄時，直接輸入相應的網址，即使用戶擁有此網址對應的功能，也無法進行操作，需要跳轉到登錄頁面，先進行登錄。
對於用戶已經登錄的，直接輸入相應的網址，如果用戶不具有些網址對應的功能，無法進行操作，顯示給用戶權限不足的提示。
對於不具有某些功能的頁面元素，如沒有部門添加的功能，那麼部門視圖裏面，對該用戶來說，不能展示部門添加的按鈕。
對於已經退出系統的用戶來說，直接輸入相應的網址，也需要先進行登錄。

權限控制，包括表級別的權限控制和數據級別的權限控制。常見的菜單，按鈕屬於表級別的權限控制。

數據級別的權限，指用戶A和用戶B都具有查詢員工檔案的權限，但用戶A是總裁，那麼用戶A可以查看所有的員工檔案信息，用戶B是部門經理，那麼只能查看該部門下的所有的員工信息，也可以有一個員工C 人事經理，可以查看當前在職的所有的員工檔案。同樣都是員工檔案的查看權限，由於身份不同，能夠查看的數據結果不同。這就是數據級別的權限。

數據級別的權限，通常需要業務邏輯處理，即在業務代碼中，進行相應的判斷，如果是總裁，執行總裁查詢的sql語句，如果是部門經理，執行部門經理查詢的sql語句。

二. RBAC 實現權限管理

二.一原始的權限管理

以前在開發權限管理時，用戶具有某些權限，直接創建一個用戶表，一個權限表，還有一個用戶權限表。用戶表裏面放置的是用戶信息，權限表裏面放置權限的信息，包括菜單權限和按鈕權限，用戶權限表是用戶表和權限表的中間表，用於存放用戶的權限信息。

當查看某個員工的權限時，直接去用戶權限表裏面，通過用戶的id 進行查詢權限。

這對於非常簡單的項目來說，是沒有太大的問題，可當用戶過多時，系統權限過多時，將會出現一些問題。

數據多。每一個用戶，都會往用戶權限表裏面放置數據，如果放滿，則是用戶總量*權限總量。如果用戶A具有權限編號爲 1~10的權限，用戶B 具有權限編號爲 2~11的權限，則需要將2~10 這九個權限重複2次，無法提取出來。
查詢效率低。查詢員工的權限時，需要遍歷整個表的記錄。
後期維護成本大。當新進來一個員工時，需要給其一個個配置權限，部門的刪除和查看權限，員工的查看權限，容易出現錯誤，可能出現少添加，多添加，或者錯誤配置權限。當員工離職時，需要給其一個個移除權限，部門的刪除和查看權限，員工的查看權限，也容易出現錯誤。很考驗配置權限的那個員工的眼睛和細心程度的。
當新添加一個權限時，給對應的員工配置，需要找到員工，一個個進行配置。配置的過程，枯燥，容易出現遺漏。

這裏，員工與權限，是直接相連的。

我們希望，在員工與權限的中間，有一個新的實體，做到員工連接新實體，新實體連接權限，員工與權限變成了間接相連，這樣就很大程序地避免上面的問題了。這個新實體，就是角色。

通過角色來控制權限，就是 RBAC.

二.二 RBAC

二.二.一 RBAC的簡單解釋

RBAC,全稱是(Role-Based Access Control), 基於角色的訪問控制。

用戶連接角色，角色連接權限，想知道某一個用戶的權限，只需要查詢出該用戶的所有的角色，然後將每一個角色的權限找出來然後進行合併即可。

如果用戶A 具有1_{10的權限，用戶B具有2}11的權限，那麼只需要將2~10的權限提取出來，創建一個角色2_10, 角色2_10裏面放置權限2,權限3…權限10, 用戶A連接角色2_10, 那麼用戶A就具有權限2,權限3 … 權限10了。

當新添加一個員工時，只需要把這個員工與角色關聯起來，新員工就可以擁有一些權限了。當移除一個員工時，只需要把員工與角色進行斷開關聯，就可以取消該員工的權限，不需要再像以前那樣再操作權限信息了。

流程圖表示爲:

該圖片引用於: RBAC權限管理 https://www.jianshu.com/p/44bfd8d6184b

二.二.二 RBAC的表設計

數據表表示爲:

二.二.二.一用戶表 user

CREATE TABLE `user` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '員工id',
  `code` varchar(20) DEFAULT NULL COMMENT '員工編號',
  `name` varchar(30) DEFAULT NULL COMMENT '員工姓名',
  `password` varchar(128) DEFAULT NULL COMMENT '密碼',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8;

二.二.二.二角色表 role

CREATE TABLE `role` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '角色id',
  `name` varchar(50) DEFAULT NULL COMMENT '角色名稱',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8;

二.二.二.三用戶角色關聯表 user_role

CREATE TABLE `user_role` (
  `uid` int(11) NOT NULL COMMENT '員工編號',
  `rid` int(11) NOT NULL COMMENT '角色編號',
  `create_by` int(11) DEFAULT NULL COMMENT '創建人',
  `create_date` date DEFAULT NULL COMMENT '創建時間',
  PRIMARY KEY (`uid`,`rid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

二.二.二.四權限表 privilege

CREATE TABLE `privilege` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(50) DEFAULT NULL COMMENT '權限名稱',
  `url` varchar(128) DEFAULT NULL COMMENT '權限的地址',
  `type` int(1) DEFAULT NULL COMMENT '類型,1是菜單，2是按鈕',
  `orderNum` int(2) DEFAULT NULL COMMENT '排序，同一級別下的排序',
  `percode` varchar(30) DEFAULT NULL COMMENT '按鈕權限的標識',
  `icon` varchar(128) DEFAULT NULL COMMENT '權限的圖標',
  `pid` int(11) DEFAULT NULL COMMENT '上級權限編號',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=15 DEFAULT CHARSET=utf8;

二.二.二.五角色權限表 role_privilege

CREATE TABLE `role_privilege` (
  `rid` int(11) NOT NULL COMMENT '角色編號',
  `pid` int(11) NOT NULL COMMENT '權限編號',
  `create_by` int(11) DEFAULT NULL COMMENT '操作人',
  `create_date` date DEFAULT NULL COMMENT '操作人',
  PRIMARY KEY (`rid`,`pid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

這就是基於 RBAC 的簡單五個表的內容。

二.三四種模型 RBAC0,RBAC1,RBAC2,RBAC3

二.三.一 RBAC0 模型

RBAC0, 是RBAC的五個核心表，就是上面那五個表。

二.三.二 RBAC1 模型

RBAC1 對 RBAC0 進行了擴展，引入了角色繼承的概念，角色具有上下級了。

此時的角色表 role 表

CREATE TABLE `role` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '角色id',
  `name` varchar(50) DEFAULT NULL COMMENT '角色名稱',
  `rpId` int(11) DEFAULT NULL COMMENT '上級角色編號',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8;

角色一般員工的編號爲1，人事經理的角色編號爲2，它的上級角色編號爲1，總裁的角色編號爲3，它的上級角色編號爲1，

一般員工具有修改個人信息，查看個人檔案的權限，

那麼人事經理也想需要這兩個權限，這個時候，不需要配置人事經理的角色與修改個人信息，查看個人檔案的權限關聯，只需要讓人事經理的角色繼承一般員工即可。

要想總裁也具有這兩個權限，只需要總裁繼承一般員工這個角色即可。

某一個員工，所具有的權限，就是該員工對應的每一個角色和所有父級角色的權限總和。

二.三.三 RBAC2 模型

角色與角色之間，可能存在衝突，如出納和會計，運動員和裁判。一個員工是不能既是出納，又是會計（你懂得），運行員不能既是運行員，又是裁判。

需要對不同的角色之間，進行職責分離。

職責分離，有兩種形式，第一種是靜態職責分離，第二種是動態職責分離。

二.三.三.一靜態職責分離

靜態職責分離，是指用戶無法同時賦予有衝突的角色。如果員工已經有了出納的角色，那麼在給該員工配置會計角色時，會提示角色有衝突，不讓配置。這個是在配置角色時，進行校驗。無論角色之間是否繼承，都需要進行校驗。

二.三.三.二動態職責分離

動態職責分離，是指用戶在一次會話(Session)中，不能同時激活自身所擁有的，互相沖突的角色，只能選擇其一。當用戶登錄時，或者登錄成功後，會讓用戶選擇角色，如用戶選擇了出納的角色。在運行會話期間，該用戶是無法選擇會計的角色進行操作的，只能先退出，再重新登錄。這個是在運行中，動態地選擇的。注意，這種模式在配置角色時，是可以配置成功的。

二.三.四 RBAC3 模型

RBAC3就是 RBAC1+RBAC2。

角色需要繼承，同時也要進行職責分離。

一般開發中，我們只選擇 RBAC0 模型即可。

三. RBAC 權限管理的完整表結構

完整的 RBAC 權限表結構，可以看 RBAC權限管理 https://blog.csdn.net/painsonline/article/details/7183613/

具有，用戶，用戶組，角色，權限，權限菜單，權限元素，權限文件，權限等主要表信息。

謝謝您的觀看!!!

RBAC權限（一）

一. 權限管理

一.一什麼是權限管理?

一.二. 爲什麼要進行權限控制?

一.三. 開發中常見的權限控制

二. RBAC 實現權限管理

二.一原始的權限管理

二.二 RBAC

二.二.一 RBAC的簡單解釋

二.二.二 RBAC的表設計

二.二.二.一用戶表 user

二.二.二.二角色表 role

二.二.二.三用戶角色關聯表 user_role

二.二.二.四權限表 privilege

二.二.二.五角色權限表 role_privilege

二.三四種模型 RBAC0,RBAC1,RBAC2,RBAC3

二.三.一 RBAC0 模型

二.三.二 RBAC1 模型

二.三.三 RBAC2 模型

二.三.三.一靜態職責分離

二.三.三.二動態職責分離

二.三.四 RBAC3 模型

三. RBAC 權限管理的完整表結構

Java的自帶註解Annotation(一)

自定義Annotation(二)

註解與反射關聯的應用(三)

UDP通信（二）

TCP實現聊天室(五)

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結

RBAC權限（一）

一. 權限管理

一.一 什麼是權限管理?

一.二. 爲什麼要進行權限控制?

一.三. 開發中常見的權限控制

二. RBAC 實現權限管理

二.一 原始的權限管理

二.二 RBAC

二.二.一 RBAC的簡單解釋

二.二.二 RBAC的表設計

二.二.二.一 用戶表 user

二.二.二.二 角色表 role

二.二.二.三 用戶角色關聯表 user_role

二.二.二.四 權限表 privilege

二.二.二.五 角色權限表 role_privilege

二.三 四種模型 RBAC0,RBAC1,RBAC2,RBAC3

二.三.一 RBAC0 模型

二.三.二 RBAC1 模型

二.三.三 RBAC2 模型

二.三.三.一 靜態職責分離

二.三.三.二 動態職責分離

二.三.四 RBAC3 模型

三. RBAC 權限管理的完整表結構

一.一什麼是權限管理?

二.一原始的權限管理

二.二.二.一用戶表 user

二.二.二.二角色表 role

二.二.二.三用戶角色關聯表 user_role

二.二.二.四權限表 privilege

二.二.二.五角色權限表 role_privilege

二.三四種模型 RBAC0,RBAC1,RBAC2,RBAC3

二.三.三.一靜態職責分離

二.三.三.二動態職責分離