訪問控制組件的權限粒度及它和AOP的恩恩怨怨

看得人多re的人少，究其原因大約是讀者讀完以後就miss the point了,不知所云,何來回饋?
so here is the point:
[b]
1 訪問控制組件的開發在Action層打住還是往下到Service層?

2 是否還能往下到DAO?

3 將Action作爲權限元素管控的話,它跟HTTP POST/GET是一一對應關係嗎? 它跟URL是一一對應關係嗎?

4 AOP是服務性功能,資源樹(當然也可以是其他結構)沒有初始化之前,AOP無計可施[/b]

這幾天非常初略的看了一下Acegi，給出如上問題的如下答案，各位指正：
[color=darkred][b][size=medium]1 Acegi裏面沒有所謂的Action權限，要麼是Web資源，用antURL來進行標識；要麼就是業務方法，使用AOP驗證

2 沒有人這麼用過

3 論壇上Robin諸人是這麼用的，這裏有一個如何初始化Action資源的問題，以後詳細來討論

4 本來想用AOP驗證和授權web資源就是錯誤的想法[/size][/b][/color]


[size=medium]
就我的感覺設計一個基於RABC的訪問控制模型組件的難點不是User-Role-Permission等概念，而是怎樣定義和管理資源。
一種說法是：
如果要做一個通用的權限控制模型，由於針對不同的應用，項目中涉及到的資源各不相同，並且每一類資源上的操作也不一樣，因此需要抽象出Resource-ResourceType-Operation類出來，爲應用開發提供管理資源、資源類型以及定義在資源類型上的操作的接口。這樣一來靈活是靈活了,一切皆資源!!好處就是應用開發者可以自定義資源,壞處就是,應用開發者不得不自己定義資源.隨時而來的還有,需要爲每一類資源指定相關的一組操作,比如文件有執行/讀/寫/刪,頁面元素有顯示/隱藏/,你甚至可以吧領域對象作爲一個資源,或者領域對象的一個方法作爲一個資源,或者領域對象所在的包作爲一個資源...是不是有點靈活過頭了? 而且用戶真的需要知道這些嗎?

第二種說法:
將資源分爲功能性資源和數據性資源,頁面Page,頁面上的Action(也就是所謂的業務接口,針對用戶可見的.它實際上就映射到了頁面上的某一個或者一組元素,這個有空再討論)作爲功能性資源,是用戶用來進行權限配置的接口,用戶只需要瞭解到這一粒度的權限就可以了,那麼針對這個資源,其上的操作只有訪問這一種操作,要麼有要麼沒有,管理員(比較高級的用戶)給角色分配就好了,so simple.我們把這種權限分配通常叫做[b]前臺權限管控[/b].但是往往一個業務接口是由若干個領域對象的方法(在純OO模型下,如果是貧血的domain模型的話大約就是Service方法吧)組成的一個流程,前後分別是用AOP動態植入的權限驗證啊,日誌啊,連接的建立與釋放啊等等.其中每一個領域對象方法對應着一些數據的操作,無外乎CURD四個.那麼針對某一類數據(比如物料)或者某一個數據(料號爲ABC的物料,數據實例)的操作我們叫做數據性資源上的權限.當一個業務接口由A對象的create方法+B對象的Update方法組成的話,如果某用戶沒有對A數據的C(新建)權限,那麼此業務接口將不能得到執行,多麼強大啊!!問題是,除了用人眼看代碼,我怎麼能知道業務接口調用了哪些領域對象的哪些方法呢? 雖然在邏輯上, page-Action-dominObject(PO)-domainObjectMethod(Service method)可以組成一個資源樹,父資源的權限可以通過子資源的權限計算得到,那麼如果我們將用戶的權限指定到最細的粒度上,那我們就能計算出某用戶針對此資源樹上所有的權限了.這個可以參見我的另外一個文章:[url]http://www.iteye.com/post/606826[/url].我們把這叫做[b]後臺權限管控[/b]但是實際上,我們沒有辦法初始化這顆權限樹啊!
這樣的情況下,AOP失效,爲什麼 ? 因爲AOP太早了.如果我不知道一個業務接口中到底調用了那些領域對象方法,我就不能找到這些領域對象方法資源的資源ID並傳給AOP,那麼AOP中的權限驗證接口方法通過什麼來判斷呢?


罈子裏面基本上所有有關RBAC的討論我都讀過了,針對Action做資源管控的或者繼續往下針對數據資源進行管控的都有,但是都沒有給出可行的方案或者結論.我考慮後臺權限管控的原因在於怕有人繞過UI,跳過業務接口直接調用領域模型的方法,但是轉念想想又可笑,那有人直接繞過應用操作數據庫呢? AC系統不是萬能,那麼他的系統邊界又應該如何定義呢?
[/size]