Redmi Buds 4開箱簡評：才199還有降噪 可以無腦入
在上個月舉辦的Redmi Note11T Pro系列新機發布會上，除了兩款手機新品之外，Redmi還帶來了兩款TWS真無線藍牙耳機產品，Redmi Buds 4和Redmi Buds 4 Pro，此前我們在Redmi Note11T
常見的，在項目實際開發中我們不光要控制一個用戶能訪問哪些資源，還需要控制用戶只能訪問資源中的某部分數據。這就是所謂的數據權限。典型的如列表數據權限，主要通過數據權限控制行數據，讓不同的人有不同的查看數據規則。
在互聯網系統中，權限一般分為功能權限和數據權限，功能權限比較常見，因為通用性和復用性，業內有很多的通用框架和設計。但對應數據權限來說，由于數據權限強依賴客戶組織架構和具體業務的關系，往往實現起來會比較復雜，很少有一個設計架構能完全覆蓋住，所以大部分的系統都一致性的遵循此策略：如非必要的盡量不使用數據權限，必須要的則單獨控制。
目前常見數據權限方案基本為硬編碼，具體分為如下兩種：一是拆分功能頁面，即根據不同數據權限用戶，通過復制拷貝的方式，增加多個類似的菜單，再通過功能權限配置來給不同用戶設置不同的菜單，從而實現數據權限的控制；二是在功能對應的后端接口里做判斷，對不同數據權限的用戶，過濾不同的數據列表透出給用戶。硬編碼的方式顯而易見的優點是技術難度低，實現簡單。
但以上硬編碼的方式，無論選擇用哪一種，都無法解決系統靈活性的問題，每當系統有老的需求要變更或者新的需求要新增，對應的開發人員就不得不去調整編碼，修改菜單和頁面，由此可見，硬編碼對開發的成本和運維的成本都比較高。與此同時，行業內常見的通用數據權限控制，大都是給單一業務使用，和業務耦合度較高，可能在當前業務客戶端是通用可擴展的，但是在另一個業務客戶端就無法做到無縫接入了。
因此，如何提高數據權限設置的靈活性，降低耦合性，是本領域技術人員需要解決的問題。
首先來說一下，為什么我們要做這樣一個多系統的數據權限控制裝置？
大背景是我司當前有多個業務系統需要通過數據權限控制業務數據，它們的用戶體系或相同或不同，控制維度各有定制。
于是產生諸如以下需求：
為了支持以上需求，于是理所當然的出現了如下一套多系統的通用數據權限控制系統。
本系統底層使用統一的一套模型，支持權限配置化，業務方可自定義權限維度，用戶體系解耦，滿足不同系統快速接入數據權限的業務場景。
RBAC是經典的功能權限模型，它是 Role-BasedAccess Control 的英文縮寫，意思是基于角色的訪問控制。
運營事先會在系統中定義出各種不同的角色，不同的角色擁有不同的權限，一個角色實際上就是一組權限的集合。而系統的所有用戶都會被分配到不同的角色中，一個用戶可能擁有多個角色。使用這種模型可以極大地簡化權限的管理。
但是，在該模型下，系統只會驗證用戶甲是否屬于角色A，而不會判斷用戶甲是否能訪問只屬于用戶乙的數據 Data。這種問題我們稱之為“水平權限管理問題”。
所以，為了解決這個問題，我們基于 RBAC 模型下，又擴展了功能和維度的概念，使系統能基于角色控制用戶的數據權限。如下：
圖片
同時，為了做到多系統通用，我們又對系統、功能、權限做了如下抽象：
圖片
模型把每個系統抽象成由一個個業務組成，業務下分解成多個功能，功能對應多個維度:
根據以上描述，顯而易見的，要實現數據權限，最重要的是需要抽象出數據規則。
比如我們營銷系統的訂單列表，需要從下面幾個維度來控制數據訪問權限。
銷售人員只能看自己的數據；
a 部門的人只能看自己部門的數據；
a 部門的上級部門 A 的人能看自己部門的數據和下級 b 部門的人；
上面的這些維度就是數據規則。
這樣數據規則的幾個重點要素我們也明晰了，就是規則字段，規則表達式，規則值，上面三個場景對應的規則分別如下：
規則字段：創建人，規則表達式：= ，規則值：當前登錄人
規則字段：所屬部門，規則表達式：= ，規則值：a
規則字段：所屬部門，規則表達式：in ，規則值：A,a
即數據規則由【維度+條件表達式+維度對應值】組成，業務數據的數據權限就是由多個數據規則組成的范圍控制。具體模型如下：
圖片
那么，本套多系統權限控制系統，到底該如何接入呢？大致流程如下：
圖片
按照此通用方案，數據控制整體接入過程如下：
1.業務確定需要數據權限接入的功能。
2.產品、開發、業務確認功能的維度。
3.運營在開發的支持下在運營管理端配置數據權限，包括支持的維度、表達式、固定值等等。如需自定義維度對應值，實現對應端口。
4.各系統管理員登錄各自的數據權限配置端，設置每個角色的數據規則。
5.客戶訪問系統的具體功能，根據客戶的角色，獲得數據規則，根據數據規則組裝業務數據返回。
訂單是很常見的系統功能，當前，需要對不同員工查看訂單的數據范圍做控制，根據員工所屬的部門不同，查看對應部門的訂單列表。
步驟一：確定系統、功能、維度
系統：xxx系統 功能：訂單列表 維度：部門
步驟二：管理端配置數據權限
圖片
步驟三：業務方接入 Sdk，實現自定義維度（部門）選擇項配置端口
示意代碼
/** * 獲取維度選擇項 */List<DimensionOption> getDimensionOptionList(List<String> dimensionCodes);步驟四: 對應api查詢數據接口接入 Sdk，完成數據過濾
步驟五: 系統管理員配置角色數據權限
只要完成以上5步，就實現了接入數據權限的功能。整個流程只有接入 Sdk 的成本，1天內即可完成，快速、高效，極大的降低了成本。同時公司內所有系統都擁有了一套完整統一的權限控制系統。
那么，底層究竟是如何實現數據權限控制的？
以下是一個請求的控制鏈路：
圖片
權限 Sdk 是真正實現權限控制的核心組件。
圖片
Sdk 中的基石是一個個對外開放的端口，其中最底層的是上下文端口。接入方需實現這個端口接口，根據當前緩存用戶封裝數據權限上下文。如有自定義維度，需實現自定義維度選擇項端口，返回業務自定義的維度選擇項。
數據權限生效實現過程如下：
1.請求 Path 被 Sdk 攔截，通過正則匹配配置的權限 Api，匹配到說明需要被控制。
2.在功能接口中，Sdk 根據上下文端口獲取當前請求上下文，根據上下文獲取對應用戶所有角色的數據權限。
3.根據數據權限設置的配置，組裝權限控制的條件。
4.業務方查詢時加上權限控制條件，得到的數據，就是控制了數據權限后的數據。
ps:本sdk只針對java語言的后端
如果業務方使用的是 MyBatis 的 Xml 原生語句， Sdk 會把所有的數據權限組裝成對應的 Sql 片段，自動對XML查詢注入該 Sql 片段；如果使用的是 MyBatis-plus 的 QueryWrapper 方式，Sdk 會把所有的數據權限自動注入到生成的 QueryWrapper 條件中。
業務方也可以自主使用權限控制配置查詢數據，關閉 Sdk 的自動注入。
還有更多的類似問題，都是多系統數據權限控制需要解決的。雖然具體到每個小點，單從技術的角度來說，可能未必很難，但要支持更多系統，具備更好的通用化，還有很長的一段路可走。這是一個會隨著業務的發展，需要持續改進的工作。
本文鏈接：http://www.tebozhan.com/showinfo-26-16497-0.html權限管理——多系統下的數據權限通用控制
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號