访问控制组件的权限粒度及它和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]