幾乎每一個軟件系統都涉及到權限設計，權限控制又分為功能權限控制和數據范圍權限控制。toC的軟件權限控制一般都是根據用戶畫像（特征數據）來控制的，即使有部分可以配置也相對比較簡單。toB的系統一般都需要靈活的配置，功能權限配置也有RBAC（Role-Based Access Control）這樣的標準，數據范圍權限控制就沒有這樣的標準的解決方案了。
常見的數據范圍權限控制方案
常見的一種數據范圍權限控制方案是將業務按照歸屬人員和歸屬部門來劃分，在配置時可有以下選項：
- 我的業務；
- 部門的業務；
- 下級部門的業務。
這樣的設計一般也能夠滿足大部分業務的需求，但是它有以下幾個明顯的缺點：
- 不是非常靈活，只能根據業務的歸屬來進行范圍劃分；
- 數據必須內置歸屬人員和歸屬部門字段，有的系統還約定了字段名稱。
基于條件表達式的數據范圍設置
條件表達式類似與sql語句條件表達式，在數據查詢時植入到查詢語句中，在修改時對數據對象進行驗證。
數據范圍權限條件表達式設置
條件表達式的形式是一個邏輯表達式，其中方括號中的是 [表名.字段名]，花括號中的是 { 環境變量或屬性 ':' 在SQL語句中的變量名}，這個SQL語句中的變量名是可選的，它的作用是個前面環境變量和屬性重命名，避免命名SQL語句不合法。
配置不同角色的 數據權限范圍
接口的權限遵循RBAC規范，將接口和角色關聯，系統在關聯角色時同時配置數據范圍表達式，實現范圍的權限控制。
條件表達式數據范圍控制的實現方式
訪問關系數據庫有兩種方式，一種通過ORM接口訪問數據庫中的表，另一種是直接用SQL語句訪問數據庫。這兩種方式有不同的控制方式：
一、ORM接口訪問
需要對ORM接口進行擴展或者自己設計一套ORM方案，南大先騰做了MyBatis和Hibernate的對應功能的拓展 https://github.com/ndxt/centit-persistence/tree/before-delete-hibernate-mybatis ，因為后來公司全部研發都轉移到自研的ORM，這個擴展也不再更新了，各位有興趣可以獲取。
在ORM接口訪問數據庫時對上面的表達式進行轉換，主要是轉換花括號{}中的環境變量。
二、SQL語句訪問
SQL語句訪問時也要對語句進行拓展，在SQL語句中添加錨點，形式如下：
select * from bussiness_chance a where 1=1 { bussiness_chance a } order by a.create_time
其中 { bussiness_chance a } 為錨點，形式為 { 表名 別名， 表名 別名，……..} 別名是可選的，一個錨點可以有多個表。SQL語句再執行前需要進行預處理，系統根據當前用戶的角色查找他用于的角色在當前接口中的所有數據范圍權限表達式，如果有多個表達式則用or連接成符合比表達式，并替換到SQL語句的錨點中。比如上面的示例替換的結果為：
select * from bussiness_chance a where 1=1 and a.follow_user = :currUserCode order by a.create_time
同時在參數變量表中添加一個currUserCode的變量，對應的值為 當前用戶環境變量中的currentUser.userCode值。
總結
通過條件表達式的方式來控制數據范圍權限理論上可以對任何字段進行過濾控制，可以在系統上線后同個配置的方式進行靈活配置。但是也有一些缺點：一、只能用于關系數據庫并且需要拓展ORM模塊或者自研ORM模塊，二、SQL語句需要添加數據范圍權限的控制錨點，雖然不麻煩也不復雜但是不能忘掉。
版權聲明：本文內容由互聯網用戶自發貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發現本站有涉嫌抄襲侵權/違法違規的內容， 請發送郵件至 舉報，一經查實，本站將立刻刪除。
