1、資料許可權概述
1.1、什麼是資料許可權？
資料許可權是指對系統使用者進行資料資源可見性的控制，通俗的解釋就是：符合某條件的使用者只能看到該條件下對應的資料資源。那麼最簡單的資料許可權大概就是：使用者只能看到自己的資料。而在正式的系統環境中，會有很多更為複雜的資料許可權需求場景，如：
上述這些需求，使用硬編碼也是可以實現的，但是在業務快速發展的過程中，類似這種資料許可權需求會越來越多，如果全部採用硬編碼的方式，無疑會給我們帶來巨大的開發和維護壓力。
1.2、要素分析
從當前登入使用者的角度來說，資料許可權的定義可以解釋為：當前登入的使用者只能看到該使用者許可權範圍內的資料資源。由此可以分析出資料許可權控制中幾個關鍵要素：
主體，即當前登入使用者。領導、角色等概念可翻譯為當前登入使用者是否是領導，是否擁有某角色。
資料資源。即受管控系統資料。
條件規則。即當前登入使用者對於某特定的資料資源適用的條件。
2、資料許可權設計
理論上來說，使用者在訪問受控的系統資料時，獲取使用者對該資料資源適用的條件規則，並將該條件規則解析為sql查詢語句即可實現對資料的許可權控制。但是在實現過程中，還是會有很多難點，譬如當前登入使用者適用下列規則：
客戶資料：[客戶經理] [包含於] [下屬人員]產品資料：[銷售地區] [等於] [上海]訂單資料：（[產品銷售地區] [等於] [上海]）[並且] （[客戶市場經理] [包含於] [下屬人員]）思考如下問題：
[客戶經理] [包含於] [下屬人員]如何解析為sql語句？多表聯合查詢時又該如何處理？
[下屬人員]由系統根據當前登入使用者計算而來，上海由管理員後台選擇。兩種方式如何相容？
對於複雜多變的組合條件，應該如何設計？
如何確定當前查詢應該應用哪些條件規則？
乙個使用者擁有多個角色，不同角色對於同乙個規則設定不同的值應該如何處理？
2.1、規則元
2.2、規則元配置
1.規則元名稱的配置。乙個表中哪些字段可以進行規則設定，以及規則元名稱如何與表字段關聯。（如上述規則中[客戶經理]，[銷售地區]），比較容易想到的方法是通過配置檔案維護規則名稱與資料庫字段之間的關係。
配置檔案可以實現資料規則的配置需求，但是當規則元越來越多時，維護配置檔案就會變得麻煩起來，我們是否可以效仿spring-boot取代spring-mvc的做法，使用註解來代替配置呢？每一條資料規則最終都會落到對資料庫欄位的控制，而現在絕大部分系統都會有乙個model層對應到資料庫中的表，於是腦補出乙個絕佳的規則元配置方式：
@tablename("test")
public class testmodal extends abstractmodel
@datarule註解原始碼如下：
@target()
@retention(retentionpolicy.runtime)
public @inte***ce datarule 提供器類名
2.3、資料規則的配置
有了規則元資訊，管理人員即可在系統中針對不同使用者（角色）設定規則元value，該值作為資料查詢時的篩選條件。規則元value資料來源包含三種情況，其中第①、②種情況下，需要管理員填寫或選擇該規則的值，儲存於資料庫；第③種情況下，value值根據當前登入使用者計算得出，也即是@datarule註解中provider計算得來的值。由資料庫儲存的規則與系統計算得到的規則合併後即是登入使用者的所有資料規則。
乙個簡單的配置介面如下：
2.4 資料規則的解析
儲存在資料庫中的規則配置；如：所在地區[上海]
需要系統計算的規則配置；如：[下屬人員]
兩種情況下獲取的資料規則合併之後即可獲取適用於當前登入使用者的資料規則集合，流程圖如下：
兩種情況下獲取的資料規則如何相容？規則合併後成為乙個複雜的查詢條件應該如何設計？
定義通用的規則結構如下：
],
operate:"and",
group:
}
資料庫儲存規則結構的json串，合併時將json串反序列化之後使用and與系統計算得出規則物件連線即可，合併後的規則結構解析成簡單sql語句已經不是很難了。
但是對於多表聯合查詢時應該如何處理呢？
解析成sql語句時可以使用表名+欄位名的方式，可是遇到查詢中使用別名的時候，這種方式也不能正常工作，這裡暫時的處理方式是支援解析時傳遞別名。
乙個使用者擁有多個角色，不同角色對於同乙個規則設定不同的值應該如何處理？
譬如，使用者a擁有角色role1、role2，其中：
role1適用規則：[銷售地區] [等於] [上海]role2適用規則：[銷售地區] [等於] [北京]
那麼使用者a合併後的資料規則應該是：
使用者a適用規則：([銷售地區] [等於] [上海]) or ([銷售地區] [等於] [北京])
即：乙個使用者對於同乙個規則元的多個規則設定，應使用or連線後再與其他規則元進行and連線。
2.5、確定當前查詢適用的資料規則
經過上述的規則配置與解析之後，我們很容易拿到當前使用者適用的資料規則集合。但是在一次查詢時我們應該使用集合中哪些規則進行過濾呢？一次查詢是否開啟資料規則過濾，使用哪些表的規則過濾應該是開發者來決定，類似：
***query(...).withdatarule("`table1`,`table2`");
即表示當前使用者本次查詢使用table1、table2中配置的資料規則。資料表中的每條規則應該支援在管理後台設定是否啟用，這樣理論上可實現每個使用者對每一條資料規則的配置。
本群提供免費的學習指導 架構資料 以及免費的解答
不懂得問題都可以在本群提出來 之後還會有直播平台和講師直接交流噢
設定字段許可權 通用資料許可權的思考與設計
1 資料許可權概述 1.1 什麼是資料許可權？資料許可權是指對系統使用者進行資料資源可見性的控制，通俗的解釋就是 符合某條件的使用者只能看到該條件下對應的資料資源。那麼最簡單的資料許可權大概就是 使用者只能看到自己的資料。而在正式的系統環境中，會有很多更為複雜的資料許可權需求場景，如 上述這些需求，...
資料許可權設計思考
目前有關使用者許可權採用的比較多的都是基於rbac模型，即通過對角色許可權的定義完成對使用者許可權的限制。有關功能許可權部分想必都比較清楚，就是將系統的功能模組劃分清楚，並賦予不同角色的訪問許可權，這樣在使用者訪問某個功能模組之前進行許可權校驗即可。但是有關資料許可權部分卻一直比較模糊。在如下這篇文...
通用許可權管理設計 之資料許可權
本文將對這種設計思想作進一步的擴充套件，介紹資料許可權的設計方案。許可權控制可以理解，分為這幾種 功能許可權 能做什麼的問題，如增加產品。資料許可權 能看到哪些資料的問題，如檢視本人的所有訂單。字段許可權 能看到哪些資訊的問題，如 商賬戶，看不到角色 部門等資訊。上面提到的那種設計就是 功能許可權 ...