語音交友app開發許可權系統，不容錯過的設計方案

前言

許可權管理是所有後臺系統的都會涉及的一個重要組成部分，主要目的是對不同的人，訪問語音交友app開發資源進行許可權的控制，避免因許可權控制缺失或操作不當引發的風險問題，如操作錯誤，隱私資料洩露等問題。

1. 許可權模型

迄今為止，語音交友app開發最為普及的許可權設計模型是 RBAC 模型, 基於角色的訪問控制（Role-Based Access Control)

1.1 RBAC0 模型

RBAC0 模型如下:

這是語音交友app開發許可權最基礎也是最核心的模型, 它包括使用者 / 角色 / 許可權, 其中使用者和角色是多對多的關係, 角色和許可權也是多對多的關係。

使用者是發起操作的主體, 按型別分可分為 2B 和 2C 使用者, 可以是後臺管理系統的使用者, 可以是 OA 系統的內部員工, 也可以是面向 C 端的使用者。

語音交友app開發中的角色起到了橋樑的作用, 連線了使用者和許可權的關係, 每個角色可以關聯多個許可權, 同時一個使用者關聯多個角色, 那麼這個使用者就有了多個角色的多個許可權。

有人會問了為什麼在語音交友app開發中使用者不直接關聯許可權呢？在使用者基數小的系統, 比如 20 個人的小系統，管理員可以直接把使用者和許可權關聯，工作量並不大，選擇一個使用者勾選下需要的許可權就完事了。

但是在實際語音交友app開發中，使用者基數比較大, 其中很多人的許可權都是一樣的，就是個普通訪問許可權，如果管理員給 100 人甚至更多授權, 工作量巨大。

這就引入了 “角色 (Role)” 概念, 語音交友app開發的一個角色可以與多個使用者關聯, 管理員只需要把該角色賦予使用者, 那麼使用者就有了該角色下的所有許可權, 這樣設計既提升了效率, 也有很大的擴充性。

• 許可權：

是使用者可以訪問的語音交友app開發資源, 包括頁面許可權, 操作許可權, 資料許可權:

• 頁面許可權:

即使用者登入語音交友app開發系統可以看到的頁面, 由選單來控制, 選單包括一級選單和二級選單, 只要使用者有一級和二級選單的許可權, 那麼使用者就可以訪問頁面

• 操作許可權:

即語音交友app開發頁面的功能按鈕，包括檢視, 新增, 修改, 刪除, 稽核等，使用者點選刪除按鈕時，後臺會校驗使用者角色下的所有許可權是否包含該刪除許可權。如果是, 就可以進行下一步操作, 反之提示無許可權。

有的系統要求 “可見即可操作”, 意思是如果語音交友app開發頁面上能夠看到操作按鈕, 那麼使用者就可以操作, 要實現此需求, 這裡就需要前端來配合, 前端開發把使用者的許可權資訊快取, 在頁面判斷使用者是否包含此許可權, 如果有, 就顯示該按鈕, 如果沒有, 就隱藏該按鈕。

某種程度上提升了使用者體驗, 但是在實際場景可自行選擇是否需要這樣做

• 資料許可權:

語音交友app開發的資料許可權就是使用者在同一頁面看到的資料是不同的。

在一些語音交友app開發時，全國有很多分佈城市和服務節點，比如杭州使用者登入系統只能看到杭州的資料，上海使用者只能看到上海的資料，解決方案一般是把資料和具體的組織架構關聯起來。

以上是 RBAC 的核心設計及模型分析, 此模型也叫做 RBAC0, 而基於核心概念之上, RBAC 還提供了擴充套件模式。包括 RBAC1,RBAC2,RBAC3 模型。下面介紹這三種型別

1.2 RBAC1 模型

此模型引入了角色繼承 (Hierarchical Role) 概念，即語音交友app開發的角色具有上下級的關係，角色間的繼承關係可分為一般繼承關係和受限繼承關係。

一般繼承關係僅要求角色繼承關係是一個絕對偏序關係，允許角色間的多繼承。

而受限繼承關係則進一步要求角色繼承關係是一個樹結構，實現角色間的單繼承。這種設計可以給角色分組和分層，一定程度簡化了許可權管理工作。

1.3 RBAC2 模型

基於核心模型的基礎上，進行了語音交友app開發的角色約束控制，RBAC2 模型中新增了責任分離關係。

其規定了許可權被賦予角色時，或角色被賦予使用者時，以及當使用者在某一時刻啟用一個角色時所應遵循的強制性規則。

責任分離包括靜態責任分離和動態責任分離。主要包括以下約束:

• 互斥角色:

語音交友app開發中同一使用者只能分配到一組互斥角色集合中至多一個角色，支援責任分離的原則。

互斥角色是指各自許可權互相制約的兩個角色。比如財務部有會計和稽核員兩個角色, 他們是互斥角色, 那麼使用者不能同時擁有這兩個角色, 體現了職責分離原則

• 基數約束:

