許可權系統(2)--operation
許可權控制可以看作乙個filter模式的應用, 這也符合aop思想的應用條件。在乙個簡化的圖象中，我們只需要將乙個判別函式 isallowed(subject, operation, resource)插入到所有安全敏感的函式呼叫之前就可以了。雖然概念上很完美，具體實現的時候仍然有一些細節上的問題。基本的困難在於很難在最細的粒度上指定許可權控制規則（連續的？動態的？可擴充套件的？），因而我們只能在一些關鍵處指定許可權規則，或者設定一些整體性的許可權策略，然後通過特定的推理來推導出細粒度的許可權規則，這就引出結構的問題。我們需要能夠對許可權控制策略進行有效的描述（控制策略的結構），並且決定如何與程式結構相結合。subject, operation和resource為了支援推理，都可能需要分化出複雜的結構，而不再是簡單的原子性的概念。而在與程式結構結合這一方面，雖然aop使得我們可以擴充套件任何函式，但這種擴充套件需要依賴於cutpoint處所能得到的資訊，因而許可權控制的有效實施也非常依賴於功能函式本身良好的設計。有的時候因為需要對結構有過於明確的假定，許可權控制的實現不得不犧牲一定的通用性。
下面我們將分別討論一下operation, subject和resource的結構分解的問題。首先是operation。
說到推理結構，讓人最先想起的就是決策樹，樹形結構，在物件導向語言中可以對應於繼承。金字塔式的樹形結構也正是在現實世界中我們應用最多的控制結構。通過層層分解，operation的結構可以組織為一棵樹,
應用程式 ==> 各個子系統 ==> 每個子系統的功能模組 ==> 子功能模組
==> 每個模組的功能點(具有明確的業務含義) ==> 每個功能點對應的訪問函式(程式實現中的結構)
乙個常見的需求是根據許可權配置決定系統選單樹的顯示，一般控制使用者只能看到自己有權操作的功能模組和功能按鈕。這種需求的解決方法是非常直接的。首先，在後台建立子系統到功能模組，功能模組到功能點以及功能點到實現函式之間的對映表（如果程式組織具有嚴格規範，這甚至可以通過自動蒐集得到）。然後，在許可權配置時建立使用者與功能點之間的關聯。此時，通過乙個檢視，我們就可以蒐集到使用者對哪些功能模組具有訪問許可權的資訊。
為了控制選單樹的顯示，witrix平台中的sitemap採用如下策略：
1. 如果使用者對某個子功能具有操作許可權，則所有父選單項都預設可用
2. 如果使用者對某個功能具有操作許可權，並且標記為cascade，則所有子選單項都自動預設可用
3. 如果明確指定功能不可用，則該選單及子選單都強制不可用
4. 如果明確指定功能對所有人可用，則不驗證許可權，所有子選單自動預設可用
4. 強制設定覆蓋預設值
5. 不可用的選單預設不可見
6. 明確標記為可見的選單即使不可用也可見
7. 父選單可見子選單才可見
我們通過預計算來綜合考慮這些相互影響的控制策略。盡量將推導運算預先完成也是解決效能問題的不二法門。
在witrix平台中，每一次網路訪問的url都符合jsplet框架所要求的物件呼叫格式，需要指定objectname和objectevent引數，這就對應於功能點的訪問函式。訪問控制點集中在objectmanager並且訪問格式是標準的。使用spring等aop方式實現細粒度訪問控制，困難似乎在於不容易引入外部配置資訊（例如功能點資訊等），而且控制點所對應的物件函式格式也不統一，因而多數需要在細粒度上一一指定。
系統設計 許可權模型設計
該許可權資料模型設計依據spring security框架，針對賬號 角色 許可權 資源 模組 選單 等物件做了簡單設計 指系統登陸賬號，系統使用者物件身份標識。只使用者的身份象徵標識，乙個登陸賬號，可同時擁有多個系統使用角色 身份 比如在網購 當中，使用者同時擁有a資源管理員角色 b資源管理員角色...
許可權設計 系統登入使用者許可權設計
需求分析 場景 假設需要為公司設計乙個人員管理系統，並為各級領導及全體員工分配系統登入賬號。有如下幾個要求 1.許可權等級不同 公司領導登入後可檢視所有員工資訊，部門領導登入後只可檢視本部門員工的資訊，員工登入後只可檢視自己的資訊 2.訪問許可權不同 如公司領導登入後，可檢視員工薪水分布介面，而員工...
GIS系統許可權設計
各種軟體系統中，許可權管理是乙個很重要的內容。通過許可權的管理來限定使用者使用軟體功能，約束使用資料的權利，在gis系統中，還需要約束使用者使用資料的範圍，例如 上級領導可以檢視全市的設施的分布情況，而東城區的技術人員只需要關係本區的設施情況，而不需要關注西城區的設施分布。許可權比較通用的做法採用 ...