我对项目可能存在的权限需求的分类

很早就完成了权限系统的编码，在实现过程中对可能存在的权限需求进行了分类，也希望提提意见。
  一是系统权限，主要是对模块为单位的权限划分，具体就是用户对该模块可见不可见，能不能对该模块进行再授权的操作。表现在用户界面就是用户登录系统主页面后，可以看到的顶部菜单和左侧outlookbar菜单的内容控制。它是粒度最大的权限控制。
  二是模块操作权限，在对整个模块的权限做出控制后，这里继续对模块的浏览、增加，修改，删除的操作权限做出控制，也可以理解为对象权限 。还是以车辆管理为例，不同的人员对这个模块的操作是不同的，有些用户可以新增，删除车辆；而有些用户则只是可以对车辆的情况查看不能修改。
  三是数据范围权限，又可以叫做对象实例级权限。事实上不是每个用户都可以看到所有记录的。以财务管理为例，部门经理只能查看金额小于1W的数据；而总经理则没有限制。数据根据其类型，相应字段数值范围划分为不同的区域。不同的人拥有不同的区域查看权限。
  四是单条数据ACL权限，具体说就是对每条数据都要实现权限控制，每条数据都有一到多条权限数据与其对应。以个人通讯录为例，每个用户都维护自己的一个通讯录，这些数据都只是对本人可见，其他人不可见。但用户可以对这些数据做出授权，将某条联系方式以授权的方式共享给其他人，并赋予不同的权限，包括拥有，修改，删除，浏览四种权限。
  五是数据字段权限，这也是用户的最小粒度的权限控制。每条业务数据权限可以精确控制到每一个字段。包括单个字段的可否浏览以及可否修改。
  六是数据范围操作权限，其实这个是可以和数据范围权限合为一个的。具体的区别在与对已经划分范围的数据再增加操作的权限控制。还是以财务管理为例，部门经理只能查看金额小于1W的数据；而总经理则没有限制，可以查看所有数据。但是请注意：他们只能对这些数据拥有查看的权限，不能修改或是删除，而财务则拥有修改的权限。在一些情况下可以用模块操作权限和数据范围权限的叠加来满足对该权限的需求，但是在权限复杂的情况下，这个权限独立出来是必须的。

评论

21 楼 dada 2007-03-21  

ronghao 写道

这个你可以考虑给这些hql片段加个标识字段，标识这几个HQL片段是和那些业务挂钩的。在我的实现中是给它们增加了个domain classname.我想这应该不是难事，你可以单独出一个xml来配置这个东西，如果你实现页面配置到数据库中比较麻烦的话

事实上有类似的标示，但是控制的地方太多了，造成了混乱。

我这里举另外一个曾经的项目来做例子吧，那个项目的权限比较简单，只需要根据分公司和使用人员的职位来过滤数据。hibernate filter能够很好的满足这个需求，俺希望现在这个系统可以趋向于这种入口简单，修改也简单的方式。

20 楼 ronghao 2007-03-21  

dearwolf 写道

acegi做ACL的支持现在已经很方便了么？

http://www.iteye.com/my_topic/63047

19 楼 ronghao 2007-03-21  

这个你可以考虑给这些hql片段加个标识字段，标识这几个HQL片段是和那些业务挂钩的。在我的实现中是给它们增加了个domain classname.我想这应该不是难事，你可以单独出一个xml来配置这个东西，如果你实现页面配置到数据库中比较麻烦的话

18 楼 dada 2007-03-21  

ronghao 写道

我大概明白你的意思了，这些HQL片段有些是对应这个业务接口的，比如说用户信息管理对应一些HQL片段，财务信息管理又对应另外一些HQL片段，是这个意思吗？

确实如此，无法抽出共有的部分。我只是描述了项目的一个方面，其实还有很多方面需要这样控制的。

17 楼 ronghao 2007-03-21  

我大概明白你的意思了，这些HQL片段有些是对应这个业务接口的，比如说用户信息管理对应一些HQL片段，财务信息管理又对应另外一些HQL片段，是这个意思吗？

16 楼 ronghao 2007-03-21  

dada 写道

每个需要控制权限的接口为了权限都在数据库中实现了特定的hql片断以供修改hql语句。乍看之下整个系统的权限是实现了七七八八了，但是有以下几个硬伤：
1.如果某个接口的实现方法改变(特指hql发生了改变)，可能需要去数据库修改权限对应的hql片断，开发人员很不方便。
2.虽然由数据库维护了权限的控制，但是事实上这块的权限和业务高度耦合，不能指望维护人员能够修改什么，甚至开发人员自己来维护的时候也异常麻烦。