一個角色被分配的使用者數量受限；在語音交友app開發中，一個使用者可擁有的角色數目受限；同樣一個角色對應的訪問許可權數目也應受限，以控制高階許可權在系統中的分配

• 先決條件角色:

即使用者想獲得某上級角色, 必須先獲得其下一級的角色

1.4 RBAC3 模型

即最全面的許可權管理, 它是基於 RBAC0，將 RBAC1 和 RBAC2 進行了整合。

1.5 使用者組

當語音交友app開發平臺使用者基數增大，角色型別增多時，而且有一部分人具有相同的屬性，管理員的工作量就會很大。

如果把語音交友app開發中相同屬性的使用者歸類到某使用者組，那麼管理員直接給使用者組分配角色，使用者組裡的每個使用者即可擁有該角色，以後其他使用者加入使用者組後，即可自動獲取使用者組的所有角色，退出使用者組，同時也撤銷了使用者組下的角色，無須管理員手動管理角色。

根據使用者組是否有上下級關係, 可以分為有上下級的使用者組和普通使用者組:

• 具有上下級關係的使用者組:

最典型的例子就是部門和職位，可能多數人沒有把部門職位和使用者組關聯起來吧。

當然使用者組是可以擴充的，部門和職位常用於內部的管理系統，如果是面向 C 端的系統。

• 普通使用者組:

即在語音交友app開發中沒有上下級關係，和組織架構，職位都沒有關係，也就是說可以跨部門，跨職位。

語音交友app開發都會涉及到到組織和職位, 下面就重點介紹這兩個。

1.5.1 組織

常見的組織架構如下圖:

我們可以把組織與角色進行關聯，使用者加入組織後，就會自動獲得該組織的全部角色，無須管理員手動授予，大大減少語音交友app開發的工作量，同時使用者在調整時，只需調整組織，角色即可批量調整。

組織的另外一個作用是控制資料許可權, 把角色關聯到組織, 那麼該角色只能看到該組織下的資料許可權。

1.5.2 職位

假設財務部的職位如下圖:

每個組織部門下都會有多個職位，雖然都在同一部門，但是每個職位的許可權是不同的，職位高的擁有更多的許可權。

1.6 含有組織 / 職位 / 使用者組的模型

根據以上場景, 新的許可權模型就可以設計出來了, 如下圖:

根據系統的複雜度不同, 其中的多對多關係和一對一關係可能會有變化

1、在語音交友app開發單系統且使用者型別單一的情況下，使用者和組織是一對一關係，組織和職位是一對多關係，使用者和職位是一對一關係，組織和角色是一對一關係，職位和角色是一對一關係，使用者和使用者組是多對對關係，使用者組和角色是一對一關係，當然這些關係也可以根據具體業務進行調整。

模型設計並不是死的, 如果小系統不需要使用者組, 這塊是可以去掉的。

2、語音交友app開發分散式系統且使用者型別單一的情況下，到這裡許可權系統就會變得很複雜，這裡就要引入了一個 “系統” 概念。

3、此時語音交友app開發系統架構是個分散式系統，許可權系統獨立出來，負責所有的系統的許可權控制，其他業務系統比如商品中心，訂單中心，使用者中心，每個系統都有自己的角色和許可權，那麼許可權系統就可以配置其他系統的角色和許可權。

2. 授權流程

授權即給使用者授予角色, 按流程可分為手動授權和審批授權。語音交友app開發的許可權中心可同時配置這兩種, 可提高授權的靈活性。

• 手動授權:

管理員登入語音交友app開發的許可權中心為使用者授權，根據在哪個頁面授權分為兩種方式：給使用者新增角色，給角色新增使用者。

給使用者新增角色就是在使用者管理頁面，點選某個使用者去授予角色，可以一次為使用者新增多個角色；給角色新增使用者就是在角色管理頁面，點選某個角色，選擇多個使用者，實現了給批量使用者授予角色的目的。

• 審批授權:

即使用者申請某個職位角色，那麼使用者通過 OA 流程申請該角色，然後由上級審批，該使用者即可擁有該角色，不需要語音交友app開發系統管理員手動授予。

3. 表結構

有了上述的許可權模型, 設計語音交友app開發表結構就不難了, 下面是多系統下的表結構, 簡單設計下, 主要提供思路:

4. 許可權框架

• Apache Shrio
• Spring Security

在語音交友app開發中可以採用其中一種框架, 它們的優缺點以及如何使用會在後面的文章中詳細介紹。

5. 結語

許可權系統可以說是語音交友app開發整個系統中最基礎，同時也可以很複雜的，在實際的語音交友app開發中，會遇到多個系統，多個使用者型別，多個使用場景，這就需要具體問題具體分析，但最核心的 RBAC 模型是不變的, 我們可以在其基礎上進行擴充套件來滿足需求。

本文轉載自網路，轉載僅為分享乾貨知識，如有侵權歡迎聯絡雲豹科技進行刪除處理
原文連結：