关于权限模块设计的一点思考

基本原则大家都是明白的吧；角色权限的模型RBAC相信大家也不会陌生；
所说页面/表单元素也是我们在讨论的需要进行实际控制的东东；
你说的太粗了些吧，希望可以至少简略描述一下；

我的思路,配置文件:role-cfg.xml

<roles>
  <role action="com.ayo.action.***//Action路径">
    <role method="方法名" role="权限 admin,client,...,..."/>
  </role>
<role action="....">
    ....
</roles>

Plugin配置文件到ServletContext;
BaseAction extends DispatchAction
execute:
   通过this.getClass().getName()匹配role-cfg.xml的action
   通过request.getParameter(mapping.getParameter())找到对应的方法
   与Session中的用户验证...跳转.....
所有Aciton继承BaseAction 需要权限控制的方法添加到<role/> 不需要额外编码了
写个方法重新加载role-cfg.xml,更改后就不需要重启服务器了
也可以不用DispatchAction,只是个简单的实现，呵呵，权当参考

个人觉得你说的不太对；
权限控制到url的话有点太粗了；
在页面上，对某些操作的可执行与否，一个好的权限系统应该是可以控制到的；当然，你可以说，执行到它后，最终应该还是一个url，但是，比如说含有超级管理员，他的可执行操作很多，全部显示，当一个普通操作者登陆后，我们也是同样全部展现，然后在他按下某个操作按钮后再进行判定他可执行与否吗？
个人觉得，应该要能控制到不同页面元素；
再者，权限系统，可以说是一个独立的模块，独立于具体项目之外的，可重用的，决不是说只适用于当前项目，绝不是你所说“花费80%的精力去提供10%的功能”。

你把ACL当成一个库使不就完了。
ACL ACL 想控制什么控制什么

简单点可以根据action来实现权限过滤，即操作

通过AOP来做

举例：
增、删、改、查4种操作权限
create,delete,update,read
统一使用Y/N来表示是否有权限
url统一按照规范
比如进入read页面，页面中包含了“新建”、“修改”、“删除”按钮，
在进入read的servlet之前调用权限过滤器，将CUD权限放入request，再通过统一标签对按钮或者超链接进行只读/不显示等处理。
需要经过权限过滤的就套用标签进行过滤，如果涉及了业务的话，就需要多种不同业务的标签（类似：能看到别人的数据，但是不能对别人的数据进行操作）。

我所说的只是针对项目应用，不针对理论性的东西
我认为权限是和功能对应的，而不是针对到URI和类上。如果一个用户拥有，例如：用户编辑的功能。可能使用多个类或者方法实现这一个功能，只有拥有用户编辑的功能，就不需要具体控制到哪个类或者方法是否能够访问。
我简单看了acegi和struts2的权限，里面的role几乎都是写死的。但是对于一个项目来说，role都是活的，允许客户可以维护。
所以我说上述实现方式只能是一个概念，而不能用于实际项目中。

其实是一个问题，就是权限粒度的细化，你目前是把url作为一个最小权限集，所以带来了以上的问题。

按你的业务要求，应该细化为更小粒度。

对的，
所有的讨论就是想找出一个能够应用于实际项目中的工具或框架或实现；
在配置文件等中写死role、permission等的配置，肯定是需要可配置，提供操控界面，没提供的话咱们利用它来做权限系统肯定也会修改完善至符合自己的需求；
概念你说了，真实项目应用的东西你还是没有说啊