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

现在在进行系统的权限模块的开发，
已经建立了 user - role - permission 的关联规则，可以实现到url的控制；
问题产生，这样就要依赖url，而且可能会出现同一个url处理类中会包含处理多个业务的方法，这样就不能实现严格控制了，而且可能产生混乱，这是问题一；
问题二，如果我想权限控制粒度再细一点，比如能够控制到每个页面的每个按钮（操作），这样又该符合设计呢？

权限的控制问题应该在大部分的web程序中都会使用到的吧，
还请诸位不吝指点几句

评论

53 楼 andy54321 2009-01-05  

precom 写道

如果要控制到按钮，说明这个界面有多个按钮，何不把它们拆分为几个窗口呢？ 程序一样，但在进入各自窗口时，传入参数不一样，不增加代码，只增加菜单，把按钮变为菜单。

有道理，可以更改部分按钮为菜单；
不过有的不行，比如某个的管理页面，页面中可能存在，分别选中一些记录，进行修改/删除等操作；如果都改成菜单的话，叶面可能冗余了一点。。。。

52 楼 precom 2008-12-31  

如果要控制到按钮，说明这个界面有多个按钮，何不把它们拆分为几个窗口呢？ 程序一样，但在进入各自窗口时，传入参数不一样，不增加代码，只增加菜单，把按钮变为菜单。

51 楼 crabboy 2008-12-31  

jander 写道

看看spring security, 它都给你解决了。
虽然有点繁琐。

spring security 2.0 配置好多了。

50 楼 wumingsx 2008-12-31  

我用的是拦截器,标签,把权限定位到方法级别...

49 楼 andy54321 2008-11-04  

haole 写道

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

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

48 楼 gujianxin 2008-11-04  

andy54321 写道

现在在进行系统的权限模块的开发，
已经建立了 user - role - permission 的关联规则，可以实现到url的控制；
问题产生，这样就要依赖url，而且可能会出现同一个url处理类中会包含处理多个业务的方法，这样就不能实现严格控制了，而且可能产生混乱，这是问题一；
问题二，如果我想权限控制粒度再细一点，比如能够控制到每个页面的每个按钮（操作），这样又该符合设计呢？

权限的控制问题应该在大部分的web程序中都会使用到的吧，
还请诸位不吝指点几句

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

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

47 楼 haole 2008-11-04  

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

46 楼 寄生虫 2008-11-04  

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

45 楼 taupo 2008-11-04  

通过AOP来做

44 楼 ferreousbox 2008-11-03  

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

43 楼 guooscar 2008-11-03  

andy54321 写道

blueblood 写道

hi all: 看见大家提出了很多技术上的解决办法，呵呵，实在忍不住想说两句。我在公司就是维护权限系统的。我个人认为，权限系统控制到url这个粒度就可以了。再往下控制可以交给其它系统来解决。
    你能做到多细了？你可以控制按钮，那你需不需要控制链接了？如果不同的角色，看到的下拉列表框不同，你需要控制吗？如果不同的角色需要看到的列表数据也不同，你需不需要控制了？业务需求是多变的，你能满足多少了？再则，你花费80%的精力去提供10%的功能是否值得？
   
   

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

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

42 楼 andy54321 2008-11-03  

blueblood 写道

hi all: 看见大家提出了很多技术上的解决办法，呵呵，实在忍不住想说两句。我在公司就是维护权限系统的。我个人认为，权限系统控制到url这个粒度就可以了。再往下控制可以交给其它系统来解决。
    你能做到多细了？你可以控制按钮，那你需不需要控制链接了？如果不同的角色，看到的下拉列表框不同，你需要控制吗？如果不同的角色需要看到的列表数据也不同，你需不需要控制了？业务需求是多变的，你能满足多少了？再则，你花费80%的精力去提供10%的功能是否值得？
   
   

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

41 楼 sgysgy 2008-11-03  

我的思路,配置文件: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,只是个简单的实现，呵呵，权当参考

40 楼 andy54321 2008-11-03  

ayaya 写道

基本原则还是采用角色权限的方法：Function -- Role -- User；
可以将需要管理的页面和表单元素作为最基本的颗粒：Url-->Page-->Elements;

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

39 楼 andy54321 2008-11-03  

zxming12345 写道

说一下第二个问题：

第二个问题，我们系统中是这样解决的：

操作是树形的，权限也是树形的。
举个例子，url1 是跳转到一个页面，url1可以分配权限。
这个url的页面中，其实也可以通过树形，配置功能点，这些功能点，也有url。

在页面中，写一个permision的tag，页面中的链接，写在这个tag中。这个tag就去功能树上判断当前用户有没有这个url的权限，如果有，这个链接就打出来，如果没有，这个链接就不大出来。

还有，我们系统中，还有对数据库中表和字段的权限设置。

