本文將對這種設計思想作進一步的擴充套件，介紹資料許可權的設計方案。
許可權控制可以理解，分為這幾種 ：
【功能許可權】：能做什麼的問題，如增加產品。
【資料許可權】：能看到哪些資料的問題，如檢視本人的所有訂單。
【字段許可權】：能看到哪些資訊的問題，如**商賬戶，看不到角色、 部門等資訊。
上面提到的那種設計就是【功能許可權】，這種設計有一定的侷限性，對於主體，只能明確地指定。對於不明確的，在這裡可能就沒辦法處理。比如下面這幾種情況：
資料僅當前部門及上級可見
資料僅當前使用者(本人)可見
本文我將介紹如何利用乙個表兩個字段完成這個【資料許可權】的設計思路
【資料許可權】是在【功能許可權】的基礎上面進一步的擴充套件，比如可以檢視訂單屬於【功能許可權】的範圍，但是可以檢視哪些訂單就是【資料許可權】的工作了。
在設計中，我們規定好如果沒有設定了資料許可權規則，那麼視為允許檢視全部的資料。
幾個概念
【資源】：資料許可權的控制物件，業務系統中的各種資源。比如訂單單據、銷售單等。屬於上面提到的【領域】中的一種
【主體】：使用者、部門、角色等。
【條件規則】：用於檢索資料的條件定義
【資料規則】：用於【資料許可權】的條件規則
2，銷售單，可以由本人或上級領導檢視
3，銷售單，銷售人員可以檢視自己的，銷售經理只檢視 銷售金額大於100,000的。
我們能想到直接的方法，在訪問資料的入口加入sql where條件來實現，組織sql語句：
where userid =
where userid = or in (領導)
where userid = or ( in (銷售經理) and 銷售金額 > 100000）
這些乙個乙個的"條件"，本文簡單理解為乙個【資料規則】，通常會與原來我們前台的業務過濾條件合併再檢索出資料。【資源】 - 【資料規則】
我又覺得不同的人應該對應不同的規則，那麼也可以理解為，乙個使用者對應不同的角色，每乙個角色有不一樣的【資料規則】，那麼設計就變成
【資源】 - 【主體】 - 【資料規則】
根據提供者的不同，準備不同的許可權應對策略。
這裡可以簡單地介紹一下，這個方案至少需要2張表，乙個是 【資源，主體，規則關係表】、乙個是【資料規則表】
關係表不能直接儲存角色，因為你不確定什麼時候業務需要按照【部門】或者【分公司】來定義資料規則
於是可以用 master、masterkey 類似這樣的兩個欄位來確定乙個【主體】
我們的設計關鍵在於如何規範好這些【資料規則】 ，這個規則必須是對前端友好的，而且是對後台友好的，json顯然是很好的方式。
規則說明：
1，資料許可權規則總是：｛屬性 條件 允許值｝
2，資料許可權規則可以合併。比如 （ and ) or
3，最終我們會用json格式
如下圖定義了客戶資訊的搜尋框，我們搜尋客戶id包括an，我們組織成的規則將會是：
],"op":"and"}許可權控制總離不開一些條件的限制(比如檢視當前部門的單據)，如果沒有完善的通用查詢規則機制，那麼在做許可權條件過濾的時候你會覺得很彆扭。這裡介紹乙個通用查詢方案，然後再介紹如何實現【資料規則】。
,
],"op":"and"}
規則描述：
查詢顧客vinet所有訂單時間小於2011-01-01的單據
通用後台的翻譯，就可以生成這樣sql的引數：
text:
([orderdate] < @p1 and [customerid] = @p2)
parameters:
p1:2012-01-01
p2:vinet
],
"groups":[
, ],"op":"or"}
],"op":"and"
}
text:([orderdate] < @p1 and ([customerid] = @p2 or [customerid] = @p3))
parameters:
p1:2012-01-01
p2:vinet
p3:tomsp
這種簡單的結構就可以滿足全部的情況。
當然，上面提到的這些條件都是在前台定義(可能是使用者在搜尋框自己輸入的)的，而 在後台，我們可能會定義一下【隱藏條件】，比如說 【員工只能檢視自己的】，要怎麼做呢，其實很簡單，只需要在後台接收到這個過濾條件(前台tojson，後台解析json)以後，再加上乙個過濾規則(隱藏條件)：
],
"groups":[
,],"op":"or"}
],"op":"and"}
],rules:
}
text:
([employeeid] = @p1 and ([orderdate] < @p2 and ([customerid] = @p3 or [customerid] = @p4)))
parameters:
p1:5
p2:2012-01-01
p3:vinet
p4:tomsp
也可以在後台進行處理。在後台我們會定義跟這種資料結構對應的類，那麼再定義乙個翻譯成sql的類：
說了這些，可以開始介紹如何實現【資料規則】了：
上面提到的【隱藏條件】，就是我介紹的【資料規則】
試想一些，這樣 前台的過濾規則，再加上我們之間定義好的 【資料許可權】控制 過濾條件。不就達到目的了嗎。
先看看我們在資料庫裡儲存的這些【資料規則】：
看不明白？那來個清楚一點的：
下圖是我們設計【資料許可權】的介面，可以選擇所有的字段，包括幾個使用者資訊：
如果說資料許可權是對功能許可權在縱向的擴充套件，那麼字段許可權就是在橫向的擴充套件。可以禁止指定使用者/角色 對某些欄位的訪問
舉個例子：我有個員工表，b使用者能查詢5條記錄，但看不見記錄中工資欄位裡的資料，c使用者也能查詢5條記錄，但能看到記錄中工資欄位裡的資料，因為c使用者是財務部門的人。
可以在體驗實際的應用效果。
通用許可權管理設計
最近又碰到了許可權的分配和管理，需要單獨設計一套結構。其實以前有了很多的這方面的設計和博文，在園子裡面的找找看就會找到n頁的結果。這裡也不敢說是新思路吧，權當是自己的總結和留個腳印吧，方便查詢。通用在這裡有兩個概念 1 為了吸引眼球 一看到是通用就要點開看看究竟，當然了，結果無非是幾種，有人罵，有人...
通用許可權管理設計篇（一）
一 引言 因為做過的一些系統的許可權管理的功能雖然在逐步完善，但總有些不盡人意的地方，總想抽個時間來更好的思考一下許可權系統的設計。許可權系統一直以來是我們應用系統不可缺少的乙個部分，若每個應用系統都重新對系統的許可權進行設計，以滿足不同系統使用者的需求，將會浪費我們不少寶貴時間，所以花時間來設計乙...
通用的許可權管理系統設計
一般的企業應用系統，最重要的兩個模型是資料模型和許可權模型。資料模型根據不同的行業有所不同，而許可權模型跟行業關係不大，但是每個應用系統所必不可少的，也常常令設計者大為頭疼。如何設計乙個通用的許可權管理系統呢，如何 使這個許可權系統能夠足夠靈活，而又能適應企業不斷變化的業務呢？遵循如下原則就可以基本...