用细粒度的Action做为你的系统权限

1.acegi提供了可配置的voter,一个验证请求交由多个voter进行处理,已经提供了roleVoter.可以加入自定义的voter来处理.

2.什么是嵌入权限?

3.我想假如后台需要为多个前台,或者是未来的前台服务的时候,也才有必要引入这种复杂性.

我也是看看,没应用过,有什么不对之处,还望海涵.

不管在是在service还是action加权限验证，实际是RBAC模块是可以分离的，我在去年的时候完成了这个模块，然后项目的时候只要把这个模块加进去就可以了。如果实际项目是可以通过url来控制权限的，那么就可以不用写一行代码。 在RBAC模块里完全可以做到很细的控制。
资源概念(可以是url，还有刚才看到有人说.do后面的参数那不到，参数当然可以拿的的,只不过url被切分成两部分而已，一部分就是参数.可以通过getQueryString得到)
资源就是想要的到的最终物质,我们可以给每一个资源定义一个权限，也可以给某一类资源定义一个权限,而web项目 url的tree特别容易用来管理资源。资源是一棵树,如果你有管理树根的权限那么就有了这颗树的所有权限。
权限概念
权限是对资源的一种保护访问.用户要访问A资源前提是用户必须有A资源的访问权限.
角色概念
实事上我们不会直接把权限赋予给用户，而是通过角色来赋予给用户,因为用户拥有某一种权限是因为用户扮演着某一种角色。
A是个经理,他管理着B公司,他拥有b,c,d的权限。实际是不是A有这个权限，而是因为Abo是经理。因为经理拥有b,c,d权限
所以很显然在权限划分上，我们会把权限赋予给某一个角色，而不是赋予给个人。这样带来的好处是
如果公司换了经理，那么只要再聘用一个人来做经理就可以了，而不会出现因为权限在个人手里导致权限被带走的情况

分组概念(分组也是一棵树，用户就是这里的叶子)
只有角色是不够的，B公司发现A有财务问题成立了一个财务调查小组,然后我们赋予了这个小组财务调查员的角色(注意是赋予小组这个角色).这样这个小组的所有人员
都有财务调查的资格。而不需要给小组的每个人都赋予这个角色(实际上已经拥有了)，分组概念也适合部门，因为任何一个部门在公司里或者社会上都在扮演着一个泛的角色。
用户
用户一定是属于某一个分组的,不存在不属于分组的用户.不过用户可以直接扮演(获得)角色，或者通过属于的分组来得到角色
最后一个概念
判断用户有没有访问资源的权限就看这个用户有没有访问这个资源的权限,也就是说分组，分部门,分角色最终是以权限来实现对资源的访问控制

1.voter?在上述应用中,是否可以设想有一个voter,它所做的事情是否就是根据articleId从数据库取出article.author,与当前用户进行比对,如果相符就vote同意?

2.嵌入权限的意思就是,在系统设计之初不对权限做太多的设计,在系统的外部通过可配置的权限模块来给系统引入权限逻辑.

3.这个前台后台没有听太懂.
象上述作例子论坛这样的系统,没有特定的后台管理界面.版主,普通浏览者,匿名用户等等,所有用户都使用相同的界面.只是界面上显示的内容不同.比如,在一个看帖界面中,版主能看到删除链接,点击该链接能执行删除当前帖子的操作.但,匿名用户看不见删除链接,即使用户自己拼出删除链接,也不能执行删除操作.

继续探讨.

1.是
2.同意.
3.后台和前台不是你说的意思.是指如:
ServiceBeanA代表后台(相对稳定的一层).
ActionC,ActionD,ActionE代表前台,或者URLC,URLD,URLE.

我们可以仿造C/S的方式来解决这个问题。

interceptor所有动态页面访问，解析其中的链捷，并且设置为“有效的”。

这样，只需要设置一个初始页面，用户只能按照程序给的界面来操作，不可能直接通过url越过障碍。

应用系统的授权最好是针对界面的，这样对于用户来说，一目了然，容易使用。

对于分组的概念，我觉得是不是可以归并到角色中呢？比如创建一个角色：财务调查员，那么扮演了这个角色的用户不就自然的聚合到一起了么？为什么需要一个组呢？

对于这种虚拟组可以归并到角色，但是分组还是必须存在。实体分组情况就不能作为一个角色来处理。实体分组在现实中可以看作是部门间的层次关系。我们可以给一个分组赋予一个或者多个角色，这样就不需要给分组里的所有成员一个一个的赋予角色。而且如果是电子政务的，分组是必须的.

是的，这种虚拟的组是不必要存在的，通过角色来管理完全ok。当需要一个实在的组织机构的时候，出现的组的概念才是对的。

功能权限可以通过acegi来实现，而实例权限可以通过workflow来实现，这样不就行了么？何必要权限控制把工作流的工作一起做了？流程你可以不用，但是一样可以用他的权限控制阿

上面的各位大大说的都很有道理，看来这方面的经验大家还真不少呀。
不过我觉得那个voter的思想倒是有点意思的。

可以每一个voter实现一个权限交验，不用管是在什么action 还是service，反正就干他的交验就行了，这样在大体上好像能够实现同流程的分离。

但是一些数据提取从哪里来呢？给voter提供的交验模型从哪里来，数据从哪里来，怎么能实现可配置的交验，怎么才能从系统中最大程度的脱离出来呢？

不了解真正的voter，请各位探讨一下。