1 資料級的許可權管理和功能級的許可權管理 

功能級許可權，有大有小。大的可以直接包括一個業務模組，小的可以是一個按鈕。一般的功能級許可權一般包括：選單、url、按鈕 。

資料級許可權主要是針對訪問資料的可見範圍。一般包括以下幾類：當前操作人可見、部門可見、部門及子部門可見……等。資料級許可權目前常用的做法就是在業務模組的表中增加操作人欄位（如：creator），然後通過aop或者是在基類的查詢、檢視、更新、刪除中，把creator欄位值與可見範圍進行特殊處理。

2 不使用框架(shiro,springsecurity)做許可權設計的思考(我的理解是拼sql)

所謂操作許可權

就是有或者沒有做某種操作的許可權，具體表現形式就是你看不到某個選單或按鈕，當然也有的是把選單或按鈕灰掉的形式。實際上它的實現機制比表面上看到的要複雜得多，比如：我們從瀏覽器訪問過一個地址之後，實際上這個URL就會在歷史中存在，這時就會存在一種可能，有的人雖然沒有許可權，但是他知道怎麼訪問的URL，如果他再有一定的技術基礎，那麼通過猜測，有時候就可以得到真正的操作的URL，這個時候如果操作許可權限制做得不到位，那麼他就可能做他非授權的事項，所以操作許可權一般都在顯示介面做一次控制，過濾沒有許可權的操作選單或按鈕，另外在真正執行操作時，還要進行一次許可權檢查，確保控制非授權訪問。
所謂資料許可權 

就是有或者沒有對某些資料的訪問許可權，具體表現形式就是當某使用者有操作許可權的時候，但不代表其對所有的資料都有檢視或者管理許可權。資料許可權有兩種表現形式：一種是行許可權、另外一種是列許可權。所謂行許可權，就是限制使用者對某些行的訪問許可權，比如：只能對本人、本部門、本組織的資料進行訪問；也可以是根據資料的範圍進行限制，比如：合同額大小來限制使用者對資料的訪問。所謂列許可權，就是限制使用者對某些列的訪問許可權，比如：某些內容的摘要可以被查閱，但是詳細內容就只有VIP使用者才能檢視。通過資料許可權，可以從物理層級限制使用者對資料的行或列進行獲取，這種方式比把所有資料拿到之後再根據使用者許可權來限制某些行或列有諸多好處：
效能提升：獲取的資料量較少，節省了網路流量和資料庫IO，一定程度上可以提升效能
翻頁處理更為準確：如果通過後續邏輯去掉某些行，就會導致一頁顯示的記錄條數不足，或者採用這條記錄只顯示部分內容，但是操作許可權方面做限制的方式，這個時候就產生一個悖論，你不想讓我操作，為什麼讓我看到？你讓我看到為什麼不讓我操作？
安全風險提升：理論上讓攻擊者看到的資訊越多，被攻擊的風險也越大。通過後續業務邏輯限制的方式通過攻擊控制層或展現層的程式碼，理論上就可以獲取到所有的資料。
程式碼編寫工作量增加：由於資料是正常全部返回的，只是通過後期的邏輯進行了控制，這個時候就需要開發人員增加相關的程式碼來進行判斷和控制，這個時候會把高層級的限制邏輯暴露給底層業務開發人員，並由他們來編寫程式碼進行限制。
程式碼重構工作量增加：當權限限制邏輯或範圍有變化的時候，程式設計師們就需要對這部分邏輯進行重構，稍不注意就會出現資料安全問題。
操作許可權相對來說比較簡單，目前也有比較好的解決方案，因此今天的不討論操作許可權，今天重點來討論資料許可權的實現方案。

