最近專案的專案很奇怪，乙個大專案(系統)裡包含了很多小的子系統，而這些子系統中都有許可權控制的部分，這件事情挺讓我頭痛的，記得一年前在瀋陽，我曾經有一段時間也因因這個問題而疲於奔命，為什麼說疲於奔命呢？由於當時專案進度不允許，導致最終系統許可權模組草草了事，每個模組都是由讀許可權字串來控制使用者acl，當使用者無法訪問時，提示許可權不夠。這麼做對使用者是很不負責任的，既然讓使用者看到了操作的方式和介面，為什麼又告訴使用者沒有許可權呢？
我開始懷疑我們是否應該在底層就**使用者的訪問許可權。
現在專案開展起來了，雖然目前我已經有了對許可權控制的一套方案，並且實施成了我的可重用框架**，雖然目前的許可權也是基於眾星捧月的aop思想，但我至今對許可權設計仍有兩個疑惑：
疑惑一：很多同行提出方案，想要在底層就擷取使用者許可權，控制使用者對方法或者類的訪問。這樣做的好處在於可以將系統功能與業務邏輯鬆散耦合，並且實現簡單，結構清晰，三兩個advisor、filter，或者acegi就能搞定，但在web程式中體現出了他的劣勢，當我們將使用者的訪問拒絕在業務邏輯之外的時候，我們此時是否應該丟擲異常提示使用者？
一旦提示使用者沒有相應的許可權，我認為對於使用者來說，這就不是乙個perfect practice。由此得出，我們根本就不應該讓使用者做此次操作，而控制使用者操作的源頭就是介面，也就是說，在介面上我們就應該對使用者的許可權元素(如新增按鈕、功能選單等)進行控制。此時，一對矛盾出現了，要控制介面上形形色色的元素只有兩種辦法，一，將許可權與你的介面結合起來設計，這將違背aop的思想，也使得系統控制模組的重用性大大下降，二，我們借鑑primeton的想法，將許可權控制的理念抽取出來，單獨做成一套許可權系統，解決你所有的需要許可權控制的系統需求，這樣也有令人頭痛的問題，你的所有想用它來控制許可權的系統，必須介面上統一風格。
或許這樣的方式對商業web系統是合適的，畢竟需要你大刀闊斧個性化的地方不多，但我們卻很難保證在未來幾年內商業web系統的風格不改變。再者，開發這麼乙個系統也不是一蹴而就的事，在這個問題上一直讓我困惑不已。
疑惑二：大多應用的許可權判定是基於許可權字串的，但儲存在資料庫中的許可權字串能夠判定的許可權並不多，在我們這次專案中，我引用了基於二進位制的8421許可權判定法則，我深深的感覺到許可權字串的弱勢，這使我想起了中國古老一套數學理論-「盈不足術」，超遞增序列的魅力在我眼前滑過，
首先我來解釋一下盈餘不足理論：有十隻盒子，第乙個盒子裡放乙個盤子，第二個盒子裡放兩隻，第三個盒子裡放四隻，第四個盒子裡放八隻……第九個盒子裡放256只，第十個盒子放512只，即第n只箱子裡放2^(n-1)只盤子，一共1023只。那麼命題如下：
在1023這個數字之內，任何乙個數目都可以由這十隻盒子裡的幾隻組合相加而成。那麼1、2、4、8、16、32、64、128、256、512這個序列為什麼有這麼個魔力？這個數列的特點：
1、每項是後一項的二倍，2、每項都比前面所有項的和大，而且大1。這個1就是關鍵，就因為這個1，它才可以按 1遞增，拼出總和之內任意乙個整數。這個序列叫做超遞增序列，它是解決揹包問題的基礎。
3、拼出總和之內任意乙個整數可以由這個序列中的一些數構成，且構成方法唯一，據說是密碼學中的np定理。譬如說這個數列總合中20這個數，只能由16+4一種方法構成，由此延伸出來，如果綜合中這個資料代表乙個權值，我們可以解出它的所有構成引數（操作），如20這個資料，我們可以挨個和序列中每一項按位與，得出來如果不等於0，就說明他是由這個數構成的。
儲存權值到int還是varchar對於我們來說是個問題，當然，儲存字串的好處是運算壓力小。我們可能聽過乙個故事，就是把這個超遞增序列延伸到第64 項，就是那個術士和皇帝在西洋棋棋盤上要公尺粒的傳說。64項的和是乙個天文數字！
但計算機本身就是乙個只認識二進位制的機器！很多程式設計師整天只關心架構，甚至不知道或者不關心位操作是什麼玩意，當然我們有朋友擔心資料庫的int不夠長，那麼既然可以儲存乙個只有0、1組成的varchar字串，為什麼不能儲存乙個十六進製制的字串，有人規定varchar只能儲存01嗎？十六進製制串的長度正好是二進位制的四分之一。
由此我們可以無限制的擴充套件權值操作。
在最近的專案裡，我對許可權的控制分成兩個部分，第一就是使用者體驗上，我設定了乙個許可權標籤，從資料庫中抽取許可權資訊，然後做到標籤裡，也湊或算成是介面 aop了，第二就是底層的攔截，用了spring 的aop，為的是防止許可權衝突，雙管齊下。暫時解決許可權所需，另外在演算法上我用了16進製制的許可權判別**，雖然配置較麻煩，寫完**還要寫文件說明，不過也解決了許可權繁雜又多的問題，暫時就這樣了，嘿嘿，以後有空再研究。
使用者認證管理設計方案
1 設計思路
為了設計一套具有較強可擴充套件性的使用者認證管理，需要建立使用者、角色和許可權等資料庫表，並且建立之間的關係，具體實現如下。
1.1 使用者
使用者僅僅是純粹的使用者，用來記錄使用者相關資訊，如使用者名稱、密碼等，許可權是被分離出去了的。使用者（user）要擁有對某種資源的許可權，必須通過角色（role）去關聯。
使用者通常具有以下屬性：
ü 編號，在系統中唯一。
ü 名稱，在系統中唯一。
ü 使用者口令。
ü 注釋，描述使用者或角色的資訊。
1.2 角色
角色是使用許可權的基本單位，擁有一定數量的許可權，通過角色賦予使用者許可權，通常具有以下屬性：
ü 編號，在系統中唯一。
ü 名稱，在系統中唯一。
ü 注釋，描述角色資訊
1.3 許可權
許可權指使用者根據角色獲得對程式某些功能的操作，例如對檔案的讀、寫、修改和刪除功能，通常具有以下屬性：
ü 編號，在系統中唯一。
ü 名稱，在系統中唯一。
ü 注釋，描述許可權資訊
1.4 使用者與角色的關係
乙個使用者（user）可以隸屬於多個角色（role），乙個角色組也可擁有多個使用者，使用者角色就是用來描述他們之間隸屬關係的物件。使用者（user）通過角色（role）關聯所擁有對某種資源的許可權，例如
l 使用者（user）：
userid username userpwd
1 張三 ******
2 李四 ******
……l 角色（role）：
roleid rolename rolenote
01 系統管理員監控系統維護管理員
02 監控人員**監控人員
03 排程人員排程工作人員
04 一般工作人員工作人員
……l 使用者角色（user_role）：
userroleid userid roleid userrolenote
1 1 01 使用者「張三」被分配到角色「系統管理員」
2 2 02 使用者「李四」被分配到角色「監控人員」
3 2 03 使用者「李四」被分配到角色「排程人員」
…… 從該關係表可以看出，使用者所擁有的特定資源可以通過使用者角色來關聯。
1.5 許可權與角色的關係
乙個角色（role）可以擁有多個許可權（permission），同樣乙個許可權可分配給多個角色。例如：
l 角色（role）：
roleid rolename rolenote
01 系統管理員監控系統維護管理員
02 監控人員**監控人員
03 排程人員排程工作人員
04 一般工作人員工作人員
……l 許可權（permission）：
permissionid permissionname permissionnote
0001 增加監控允許增加監控物件
0002 修改監控允許修改監控物件
0003 刪除監控允許刪除監控物件
0004 察看監控資訊允許察看監控物件
……l 角色許可權（role_permission）：
rolepermissionid roleidpermissionidrolepermissionnote
1 01 0001 角色「系統管理員」具有許可權「增加監控」
2 01 0002 角色「系統管理員」具有許可權「修改監控」
3 01 0003 角色「系統管理員」具有許可權「刪除監控」
資料庫設計
一 實驗目的 1 熟悉資料庫及表物件的建立過程 2 熟悉表字段型別及屬性的設定 3 熟悉資料表資料的編輯 4 熟悉建立多表間關係的操作。二 實驗裝置及軟體環境 一 實驗裝置 伺服器 交換機和pc機組成nt網路。二 軟體環境 1 伺服器採用microsoft windows 2003 server 作...
資料庫設計
一 需求分析 訂單資料流程圖 道路 標識id featuredentifier 幾何標識 geometryfield 要素編碼，道路名，長度 倉庫 depotid id，name，open time，close time tb depot表 商品庫存資訊 stock，goodid，companyna...
資料庫設計報告
本系統主要用於旅館或賓館出租的房間管理。1.使用者身份的登記 2.房屋出租管理 3.年收 支情況 本系統包括 標準模組 系統登入模組 主介面模組 系統管理模組 學生基本資訊管理模組 選課模組 成績管理模組。1.標準模組 定義公共變數和過程。2.系統登入模組 進行使用者身份的驗證。3.主介面模組 作為...