我们需要维护一个数据字典，建表的时候，并不是直接在数据库中建表的，而是通过数据字典这个功能点建表的。

查询的时候，我们通过数据字典，封装了查询，这样在开发查询的时候，可以通过配置得到查询结果，而不用写sql了。比如首先选择查询的表，然后设置表之间的连接关系，然后可以在页面设置查询条件，分组，排序统计，最好向数据库存储一个查询。当调用查询的时候，就可以通过这个查询id 得到查询结果。
     我们可以通过数据字典，为每个用户配置每个表和每个字段的权限，当通过查询id得到查询结果的时候，就可以通过权限，判断改用户有没有对这个表的查询权限，如果有，再判断该用户没有对配置的查询的字段的权限，这是，如果一个字段，这个用户没有权限，那么，查询结果中就不包括这个字段，这样就实现了对表、字段的权限。而且简化了开发。因为sql不用写了，在页面配置一个查询就可以了。

我跟根据这个查询，还写了很多标签，比如，通过查询id 就可以利用标签，打印出列表等。列表后面的操作，也是可以配置的。这些操作，当然也会收url权限的控制。

说的很不错，如果关于你的“对数据库中表和字段的权限设置”解释的再详细一点就好了；
按你所说，可以通过配置的形式对查询模块的开发可以做到权限的严格控制，应该可以实现多样化了，不过看了解释有些不是很明白；

38 楼 philip01 2008-11-02  

spring security acegi
他有一个jsp标签,有权限就显示,没有权限就不显示,
但有的点繁琐，是非常繁琐，感觉太庞大了,但是可以有
解决你的问题

37 楼 amonlei 2008-11-01  

andy54321 写道

现在在进行系统的权限模块的开发，
已经建立了 user - role - permission 的关联规则，可以实现到url的控制；
问题产生，这样就要依赖url，而且可能会出现同一个url处理类中会包含处理多个业务的方法，这样就不能实现严格控制了，而且可能产生混乱，这是问题一；
问题二，如果我想权限控制粒度再细一点，比如能够控制到每个页面的每个按钮（操作），这样又该符合设计呢？

权限的控制问题应该在大部分的web程序中都会使用到的吧，
还请诸位不吝指点几句

每种类型的项目对权限的粗细粒度要求不一样，想做通用，不太可能。你应该瞄准一个特定领域进行设计。 

36 楼 wyz191 2008-11-01  

andy54321 写道

问题二，如果我想权限控制粒度再细一点，比如能够控制到每个页面的每个按钮（操作），这样又该符合设计呢？

整一个标签,用于判断某个用户是否拥有操作某项业务的某个权限<判断用户A是否拥有对模块A的"添加"/"编辑"/"删除"/"查看"的权限>,如果用户拥有就让页面显示相关按钮,如果没有此权限就不让它显示即可<用标签控制>;页面实现如下所示:
<compe:competence compValue="" compName="删除" adminsInfo="${adminInfo}" serviceTypeId="${serviceId}">
<a href="javascript:check('delete');">删除</a>&nbsp;&nbsp;&nbsp;&nbsp;
</compe:competence>

不知道这样是否可行

35 楼 jander 2008-11-01  

fuwang 写道

jander 写道

有这么复杂吗？
简单的权限用RBAC解决。复杂的用ACL解决。
应该是现在的标准吧。
这两个决定了谁有权限，然后用filter(web),aop(Class method)两头一截。ok。

那你是怎么让filter过滤的url和aop拦截的类的方法名做到对应的？专门建表维护这个关系？
比如 "user.do?do=delUser&userid=23" 这个url，aop要拦截的类的方法是Action类的delUser(request,response,...)方法呢还是Service类的delUser(Long id)方法?
我觉得用filter过滤url，同时对界面的按钮和菜单做到所见即所得，不就满足要求了(其他的特殊权限当作业务逻辑)，为什么要同时使用filter和aop呢?

在Service中检查，因为不仅仅考虑web，还要考虑远程调用。

Service中对应的方法：
read(Document doc)
write(Document doc)
aop检查客户是否具有该doc的对应权限。

我在filter仅仅简单的检查客户是否具有某个目录的权限。

34 楼 fuwang 2008-11-01  

jander 写道

有这么复杂吗？
简单的权限用RBAC解决。复杂的用ACL解决。
应该是现在的标准吧。
这两个决定了谁有权限，然后用filter(web),aop(Class method)两头一截。ok。

那你是怎么让filter过滤的url和aop拦截的类的方法名做到对应的？专门建表维护这个关系？
比如 "user.do?do=delUser&userid=23" 这个url，aop要拦截的类的方法是Action类的delUser(request,response,...)方法呢还是Service类的delUser(Long id)方法?
我觉得用filter过滤url，同时对界面的按钮和菜单做到所见即所得，不就满足要求了(其他的特殊权限当作业务逻辑)，为什么要同时使用filter和aop呢?