需求整理
一個好的資料許可權方案要考慮哪些問題呢？我覺得要考慮以下方面：
對程式設計師透明：整個方案對於程式設計師們來說，不論是前臺還是後臺的程式設計師們來說，越透明越好，他們最好不知道有這麼回事情
與不同的使用者許可權能較好整合：作為一個數據許可權系統來說，肯定要和使用者、角色、組織機構什麼的資料打交道。如果這個方案只能和某一種使用者許可權系統整合，那麼它充其量只能算是一個可用的解決方案，但是註定算不是上好的解決方案。
效能損失最少：我們說，要增加新的功能或限制的過程中，肯定會對效能方面有一定影響的，怎麼樣能把效能損失降低，甚至能提升一定的效能是設計師們永恆的主題。
對於分頁能良好支援：上面有說到當採用了行許可權時，有些行是不能顯示給使用者的，這個時候不能對分頁有影響，比如本來是一頁是10條的，現在忽然變成8條，甚至在極端情況下變成0條，這樣的使用者體驗就非常差了。
一次設定到處生效,哪怕是不同的ORMapping方案也都起作用：我們知道，現在採用唯一的一種ORMapping解決方案的場景已經越來越少了，不同的方案都有自己的優缺點，它可能只適應某種前置條件下的應用場景，實際應用的情況下根據場景不同使用不同的解決方案也是非常普遍的，這就要求解決方案有一定的普適定。
跨資料庫：一個專案，它的執行環境基本上是確定的。但是對於一個產品來說，根據使用者的實際場景不同，可能對於資料庫也有不同的要求，這個時候就需要對不同的資料庫有支援，不能對於A資料庫是支援的，對於B資料庫的場景下，就出異常或者結果不正確了。
需求分析
由於要對程式設計師透明，因此解決方案不應該在DAO層實現。
由於要和不同的使用者許可權系統進行整合，因此確定了不能在DAO層實現。
對於分頁有良好的支援，決定了不能在DAO層和顯示層實現。
一次設計到處生效，對多種ORMapping方案生效，決定了不能在ORMapping層實現。
要求能跨資料庫，進一步提升了方案的通用性和普適性，也提升了實現的難度。
資料行許可權不是所有的過濾條件都是和使用者、角色、崗位欄位有關的，不是所有的表中，都有使用者、角色、崗位欄位，這個時候也要能良好支援。比如：人員資訊表中：不同的級別的HR，可以看到不同級別的人員資訊。總之過濾條件可能是資料表中的任意欄位。
資料列許可權是控制列的可見性的，也就是說，同樣對這行資料有許可權，但是可能對其中的幾列沒有許可權，則這幾列不可見。
比如表table1 有（a,b,c,d,e,f）欄位，列許可權控制可能控制c,d不可見。但是程式設計師寫程式碼的時候可能寫的是select * from table1，這種情況下也不能返回c,d欄位。

RBAC就是個基礎模型，它是基礎的但不是萬能的。這就好比馮諾依曼的計算機模型，是非常基礎的，只要是學計算機的都必然要先學習這套模型；但現在的計算機沒有哪個是僅僅依據馮諾依曼的模型來設計的，都在各個方面做出了長足的擴充套件與優化，比如CPU和記憶體之間的多級快取，比如IO通道上的獨立計算晶片（相當於一個簡易CPU了）。

所以無論是什麼系統，多半都會在RBAC上進行擴充套件甚至裁剪。

以上說的比較空些，下面說點我自己的理解。

許可權總體而言可以分為兩類：功能許可權 和 資料許可權。功能許可權泛指對某個功能（頁面、按鈕、命令）的使用權；資料許可權則泛指所能操縱的範圍；比如你有刪除郵件的功能（功能許可權），但只能刪除自己的郵件（資料許可權）。

當功能許可權數量過於龐大，導致管理複雜度太高時，自然就會考慮對其進行分類，於是誕生了一個新的概念：“角色”，也即一組許可權的集合，我也見過某些系統稱之為“許可權模板”。

隨後又會面臨另一個問題，就是功能許可權與資料許可權的匹配問題，比如你作為版主，你可以刪除你板塊下的任何帖子，但修改卻只能針對自己的帖子，這就是不同功能許可權匹配了不同的資料許可權。為此某些系統會為此誕生一個新的概念：“崗位”，有些也會稱之為“業務組”之類的很多名字；簡化的處理方式也有直接將資料許可權跟組織機構直接對應起來從而忽略資料許可權的管理。


再寫下去似乎不好結束了啊。。。看來只好草草收場了。總的來說：儘可能理解各種設計的優異之處和侷限性，然後根據業務需求來設計符合系統要求的許可權模型，然後不要忘了：簡潔就是美。