为什么需要去数据库修改权限对应的hql片断呢？不能动态修改吗？我刚才也提到了一个大的抽象的资源类，它的作用就是把这些hql片断重新以某种方式组合，同时它的另外一个作用就是实现权限和业务的解耦，它上面可以再增加一个接口，可能是这样一个方法 QueryObject getAuthQueryObject(Principal p);传入当前用户信息，返回他有权限的资源（这里是重新组织过的HQL），然后你AOP业务方法，前拦截把这个QueryObject处理到你的业务hql中去

15 楼 dada 2007-03-21  

ronghao 写道

我觉得你虽然描述的比较复杂，但问题的关键还是很清晰，谁（某渠道某分公司的管理角色，某分公司总管）拥有什么样的数据范围权限。而所谓的数据范围无非是在所有记录上以一定规则划分出不同的区域，这个划分目前是以特定的hql片断来实现的。你完全可以把这些hql片断以资源的方式管理起来，根据用户的角色分配不同的资源（这里可以理解为不同的hql片断）。由这些资源构成一个大的抽象资源（因为这些不同的hql片断可能会重复，可能会互相影响），最后再去和业务数据打交道（这里你采用的是动态添加hql语句）。说的很拗口

你描述的这些部分已经都实现了，我主要想要知道的是你如何看待或是解决我下面说的硬伤部分(主要是针对特定的接口实现特定的hql片断同直接把数据权限当作业务逻辑的一部分有什么区别呢？除了留下来一个看上去很美的统一管理的途径)。

14 楼 ronghao 2007-03-21  

dada 写道

ronghao 写道

老实说这个实现是有限制的，就是Criteria的封装，动态改变SQL语句的条件。但我并不认为复杂业务逻辑就一定不能处理的。你可以举个例子：）

举例如下：
某公司的雇员有内部雇员和外部雇员2类雇员。内部雇员即所谓的内勤人员，外部雇员(也称渠道人员)一般是跑业务和市场开拓的(有很多分类)，我们把外部雇员的不同分类称之为不同的渠道。
行政架构(DIVISION)维系总公司和分公司之间的关系，内部雇员直接嫁接在行政架构上。
同时，为了保证外部雇员的干劲，在行政架构上我们添加了渠道组织架构(一般添加在行政架构的最底层，比如各分公司)。不同渠道的组织架构是不同的，渠道人员嫁接在该渠道的组织架构中。

权限需要做到的是：
某渠道某分公司的管理角色登入系统，只能看到该渠道该分公司下的渠道角色。
某分公司总管登陆系统可以看到该公司内部雇员以及某些特定渠道的渠道角色。
同时，要为以后外部雇员和内部使用系统预留接口，实现它们登陆只能看到自己的信息的功能。

现在的作法大体上是使用AOP拦截接口方法，动态添加hql语句，或是改变criteria的查询(整个系统中因为查询比较复杂hql使用的比例远大于criteria)，下面我用hql举例来阐述我的困惑。
每个需要控制权限的接口为了权限都在数据库中实现了特定的hql片断以供修改hql语句。乍看之下整个系统的权限是实现了七七八八了，但是有以下几个硬伤：
1.如果某个接口的实现方法改变(特指hql发生了改变)，可能需要去数据库修改权限对应的hql片断，开发人员很不方便。
2.虽然由数据库维护了权限的控制，但是事实上这块的权限和业务高度耦合，不能指望维护人员能够修改什么，甚至开发人员自己来维护的时候也异常麻烦。

------------------------- 数据权限的分割线 --------------------------

顺便谈一下显示权限，这里有一个比较变态的需求。
拿人员录入作例子，某分公司在不同年份中人员的可录入项目是不一样的。
这里的年份描述可能不尽清晰，我们可以把它理解成条例，比如某公司虽然在2007年但是他使用的是05年的条例，条例限制了他的可录入项。该分公司可能在年底整个系统往07年条例过渡，他们希望条例过渡时，录入项可以自动改变。

目前可行的方法是控制整个页面的可视化组件的权限(有页面可视化资源表对应)，根据条例动态渲染组件。

但是存在一个让我很不舒服的问题，当权限从系统中移除时这个页面效果惨不忍睹。有什么好的解决方法吗？

