canonical

      權限控制可以看作一個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方式實現細粒度訪問控制， 困難似乎在于不容易引入外部配置信息（例如功能點信息等），而且控制點所對應的對象函數格式也不統一，因而多數需要在細粒度上一一指定。