最近負責一個項目的重構架構實施，執行到權限這一塊時，發現對原有的權限體系很難下手，包括對錶間設計或者是說對權限的顯示控制。
權限，無非就是賦權和權限攔截。
先從權限攔截開始說起吧，對於普通的web來說，對權限的攔截無非就是前端加一個fiter類似的攔截器，對用戶訪問的權限進行攔截。比如說，用戶採用產品碼和功能碼進行訪問，比說用戶這個大的產品下有用戶創建這樣一個功能。但是用戶創建又分爲1.填寫表單 2.詳細信息錄入 3.提交創建成功 。在這裏如果說用戶這個大產品下，對創建這樣的功能則需要具有原子性，及如果創建用戶是2001 200101這樣的產品碼和功能嗎，則200101要包含三個部分，填寫表單，詳細信息錄入，提交創建成功。 即再攔截的時候，如果沒有功能權限，則都不能訪問。
之所以提出這一點，就是因爲現在的系統缺失了這種功能原子性。還是上面的例子，分爲3個功能碼，200101作爲填寫表單 200102作爲信息錄入 200103作爲創建。在這種情況下會出現一些很嚴重的問題，比如說攔截的時候，需要對這三個功能碼都進行攔截。
接下來討論賦權。
賦權就是上級對下級的賦權，其中包括上級用戶對下級用戶的賦權，上級組織對下級組織的賦權。
通常來說，權限體系會有如下的表設計：
T_ROLE :可以動態的定義系統中的所有角色
T_PRODUCT：定義系統中的產品功能，上面提到的功能原子性在這裏又做進一步提現，如果不將功能做原子化處理，那麼在這裏可能一條功能會對應多條記錄
T_ROLE_PRODUCT：角色權限
T_AUTHENTICATE：用戶權限
通常賦權的操作爲1.上級賬戶讀取下級角色可用的權限，2.讀取自身的權限進行賦值
在這裏，兩次讀取都需要用到功能的原子性，因爲當用戶讀取權限的時候，在T_PRODUCT中明確的定義了當前系統所有的產品和功能，以及其產品碼和功能嗎，如果沒有遵守原子性，這張表裏馬上又回出現冗餘。
對於權限的設計，除了要注意通用性之外，還要特別的注意對功能定義的原子性。否則系統無論從維護還是其他的設計，都比較難執行。