请问这样的细粒度权限能否用acegi实现？

我还不太懂通用的权限设计，不过说到一般的web系统的权限来说，往往是针对某种业务操作来实施的，例如XX角色是否可以做XX事情，这个XX事情和业务bean有一定的对应关系，但不是很明确的对应，特别是不可能清晰的对应到XXbean的XXmethod的权限控制上，事实上这种对bean方法的权限控制并不适合通常的应用系统对应权限控制的场景。

在这种情况下，权限不应该施加在业务bean上面，而是应该在Web Action层提供控制，由Action来根据上下文来自行决定是否当前session用户能否访问，还是拒绝。这个时候可以维护一张role和业务操作的权限表放在缓存中，以备查询。

对于AJAX或者Flash RIA应用来说，由于涉及到分布式调用，则不应该直接暴露业务bean，而是应该提供一层特殊的业务层facade，这个时候，权限在这层facade来实现，方法则同上。

总之，针对web应用程序的业务逻辑级别的权限控制，我的观点是在web层和业务层facade实施，而不应该针对业务bean去做。另外我也不太理解Acegi搞那么复杂究竟是为什么？而且我也想像不出Acegi可以解决我说的这种权限控制方式(也许我对Acegi还不熟悉)。

robbin提到的“维护一张role和业务操作的权限表”正是acegi的核心实现，强烈建议robbin了解一下。

其实acegi并不复杂，可以说实际上很简单。所谓复杂就是在多种环境下实现安全框架，核心的安全校验无非就是url过滤和业务方法拦截....

不知道acegi能不能实现批量对象的数据权限，最常见的就是读操作
例如对O查询时，除了输入的各种条件外，A角色还另外受限制只可以看O.type = 1, 而B角色则是O.type = 2 and O.subType > 10的。数据量大，不可能一个个读出来判断的，只能在发送给db的sql进行处理，产生合适的sql。如果acegi可以实现，我想知道它是怎么做的。

我实现这样的通用数据权限框架是借助我的框架http://bba96.dev.java.net，通过aop，可以对未知细节的复杂的query对象进行动态改变。

我看到你贴的示例代码是针对yourpackage.MoneyManager.appropriatingFunds这个业务bean的method级别的拦截。而我想表达的含义是，权限控制的业务操作不是具体的xxClass的xxmethod，而应该是一个符合业务含义的抽象定义，例如：拨款，划帐，审批，。。。等等。这样抽象业务逻辑定义最终是由Web Action来调用一系列业务bean来完成的，但是这些抽象业务逻辑定义既没有和业务bean有直接的对应关系，和Web Action的对应关系也很松散。因此，权限控制表(角色和抽象业务逻辑的权限查找表)和业务bean可以说没有任何对应关系，权限控制不应该在业务bean的method这种粒度上展开。

我认为合理的控制方式是在Web Action来进行拦截(本质上等于基于URL的控制)，Action去实现一个权限接口：

public class XXXAction implements hasPermission {
    public boolean authenticate() {
        ...
    }
}

由Action去实现hasPermission 接口的authenticate方法，在该方法中，Action自己根据应用上下文来判断是否应该具备权限。一般来说，Action从Session中取得用户标示，从而得到角色Role，另一方面Action要隐含的自己确定知道自己是属于哪个抽象业务逻辑的，然后根据这些信息查找全局Cache中的权限对应表，就可以确定是否有权限操作了。

至于Action和抽象业务逻辑的对应关系，可以放在外部配置文件中配置，也可以保存在数据库中进行修改，但是我觉得这样做有缺陷，例如如果Action中包含了工作流或者页面流，即使同样的Action URL，也可能具备不同的权限可能性。

考虑到权限的需求变化太大，我觉得在Action中暴露hasPermission 接口，把具体的工作推给Action自己去决定是最明智的，也是适用性最广的。

这种情况我觉得应该在业务bean接口上传入role参数，而不适合使用AOP隐式的代入其他条件。这和分页是一个道理。

然后Action在调用该业务bean之前，从Session中取得用户标示，获得role，再作为参数调用该业务bean。

这个跟分页还是很大区别的吧。分页逻辑比较简单（简直就是没有逻辑，只是两个参数），role就涉及到太多了，权限类型都还可以分为允许/限制等等，而且根据资源不同还可能有扩展。使用aop就是为了统一处理，不需要把role的影响散布到每个业务中。

恰恰相反,  我认为这个 hasPermission 接口是对业务代码的侵入,  如果 hasPermission 方法中只是 资源 - 角色   的映射, 那么相对而言 url 拦截具有的优势有:

1. 统一的维护便利性 (只需要维护后台资源权限数据即可)
2. 对业务代码无侵入

两种方案的差别类似于事务管理中的 编程式事务管理 和 声明性事务管理

如果涉及到实例级权限控制,  现在的主流做法还是在业务中编码实现, 如果如以上各位所述 aop 可以实现,  应该是个不错的选择



我认为大多数人对 Acegi 都有些偏见,  如果稍微花点时间了解,  相信会改变看法,  正如上面某位仁兄所述, Acegi 的复杂度在于对多种环境的支持,  大多数应用也只是用到其中某些功能, 要做的只不过是把 example 的配置文件拷过来稍做修改 

其实说了半天， 俺的观点就是 : acegi 是一个高度可扩展, 可复用的 security framework

下载了你的开源框架，没找到你在哪里用AOP加入role的代码。权限确实适合用AOP去解决。

如果拿出来一个个比较acegi是没有问题的，但是要是够造query查询，acegi可就不方便了，不是做不到，而是入侵太大，现在acegi的设计力求插拔。也就是拿掉acegi整个系统就没有安全限制了，而且你说的有点像是业务逻辑，入侵系统尤其是入侵SQL用acegi来说总是有点不合适的。

对URL拦截做起来当然更简单，但是问题对于那些工作流，页面流来说，即使是同一个URL，由于状态流转在不同步骤，也需要代表不同的权限，这个时候URL拦截就无效了。做法可以是这样的：

先使用URL拦截的方式去对付大多数的情况，然后少数URL搞不定的再加一个接口，让Action自己去判别。这样用两个拦截器对Action进行拦截，如果Action实现了hasPermission接口，那么就交给Action自己判断，如果Action没有该接口，就查找内部的URL和权限的对照表来判断。

我确实不了解Acegi，但是我觉得有一个基本原则，就是一般应用程序的权限判断应该在web层控制，我看了好几个Acegi示例，都是对业务bean的method进行拦截和权限控制。对业务bean的method进行权限控制，首先粒度就有问题，大多数情况下粒度太细，但有些情况又可能太粗。其次，权限判别完成以后，如果权限拒绝，你怎么把信息有效的传递给Web层和其他的Facade层进行用户友好性的提示处理？如果直接断掉调用链，Web层调用到这里突然就没有任何反应了；如果抛出运行期异常(也只能抛运行期异常)，Web层未必能够清楚的了解到究竟会出现哪些和权限有关的异常，那么大量使用try catch去捕获处理，代码就会非常烦琐。考虑到权限控制往往和用户交互非常紧密，因此应该尽量往前推到用户交互层去做，而不是底层。而且很多系统需要根据权限不同，生成不同的UI组件(例如管理员的菜单和普通用户菜单就肯定不一样)，这也需要在Web层的View进行控制。

总之，我到不是对Acegi有什么偏见，我希望看到的是Acegi对Web Action的权限控制示例，而不是对业务bean的method级别控制，但是还没有看到任何这样的示例。