我觉得你虽然描述的比较复杂，但问题的关键还是很清晰，谁（某渠道某分公司的管理角色，某分公司总管）拥有什么样的数据范围权限。而所谓的数据范围无非是在所有记录上以一定规则划分出不同的区域，这个划分目前是以特定的hql片断来实现的。你完全可以把这些hql片断以资源的方式管理起来，根据用户的角色分配不同的资源（这里可以理解为不同的hql片断）。由这些资源构成一个大的抽象资源（因为这些不同的hql片断可能会重复，可能会互相影响），最后再去和业务数据打交道（这里你采用的是动态添加hql语句）。说的很拗口

13 楼 dada 2007-03-21  

ronghao 写道

老实说这个实现是有限制的，就是Criteria的封装，动态改变SQL语句的条件。但我并不认为复杂业务逻辑就一定不能处理的。你可以举个例子：）

举例如下：
某公司的雇员有内部雇员和外部雇员2类雇员。内部雇员即所谓的内勤人员，外部雇员(也称渠道人员)一般是跑业务和市场开拓的(有很多分类)，我们把外部雇员的不同分类称之为不同的渠道。
行政架构(DIVISION)维系总公司和分公司之间的关系，内部雇员直接嫁接在行政架构上。
同时，为了保证外部雇员的干劲，在行政架构上我们添加了渠道组织架构(一般添加在行政架构的最底层，比如各分公司)。不同渠道的组织架构是不同的，渠道人员嫁接在该渠道的组织架构中。

权限需要做到的是：
某渠道某分公司的管理角色登入系统，只能看到该渠道该分公司下的渠道角色。
某分公司总管登陆系统可以看到该公司内部雇员以及某些特定渠道的渠道角色。
同时，要为以后外部雇员和内部使用系统预留接口，实现它们登陆只能看到自己的信息的功能。

现在的作法大体上是使用AOP拦截接口方法，动态添加hql语句，或是改变criteria的查询(整个系统中因为查询比较复杂hql使用的比例远大于criteria)，下面我用hql举例来阐述我的困惑。
每个需要控制权限的接口为了权限都在数据库中实现了特定的hql片断以供修改hql语句。乍看之下整个系统的权限是实现了七七八八了，但是有以下几个硬伤：
1.如果某个接口的实现方法改变(特指hql发生了改变)，可能需要去数据库修改权限对应的hql片断，开发人员很不方便。
2.虽然由数据库维护了权限的控制，但是事实上这块的权限和业务高度耦合，不能指望维护人员能够修改什么，甚至开发人员自己来维护的时候也异常麻烦。

------------------------- 数据权限的分割线 --------------------------

顺便谈一下显示权限，这里有一个比较变态的需求。
拿人员录入作例子，某分公司在不同年份中人员的可录入项目是不一样的。
这里的年份描述可能不尽清晰，我们可以把它理解成条例，比如某公司虽然在2007年但是他使用的是05年的条例，条例限制了他的可录入项。该分公司可能在年底整个系统往07年条例过渡，他们希望条例过渡时，录入项可以自动改变。

目前可行的方法是控制整个页面的可视化组件的权限(有页面可视化资源表对应)，根据条例动态渲染组件。

但是存在一个让我很不舒服的问题，当权限从系统中移除时这个页面效果惨不忍睹。有什么好的解决方法吗？

12 楼 ronghao 2007-03-20  

老实说这个实现是有限制的，就是Criteria的封装，动态改变SQL语句的条件。但我并不认为复杂业务逻辑就一定不能处理的。你可以举个例子：）

11 楼 dada 2007-03-20  

ronghao 写道

很早就完成了权限系统的编码，在实现过程中对可能存在的权限需求进行了分类，也希望提提意见。

  三是数据范围权限，又可以叫做对象实例级权限。事实上不是每个用户都可以看到所有记录的。以财务管理为例，部门经理只能查看金额小于1W的数据；而总经理则没有限制。数据根据其类型，相应字段数值范围划分为不同的区域。不同的人拥有不同的区域查看权限。

能详细谈一下在复杂业务逻辑的情况下这个是如何实现的吗？

10 楼 tmh 2007-03-20  

分析的挺好的，只是太少了！

9 楼 dearwolf 2007-03-20  

acegi做ACL的支持现在已经很方便了么？

8 楼 LucasLee 2007-03-20  

ronghao 写道

Lucas Lee 写道

看来你们的权限系统比较丰富,比较典型.
不过我认为你总结得还不够,各种情况是抓住了,但是它们之间的关系还需要整理.

我认为可以总结为两大类权限:
1.功能权限.
  对某功能是否具有执行的权限,结果只有是和否(这就是其本质特征).
  但具体一个功能,可以由多个参数组合,比如URL地址加若干QueryString参数.
