AuthorizationCore
授權項目
通過將授權項、角色、相應對象相關聯的方式來判斷，請求對象是否有權限進行相應的操作。
項目分析
簡單點說授權就是一個對象（可能是個人；可能是個角色），在進行某件事情之前，根據一定的數據設定計算，被請求對象（動作的依附對象，可能是一個文件也；可能是某一個類文件；）的某一個動作（可能是文件的讀寫；可能是某一個方法）是否有權利完成。
名詞簡介
請求對象
自然人
張三、李四某一個系統中的具體的用賬號密碼登錄的人員都可以被認爲是自然人。
角色
某些情況下我們可能非常難做到自然與實際的被請求對象之間的關心，因爲這實在是一件太龐大的數據了。比如張三對於張三的博客是博主，所以張三對於張三的博客擁有管理權限。但是李四並不是張三博客的博主，所以李四並不能管理張三的博客。我們可以直接對張三跟戰三的某一篇博客建立請求與相應之間的關係，但是這個數據量會變得非常龐大。所以某些情況下，我們只能先通過數據計算張三與戰三博客的關係，然後在通過這個關係來判定數據的權限。
其他
當然這個地方可以存在其他，請求對象只是一個請求對象而已。比如說，我們現在要建立一個平臺服務，這個服務可以提供很多API給其他的系統，但是每一個系統所能調用的API接口不盡相同。那麼，我們怎樣通過我們的授權服務來判定哪幾個接口可以調用，哪幾個不可以呢？比如我們可以將某一個系統作爲一個請求對象來調用服務，就可以做到相應的權限管控了。當然還有很多很多其他的情況，我在這裏只是簡單的舉個例子，爲大家拋磚引玉
響應對象
既然存在請求，那麼相對的就會存在響應對象。那麼響應對象一般情況下可以是什麼呢？
具體的響應對象
具體的響應對象可以是某一個文件，比如你想刪除掉這個文件，我們就可以具體判斷你對這個文件是否擁有某些權限，這個時候文件就是一個響應對象。也可以是一個組織，比如你想操作這個組織，修改這個組織的頭像。這個時候這個組織就是一個具體的響應對象。
邏輯意義對象
就像是我們在 請求對象-角色 中提到的那樣，很多時候我們並不能規定某些具體的人對於某些具體的對象的權限，因爲這些對象實在是太多了，如果動態的維護這些數據，那是一件非常痛苦的事情。所以我們提出了上邊的對象概念，那麼久會扯出來另一個概念，邏輯意義對象，張三的博客對於張三來說，實際上就是自己的博客。當然李四的博客對於李四來說也是自己的博客，從這個地方上來講，這兩個自然人對於這兩個實際的對象擁有相同的授權。自己的博客並不是特指某一個具體的對象而是指某個邏輯上的對象。
某些業務場景
像是前文中提到的某一個類中的函數允不允許調用的問題。這個時候就是某些業務場景。當然這個可以認爲是某一個具體的響應對象，畢竟那個類就是那個類。不過這個地方因爲不牽扯到具體的類的實例，所以還是單獨拿出來歸爲一類比較好
其他
……
角色
這個角色有別於之前提到的角色，但是兩者非常類似。角色定義爲某個人擁有的身份，比如說，張三是張三兒子的老師，那麼張三對於張三兒子就有多個身份：父親、老師、可能還有朋友。假設我們來規定不同的身份對於戰三的兒子擁有不同的權利。那麼張三對於張三兒子的權利還蠻多的畢竟身份也有很多。
角色
角色對於角色這個地方可能非常容易理解，因爲角色就是角色嘛。不過角色還會支持一個高級特性。權限合併這個一會我們在講。
個人
某些情況，我們需要給某一個人進行授權，這個時候我們可能需要創建一個對象，專門用來表示這個個人。因爲個人表示某一個個人，所以個人與個人之間並沒有什麼直接關係。比如說張三和李四，他們之間除了都是人可能也沒有啥太特殊的關係。
組織
一般情況下，個人也好。請求對象中的角色也好，一般都是歸屬於某些組織的。當然組織是在其他系統中實現的，組織的內容我們不做過多的展開，組織的概念呢就是根據這些組織結構相對應的角色對象。比如說，張三歸屬於紅星公司的研發部。這個地方可能就會產生兩個角色，紅星公司跟研發部。而張三則因爲組織結構的原因會被設置到研發部這個角色下擁有研發部角色的相關權利。
權限繼承
角色篇章裏邊，我們提到了戰三與研發部的關係。不過張三隻屬於研發部嘛？應該不是，研發部屬於紅星公司，那麼張三自然也就屬於紅星公司。那麼我們現在有兩條路可以選，張三可以同時擁有兩個角色，我們將兩個角色的權利合併，我們就可以得到張三的的所有權利。另一條路，張三屬於研發部，研發部屬於紅星公司，將紅星公司的權利賦予研發部，那麼張三自然擁有了所有的權限。其實想來看看，如果組織結構層級非常深的情況下，那麼張三會擁有非常非常多的角色。這也是一件非常恐怖的事情，所以我們要走第二條路。其實不光是組織，所有的角色對象都應該是這樣的，不過，講道理個人不應該被繼承。
權限合併
講完了繼承，我們該講講合併了。張三跟他兒子的關係的時候，我們就提到了很常見的情況就是一個請求對象對應一個相應對象有非常多的角色。當你想驗證你做一件事情是否擁有權限的時候，就應該將你所有的權限合併起來，然後綜合來看你對想做的事情究竟擁有怎樣的授權。
權限的狀態
在講合併之前得先講講權限的幾種狀態：未定義、通過、拒絕。
未定義
這事我不管你們看着辦，行也可以，不行也可以。
通過
好了我覺得這事能行。
拒絕
不行這事不行
合併
- 只要所有的授權項中有一項是拒絕的，那麼整個授權結果都是拒絕的。
- 如果所有的授權項中都是通過或者未定義則將授權項定義爲通過。
- 如果所有的授權項都是未定義的，則合併結果爲未定義。
後邊兩條或許還好理解一些，第一條則需要着重解釋一下。其實這個地方來源於兩個概念，黑名單和白名單。他們分開使用的情況下應該非常容易理解，但是他們一旦一塊使用了，並且同一個人出現在了兩個名單裏邊，就讓人難以抉擇了。那麼我們應該怎麼辦呢，讓我們先看一下後邊的例子。
讓我的老師遠離我的QQ空間：
你申請了一個QQ，你有一個QQ空間。但是你不想讓你的老師看到你的QQ空間。其他人是無所謂的，那麼一般情況下會這麼設置：1.任何人都可以看；2.我的老師不能看；這個時候你的老師就會出現在兩個衝突的授權中（你的老師是所有人的一員，你的老師也是你的老師）。在這種情況下我們取什麼值呢？答案很顯然是不通過，否則就違背了我們的本意。
多羣組：
張三同時加入了兩個組織，而這兩個組織是相互有利益衝突的。假設他們現在建立了一條規矩，說屬於對方組織的人是不能夠訪問我們的資源的；我們自己組織裏邊的人時可以訪問我們的資源的。那麼擁有兩個組織的資源訪問權限嗎（畢竟他既屬於自己的組織又屬於對面的組織）？其實考慮這個問題應該從設置規矩的出發點上來看待這個問題，其實就是害怕對方的組織訪問了自己的東西，而給自己的組織造成了利益上的傷害。那麼從這個角度出發張三是沒有權限的。
或許你會考慮張三既然屬於了組織那麼就應該享有權利，如果不想讓張三擁有權利，可以通過某些授權來解決問題其他的手段保證合併
- 不讓戰三加入組織。確實可以解決，並且大部分情況下組織如果有衝突的話，一般情況下也確實不會讓他們相互加入，但是在某些情況下是沒有機制保證這件事情的。所以這種做法可能沒有照顧的那麼全。
- 踢出授權範圍。比較常見，比如說除了張三的所有人都享有權利。但是這個在數據表達上可能就比較困難。雖然可以做，但是相關的表達這句話的程序數據模型就會變得非常複雜，所以也比較困難
授權項
其實講到這裏，缺少什麼也應該比較清楚了。就是缺少了具體的動作。比如說訪問資源、訪問QQ空間。這些都是依附在響應對象上的具體動作。
授權項的依附
授權項是依附在響應對象身上的。回到最開始的文件案例上來。某一個具體的文件上的讀、寫、刪這些授權項都是依附在某一個具體的文件對象身上的。
權限項的分類
其實相同的內容會有相同的權限項。比如文件類型的響應對象，那麼無非也就是讀、寫、刪這麼幾個動作。別的你應該也沒有辦法弄對吧；那麼對於QQ空間來說就是被訪問；響應對象應該會存在一個類型，然後授權項的模板應該是依附在相應對象類型身上的。
END