提供介面供其他系統使用，用於判斷在某些情況下的某些人（或者系統）是否有許可權呼叫當前函式。
場景：業務規劃的場景內容（比如使用者、訊息）
操作：業務規劃的場景內操作（比如使用者的增刪改查、訊息的增刪改查的各個函式）
請求物件：希望呼叫當前函式的物件（可以是自然人：張
三、李四；可以是角色：帖子的擁有者）
角色型別：個人、角色、群組（個人：直接給單個人建立的角色，系統自動維護的；角色：管理員建立的角色，可以進行繼承；群組：為組織關係自動建立的角色；）
授權狀態：拒絕、授權、未設定
角色繼承：乙個角色可以繼承其他幾個角色，間接獲取他們的授權。（如果繼承自多個角色則合併他們的授權）
合併授權：多個授權項之間合併（合併規則為拒絕》授權》未設定）
覆蓋授權：當前角色可以不遵從父級授權的結果，直接設定授權狀態
根據設計實現的簡單說明可以將資料庫簡單設計到如下狀態，不過這裡有部分資料設計的可以簡化，實現表現層內容的時候遇到了比較難實現的問題，當然最後還是實現了，不過實現的過程異常痛苦。
因為本專案是作為基礎專案，其他的所有專案的基礎授權模組，所以本專案並沒有整合到任何專案中，而是通過udp開放埠的方式來提供相關的呼叫。
id：
name：名稱
displayname：顯示名稱
password：密碼
originaltoken：原始token
status：狀態（是否禁用）
parentid：父物件id
id：
name：名稱
roletype：角色型別（個人、角色、群組）
tenantid：租戶id
id：
roleid：角色id
parentid：父物件id
tenantid：租戶id
id：
requestid：請求id（一般為自然人id或者場景角色id）
tenantid：租戶id（應用id）
displayname：顯示名稱
id：
requestobjectid：請求物件id
authorizationroleid：授權角色id
tenantid：租戶id
id：
name：名稱
displayname：顯示名稱
tenantid：租戶物件
id：
responseobjectid：響應物件id
roleid：角色id
tenantid：租戶id
租戶、應用是資料的模擬分塊，中間的資料不會造成相互影響。可以簡單理解為資料模組的各自的沙盒模組。
請求為了適應實際的場景而建立的對應資料模組。因為相容各個子系統的資料，所以使用了租戶id與請求id共同確定物件，請求id可以是子系統中合適的資料（自然人id或者其他方便的id）。
角色是實現授權模組的重要模組中間中間資料載體。是一種身份的象徵，可以代指個人，也可以代指某種可以繼承的角色，也可以是團隊身份的象徵。
角色繼承
因為將授權項設定的非常龐大的時候，那麼這裡邊的授權也會變得比較複雜。某些授權可能需要被繼承來的比較好。至於為什麼是這樣我後面會提到。
響應需要被驗證授權的內容部分。必須說某乙個訊息，比如說某乙個帖子等等
請求與角色的對映
因為授權實際上是授到了角色身上所以，我們驗證授權的時候，也是驗證了角色的授權，至於你有沒有許可權，那麼就理所當然的被認為是你是否存在這個角色，或者說你所擁有的所有角色最後許可權合併究竟是乙個什麼結果。請求與角色的對映關係就是表示，你究竟擁有那些角色關係的資料結構。
響應與角色的對映
前面已經提到了，授權實際上是響應的物件給某乙個角色新增了某些許可權項的具體授權。實際上這句話表面上看是對的，不過有乙個細節需要強調一下，實際上響應物件並不是直接給角色進行了授權，而是給響應物件與角色的對映關係進行了授權。說出來有點繞。但是現在的實現是這樣，不過也可以在授權項裡邊直接繫結響應物件id跟授權物件id來表示這層關係，不過為了減少資料量這個地方多出來一張表。不過我覺得可能前面說的這種方式可能更容易實現一些。
來簡單總結一下授權的過程是怎樣的。其實授權的過程就是請求與角色進行繫結。響應與角色繫結，並且在響應與角色的繫結上新增某些具體授權項的過程。計算具體授權結果則是，通過請求獲取到全部的角色，然後將角色對於某一響應計算出所有的授權結果，然後獲得合適的授權結果的過程。
許可權合併
先解釋一下什麼叫做許可權合併，就是講多個平級角色的許可權合併的過程。那麼什麼叫做平級角色？實際上這個是抽象的概念，如果我同時擁有兩個角色，我改怎麼處理？比如說，你跟我是同事，也是我的朋友，如果我希望我的朋友能夠看到我的朋友圈。那麼這個時候你會有兩個角色，乙個是同事，乙個是朋友。這兩個身份就是平級的角色。還有其他的情況，比如說，乙個角色繼承自多個角色，那麼在他這一級，他直接繼承的父角色都是平級。橫跨多層的角色也是一層一層的資料累加下來的。
提到了許可權合併就不得不提許可權裡的一條比較重要的原則，叫做拒絕優先。意思就是說，如果我有兩個角色，乙個是拒絕，乙個是通過，那麼我的許可權就是拒絕的。
角色繼承的必要性
其實沒有角色繼承這個服務依然可以實現，那麼角色繼承存在的意義究竟是什麼。我來舉個例子簡單說明一下。比如說一篇部落格設定許可權是這樣的，比如登入使用者可以檢視，一級使用者可以點讚，二級使用者可以回覆，主人可以編輯刪除。那麼問題來了一級使用者不只是可以點讚吧，因為他是登入使用者，所以他也擁有登入使用者的許可權，二級使用者可以回覆也可以檢視。主人呢可以編輯可以刪除可以檢視。這其中是有繼承關係的，當然如果說沒有繼承關係也可以實現，因為你登入，我自然是可以給你新增乙個登入使用者的，你自然而然的擁有了檢視的許可權。但是這樣處理會多出來很多許可權的對映。如果一級、二級、主人都是繼承自登入使用者的話，你的許可權對映則會少很多。再舉乙個例子，比如你們有兩個部門，這兩個部門存在競爭關係，他們相互之間不允許對方的人檢視自己的資料。但是現在出現了乙個很尷尬的問題，比如你是這兩個部門的領導，那麼根據許可權合併的拒絕優先原則，你實際上是看不到ab兩部門的資料。但是業務上你應該是可以看到資料的。那麼現在怎麼辦，應該是建立乙個跨部門領導給你，然後將這個角色的資料設定為兩邊都可以看到，覆蓋掉原本的拒絕設定。
設定相關的**都不重要，隨便搞，是那麼個意思就行了。這個專案裡邊最核心的**就是獲取所有使用者，然後組建繼承樹，然後通過合併繼承許可權的方式計算請求對於響應的所有授權項的**。
/// /// 獲取請求物件對應具體場景的所有授權狀態
///
///
///
///
///
public override dictionarygetauthorizationstatus(long tenantid, string scene, long requestid)
, });
// 請求物件與角色相對應的關係
// 響應物件與角色對應的關係
treenode root_tree = new treenode();
treenode trygettreenode(long id)
// 組裝樹形結構
root_tree.parentnode.add(trygettreenode(item.authorizationroleid));
}// 組裝授權說明
}void inheritauthorization(treenode node)
}// 獲取所有授權子項
listall_keys = new list();
foreach (var item in node.parentnode)
all_keys.distinct();
// 合併所有父級授權
foreach (var item in all_keys)
node.authorizationstatus[item] = mergeauthorizationstatus(s_list.toarray());}}
inheritauthorization(root_tree);
return root_tree.authorizationstatus;
}
Shiro授權詳細解析
shiro授權 shiro支援三種方式的授權 1.程式設計式 通過編寫if else授權 塊的方式完成 不推薦 2.註解式 通過在controller方法上面註解完成 用的較多 3.jsp標籤 在頁面上面完成 可以隱藏無許可權的東西 shiro授權過程 1.授權需要繼承 authorizingrea...
思考詳細設計
新一篇 思考詳細設計 maillist中的討論 ai92 2006 8 2 設計在軟體開發中扮演的角色，相信大家都很清楚。設計的好壞直接影響著軟體產出的質量。設計一般分為架構設計 概要設計 和詳細設計。架構設計主要從系統整體上來考慮使用什麼樣的架構 如何劃分模組以及制定模組間的通訊規則。因此架構設計...
詳細設計文件
如上圖，可以看到詳細設計文件是，瀑布模型 中承上啟下的乙個關鍵環節，在做好需求分析和軟體架構之後，寫好詳細設計文件就意味可以進行編碼了。由此，可以看到詳細設計文件有三個作用 1，為具體編碼環節做好鋪墊與設計，從而指導編碼工作 2，提供測試所需文件參考 3，可作為理解編碼的參考文件。詳細設計的主要任務...