2.数据范围权限
  定义可以访问(查询、修改、删除等)的数据的范围，结果是一个记录集合。

你提及的一些权限可以由功能权限和数据范围权限组合而来。

不错！确实抽象的很准确。也许可以抽象出两个统一的权限接口来:idea: 但我这样的分类其实也代表了各类权限所对应的不同处理方法。我是在acegi的基础上做出的扩展。
一是系统权限，用到acegi的web filter 拦截模块url
二是模块操作权限,用到acegi的mothed aop 拦截业务方法，同时加了一套web标签完成页面相应button的隐藏
三是数据范围权限，因为使用hibernate，所以构造了QueryObject对象其实是对Criteria的封装，在用户执行查询时拦截查询方法，改变sql语句条件
四是单条数据ACL权限，用到acegi的acl,对权限的增删改查做了封装，同时我也认为acegi的acl还有很多的扩展可以挖掘，例如所谓大集中模式下的部门数据权限。
五是数据字段权限，每个页面配置了一个xml，在xml里对字段权限做出限定，修改webwork标签，根据xml渲染字段 

你这么实现，似乎比较复杂。过于复杂。

7 楼 giscat 2007-03-20  

权限模型建议不要设计的过细
  控制粒度尽量大一些
    目录级的，url级的，action 级的一般都能满足要求
      粒度过细，控制麻烦，耦合紧密，吃力不讨好地
 

6 楼 ronghao 2007-03-20  

Lucas Lee 写道

看来你们的权限系统比较丰富,比较典型.
不过我认为你总结得还不够,各种情况是抓住了,但是它们之间的关系还需要整理.

我认为可以总结为两大类权限:
1.功能权限.
  对某功能是否具有执行的权限,结果只有是和否(这就是其本质特征).
  但具体一个功能,可以由多个参数组合,比如URL地址加若干QueryString参数.
2.数据范围权限
  定义可以访问(查询、修改、删除等)的数据的范围，结果是一个记录集合。

你提及的一些权限可以由功能权限和数据范围权限组合而来。

不错！确实抽象的很准确。也许可以抽象出两个统一的权限接口来:idea: 但我这样的分类其实也代表了各类权限所对应的不同处理方法。我是在acegi的基础上做出的扩展。
一是系统权限，用到acegi的web filter 拦截模块url
二是模块操作权限,用到acegi的mothed aop 拦截业务方法，同时加了一套web标签完成页面相应button的隐藏
三是数据范围权限，因为使用hibernate，所以构造了QueryObject对象其实是对Criteria的封装，在用户执行查询时拦截查询方法，改变sql语句条件
四是单条数据ACL权限，用到acegi的acl,对权限的增删改查做了封装，同时我也认为acegi的acl还有很多的扩展可以挖掘，例如所谓大集中模式下的部门数据权限。
五是数据字段权限，每个页面配置了一个xml，在xml里对字段权限做出限定，修改webwork标签，根据xml渲染字段 

5 楼 抛出异常的爱 2007-03-20  

Lucas Lee 写道

看来你们的权限系统比较丰富,比较典型.
不过我认为你总结得还不够,各种情况是抓住了,但是它们之间的关系还需要整理.

我认为可以总结为两大类权限:
1.功能权限.
  对某功能是否具有执行的权限,结果只有是和否(这就是其本质特征).
  但具体一个功能,可以由多个参数组合,比如URL地址加若干QueryString参数.
2.数据范围权限
  定义可以访问(查询、修改、删除等)的数据的范围，结果是一个记录集合。

你提及的一些权限可以由功能权限和数据范围权限组合而来。

1用ldap可以只改webxml
2作为一种需求作在SQL中去....

4 楼 fly_ever 2007-03-20  

这个权限分析得够细的了，不过要控制数据字段和数据范围的功能操作权限，实现起来应该很复杂的。不知道用的是什么样的方法。

3 楼 dearwolf 2007-03-20  

数据字段的控制要做起来就很复杂了

2 楼 LucasLee 2007-03-20  

看来你们的权限系统比较丰富,比较典型.
不过我认为你总结得还不够,各种情况是抓住了,但是它们之间的关系还需要整理.

我认为可以总结为两大类权限:
1.功能权限.
  对某功能是否具有执行的权限,结果只有是和否(这就是其本质特征).
  但具体一个功能,可以由多个参数组合,比如URL地址加若干QueryString参数.
2.数据范围权限
  定义可以访问(查询、修改、删除等)的数据的范围，结果是一个记录集合。

你提及的一些权限可以由功能权限和数据范围权限组合而来。