許可權設計（初稿）
1. 前言：
許可權管理往往是乙個極其複雜的問題，但也可簡單表述為這樣的邏輯表示式：判斷「who對what(which)進行how的操作」的邏輯表示式是否為真。針對不同的應用，需要根據專案的實際情況和具體架構，在維護性、靈活性、完整性等n多個方案之間比較權衡，選擇符合的方案。
2. 目標：
直觀，因為系統最終會由終端使用者來維護，許可權分配的直觀和容易理解，顯得比較重要簡單，包括概念數量上的簡單和意義上的簡單還有功能上的簡單。想用乙個許可權系統解決所有的許可權問題是不現實的。設計中將常常變化的「定製」特點比較強的部分判斷為業務邏輯，而將常常相同的「通用」特點比較強的部分判斷為許可權邏輯就是基於這樣的思路。
3. 現狀：
對於在企業環境中的訪問控制方法，一般有三種：
1.自主型訪問控制方法：目前在我國的大多數的資訊系統中的訪問控制模組中基本是借助於自主型訪問控制方法中的訪問控制列表(acls)。
2.強制型訪問控制方法：用於多層次安全級別的軍事應用。
3.基於角色的訪問控制方法（rbac）：是目前公認的解決大型企業的統一資源訪問控制的有效方法。其顯著的兩大特徵是：1.減小授權管理的複雜性，降低管理開銷。2.靈活地支援企業的安全策略，並對企業的變化有很大的伸縮性。
4. 名詞：
粗粒度：表示類別級，即僅考慮物件的類別(the type of object)，不考慮物件的某個特定例項。比如，使用者管理中，建立、刪除，對所有的使用者都一視同仁，並不區分操作的具體物件例項。
細粒度：表示例項級，即需要考慮具體物件的例項(the instance of object)，當然，細粒度是在考慮粗粒度的物件類別之後才再考慮特定例項。比如，合同管理中，列表、刪除，需要區分該合同例項是否為當前使用者所建立。
5. 原則：
許可權邏輯配合業務邏輯。即許可權系統以為業務邏輯提供服務為目標。相當多細粒度的許可權問題因其極其獨特而不具通用意義，它們也能被理解為是「業務邏輯」的一部分。比如，要求：「合同資源只能被它的建立者刪除，與建立者同組的使用者可以修改，所有的使用者能夠瀏覽」。這既可以認為是乙個細粒度的許可權問題，也可以認為是乙個業務邏輯問題。在這裡它是業務邏輯問題，在整個許可權系統的架構設計之中不予過多考慮。當然，許可權系統的架構也必須要能支援這樣的控制判斷。或者說，系統提供足夠多但不是完全的控制能力。即，設計原則歸結為：「系統只提供粗粒度的許可權，細粒度的許可權被認為是業務邏輯的職責」。
許可權公式：who+what(which)+how 的問題，在這裡我們實現what和部分which的許可權問題(粗粒度和細粒度相合，到一定的程度)，其他的許可權問題留給業務邏輯解決
6. 概念：
who：許可權的擁用者或主體（principal(負責人)、user、group、role、actor等等）
what：許可權針對的物件或資源（resource、class）。
how：具體的許可權（privilege, 正向授權與負向授權）。
role：是角色，擁有一定數量的許可權。
operator：操作。表明對what的how 操作。
7. 解釋：
user：與 role 相關，使用者僅僅是純粹的使用者，許可權是被分離出去了的。user是不能與 privilege 直接相關的，user 要擁有對某種資源的許可權，必須通過role去關聯。解決 who 的問題。
resource：就是系統的資源，比如部門新聞，文件等各種可以被提供給使用者訪問的物件。
privilege：是resource related的許可權。就是指，這個許可權是繫結在特定的資源例項上的。比如說部門新聞的發布許可權，叫做"部門新聞發布許可權"。這就表明，該privilege是乙個發布許可權，而且是針對部門新聞這種資源的一種發布許可權。privilege是由creator在做開發時就確定的。privilege 如"刪除" 是乙個抽象的名詞，當它不與任何具體的 object 或 resource 繫結在一起時是沒有任何意義的。拿新聞發布來說，發布是一種許可權，但是只說發布它是毫無意義的。因為不知道發布可以操作的物件是什麼。只有當發布與新聞結合在一起時，才會產生真正的 privilege。這就是 privilege instance。
role：是粗粒度和細粒度(業務邏輯)的介面，乙個基於粗粒度控制的許可權框架軟體，對外的介面應該是role，具體業務實現可以直接繼承或拓展豐富role的內容，role不是如同user或group的具體實體，它是介面概念，抽象的通稱。
operator的定義包括了resource type和method概念。即，what和how的概念。之所以將what和how繫結在一起作為乙個operator概念而不是分開建模再建立關聯，這是因為很多的how對於某what才有意義。比如，發布操作對新聞物件才有意義，對使用者物件則沒有意義。
8. 思想：
許可權系統的核心由以下三部分構成：1.創造許可權，2.分配許可權，3.使用許可權，然後，系統各部分的主要參與者對照如下：1.創造許可權 - creator創造，2.分配許可權 - administrator 分配，3.使用許可權 - user：
1. creator 創造 privilege， creator 在設計和實現系統時會劃分，乙個子系統或稱為模組，應該有哪些許可權。這裡完成的是 privilege 與 resource 的物件宣告，並沒有真正將 privilege 與具體resource 例項聯絡在一起，形成operator。
2. administrator 指定 privilege 與 resource instance 的關聯。在這一步， 許可權真正與資源例項聯絡到了一起， 產生了operator（privilege instance）。administrator利用operator這個基本元素，來創造他理想中的許可權模型。如，建立角色，建立使用者組，給使用者組分配使用者，將使用者組與角色關聯等等...這些操作都是由 administrator 來完成的。
3. user 使用 administrator 分配給的許可權去使用各個子系統。administrator 是使用者，在他的心目中有乙個比較適合他管理和維護的許可權模型。於是，程式設計師只要回答乙個問題，就是什麼許可權可以訪問什麼資源，也就是前面說的 operator。程式設計師提供 operator 就意味著給系統穿上了盔甲。administrator 就可以按照他的意願來建立他所希望的許可權框架可以自行增加，刪除，管理resource和privilege之間關係。可以自行設定使用者user和角色role的對應關係。(如果將 creator看作是 basic 的發明者， administrator 就是 basic 的使用者，他可以做一些指令碼式的程式設計) operator是這個系統中最關鍵的部分，它是乙個紐帶，乙個繫在programmer，administrator，user之間的紐帶。
許可權選單的設計
1.資源表 1.1 resource resourceid,resourcenamespace,description 1.2 category categoryid,name,parentid,description 1.3 module moduleid,name,url,description...
許可權選單設計
顧名思義，權 代表 權力 劃分了系統的職權，不同的使用者擁有不同的權力劃分 限 代表 限制 在權力劃分的基礎上對職能範圍進行了限制，本文所述的許可權相對簡單，賦予不同角色看到不同選單的許可權。許可權控制能較好地解決系統安全問題，避免公司機密資料外洩，同時，不同部門使用系統時互不干擾，因此被企業廣泛應...
選單的許可權
三層系統的選單的許可權問題 所謂選單，可以是c 做的選單，也可以是幾個js做的。下面是用js做的選單許可權 js的麵包屑導航 1.顯示層 1 準備三張 d1 1.jpg，d1 2.jpg，d1 3.jpg 用途 已登入顯示一張 未登入顯示一張 滑鼠懸停顯示一張。有許可權的選單 超連結 無許可權的選單...