認證就是取得合法身份,比如京東需要用戶登錄以后才能才能下訂單,這里的登錄就是認證。登錄成功以后就具有了合法身份可以繼續進行下一步的操作。
常用的認證方式有基于session的認證和基于token的認證。
先來看一下基于session的認證:
用戶登錄成功后服務器會將用戶的信息保存在session(當前會話)當中,每個session對應有一個sessionid,將該sessionid發送給客戶端保存在cookie中??蛻舳讼麓卧L問的時候會將該sessioid帶上,在服務器端進行比對看是否存在對應的session以此判斷是否登錄。

再來看基于token的驗證:
用戶登錄成功后服務端生成一個token發送給客戶端,客戶端將收到的token存儲在cookie或localstorage中,下次訪問的時候帶上token到服務端驗證。

Session和token方式比較:
Sesion的認證方式需要將session存儲在服務端,會占用服務端的內存,并且需要客戶端開啟cookie功能,而基于token的認證方式則不用將token存儲在服務端,客戶端的保存也比較靈活,現在前后端分離的開發方式越來越流行,所以采用基于token的驗證方式更合適。
用戶登錄京東以后可以瀏覽商品,可以加入購物車,可以搜索商品,這些都是京東的功能,也是資源權限,我們說登錄用戶擁有這些權限,但是如果用戶沒有綁定銀行卡就無法支付,那么沒有綁定銀行的的用戶就不具有支付權限。給用戶授予相應功能權限的過程就叫授權,只有授權以后用戶才具有了相應的功能權限。
認證的過程是識別用戶身份是否合法,而授權是給予已經通過認證的用戶功能權限的過程,授權是在認證之后發生的.
RBAC是基于角色的權限控制,在RBAC里面有三大要素用戶、角色和權限:

用戶:用戶是權限管理的主體,用戶使用系統。
角色:如果給每個用戶單獨的分配權限會很繁瑣,比如多個用戶重復分配同一權限,引入角色的概念就會讓權限管理更為靈活,我們可以設置多個用戶為同一角色,然后給角色分配權限,則該角色下的用戶就都擁有了同樣的權限,比如:張老師,王老師,李老師都分配老師的角色,給老師分配查詢學生信息的權限則所有的老師都擁有了查詢學生信息的權限。一個用戶也可以分配多個角色,比如:張老師可以既是老師又是學術經理,那么他就同時具備了老師和學術經理的權限。
權限:權限可以分為三類:
數據權限:也就是用戶可以看到的數據內容,比如學校管理系統,老師只能看到學生的數據,學術經理可以看到學生和老師的數據。
頁面權限:這個部分的權限屬于基本的權限范疇,一般系統都會有這個類型的權限,他可以限制用戶能訪問哪些頁面,比如老師可以訪問添加作業的頁面,不能訪問查詢其他老師工資的頁面,頁面權限一般對應的是url地址。
操作權限:控制頁面上的按鈕,比如添加,修改,刪除。
用戶和角色是多對多的關系,角色和權限也是多對多的關系。
RBAC的權限控制系統通常對應五張表,舉例說明:
用戶表:
序號 | 字段名稱 | 字段類型 | 字段描述 |
1 | id | varchar2 | 無意義,主鍵uuid |
2 | varchar2 | 非空,唯一 | |
3 | username | varchar2 | 用戶名 |
5 | password | varchar2 | 密碼(加密) |
6 | phoneNum | varchar2 | 電話 |
7 | status | int | 狀態0 未開啟 1 開啟 |
角色表:
序號 | 字段名稱 | 字段類型 | 字段描述 |
1 | id | varchar2 | 無意義,主鍵uuid |
2 | roleName | varchar2 | 角色名 |
3 | roleDesc | varchar2 | 角色描述 |
權限表:
序號 | 字段名稱 | 字段類型 | 字段描述 |
1 | id | varchar2 | 無意義,主鍵uuid |
2 | permissionName | varchar2 | 權限名 |
3 | url | varchar2 | 資源路徑 |
用戶角色關系表:
序號 | 字段名稱 | 字段類型 | 字段描述 |
1 | userId | varchar2 | 用戶id(外鍵) |
2 | roleId | varchar2 | 角色id(外鍵) |
角色權限關系表:
序號 | 字段名稱 | 字段類型 | 字段描述 |
1 | permissionId | varchar2 | 權限id(外鍵) |
2 | roleId | varchar2 | 角色id(外鍵) |
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。