幾乎每一個軟件系統(tǒng)都涉及到權限設計，權限控制又分為功能權限控制和數(shù)據(jù)范圍權限控制。toC的軟件權限控制一般都是根據(jù)用戶畫像（特征數(shù)據(jù)）來控制的，即使有部分可以配置也相對比較簡單。toB的系統(tǒng)一般都需要靈活的配置，功能權限配置也有RBAC（Role-Based Access Control）這樣的標準，數(shù)據(jù)范圍權限控制就沒有這樣的標準的解決方案了。

常見的數(shù)據(jù)范圍權限控制方案

常見的一種數(shù)據(jù)范圍權限控制方案是將業(yè)務按照歸屬人員和歸屬部門來劃分，在配置時可有以下選項：

• 我的業(yè)務；
• 部門的業(yè)務；
• 下級部門的業(yè)務。

這樣的設計一般也能夠滿足大部分業(yè)務的需求，但是它有以下幾個明顯的缺點：

• 不是非常靈活，只能根據(jù)業(yè)務的歸屬來進行范圍劃分；
• 數(shù)據(jù)必須內置歸屬人員和歸屬部門字段，有的系統(tǒng)還約定了字段名稱。

基于條件表達式的數(shù)據(jù)范圍設置

條件表達式類似與sql語句條件表達式，在數(shù)據(jù)查詢時植入到查詢語句中，在修改時對數(shù)據(jù)對象進行驗證。

數(shù)據(jù)范圍權限條件表達式設置

條件表達式的形式是一個邏輯表達式，其中方括號中的是 [表名.字段名]，花括號中的是 { 環(huán)境變量或屬性 ':' 在SQL語句中的變量名}，這個SQL語句中的變量名是可選的，它的作用是個前面環(huán)境變量和屬性重命名，避免命名SQL語句不合法。

配置不同角色的 數(shù)據(jù)權限范圍

接口的權限遵循RBAC規(guī)范，將接口和角色關聯(lián)，系統(tǒng)在關聯(lián)角色時同時配置數(shù)據(jù)范圍表達式，實現(xiàn)范圍的權限控制。

條件表達式數(shù)據(jù)范圍控制的實現(xiàn)方式

訪問關系數(shù)據(jù)庫有兩種方式，一種通過ORM接口訪問數(shù)據(jù)庫中的表，另一種是直接用SQL語句訪問數(shù)據(jù)庫。這兩種方式有不同的控制方式：

一、ORM接口訪問

需要對ORM接口進行擴展或者自己設計一套ORM方案，南大先騰做了MyBatis和Hibernate的對應功能的拓展 https://github.com/ndxt/centit-persistence/tree/before-delete-hibernate-mybatis ，因為后來公司全部研發(fā)都轉移到自研的ORM，這個擴展也不再更新了，各位有興趣可以獲取。

在ORM接口訪問數(shù)據(jù)庫時對上面的表達式進行轉換，主要是轉換花括號{}中的環(huán)境變量。

二、SQL語句訪問

SQL語句訪問時也要對語句進行拓展，在SQL語句中添加錨點，形式如下：

select * from bussiness_chance a where 1=1 { bussiness_chance a } order by a.create_time

其中 { bussiness_chance a } 為錨點，形式為 { 表名 別名， 表名 別名，……..} 別名是可選的，一個錨點可以有多個表。SQL語句再執(zhí)行前需要進行預處理，系統(tǒng)根據(jù)當前用戶的角色查找他用于的角色在當前接口中的所有數(shù)據(jù)范圍權限表達式，如果有多個表達式則用or連接成符合比表達式，并替換到SQL語句的錨點中。比如上面的示例替換的結果為：

select * from bussiness_chance a where 1=1 and a.follow_user = :currUserCode order by a.create_time

同時在參數(shù)變量表中添加一個currUserCode的變量，對應的值為 當前用戶環(huán)境變量中的currentUser.userCode值。

總結

通過條件表達式的方式來控制數(shù)據(jù)范圍權限理論上可以對任何字段進行過濾控制，可以在系統(tǒng)上線后同個配置的方式進行靈活配置。但是也有一些缺點：一、只能用于關系數(shù)據(jù)庫并且需要拓展ORM模塊或者自研ORM模塊，二、SQL語句需要添加數(shù)據(jù)范圍權限的控制錨點，雖然不麻煩也不復雜但是不能忘掉。