讨论《细粒度的Action实现系统权限》帖子

最新推荐文章于 2022-03-03 08:43:10 发布

wangjbao1

最新推荐文章于 2022-03-03 08:43:10 发布

阅读量183

点赞数

文章标签： Acegi Spring Oracle Tivoli 配置管理

讨论《细粒度的 Action 实现系统权限》帖子

帖子地址： http://www.iteye.com/topic/10400?page=1

关键字： Action ，细粒度权限，实例权限， Module ， RBAC ， queryString ， Acigi ， Voter

引题

在 Struts ， WebWork 这样的系统中，会按照每个细粒度功能定义 Action 。比如：

客体（资源）	Action	功能
用户	ListUserAction	查询用户
	RemoveUserAction	删除用户
	ModifyUserAction	修改用户信息
	CreateUserAction	添加用户

看！这样 Action 就相当于客户（资源）＋操作了！！！

对 Action 使用 RBAC 策略，就可以控制某些用户能增、删、改和查，而另一些却只能查、改等等权限。

eway 说“笔者 eway 已经在一个小项目中采用了这个办法，效果还好。不妨试试，说不定收到意象不到的好处。”

讨论

定义 Module 抽象层

robbin 说“用户管理功能可能要对应六七个相关的 Action…… 所以我觉得在 Action 上面再抽象出来一层 Module ，针对 Module 设置权限比较好。”

分组概念

jjw 说道“ 分组概念 ( 分组也是一棵树，用户就是这里的叶子 )
只有角色是不够的， B 公司发现 A 有财务问题成立了一个财务调查小组 , 然后我们赋予了这个小组财务调查员的角色 ( 注意是赋予小组这个角色 ). 这样这个小组的所有人员
都有财务调查的资格。而不需要给小组的每个人都赋予这个角色 ( 实际上已经拥有了 ) ，分组概念也适合部门，因为任何一个部门在公司里或者社会上都在扮演着一个泛的角色。”

定义接口，注入 SecurityService

思想如下：需要权限判断的 Action ，必须实现 Protected ，以便和不需要权限判断的 Action 区别开。 Protected 定义了权限判断方法， Action 必须实现该方法。

权限判断执行过程由：拦截器完成。拦截器拦截 Action ，对实现 Protected 接口的 Action 进行判断。而具体判断逻辑由 Action 定义的。

下面，继续研究一下： Action 如何实现权限判断逻辑。

有这样一个服务： SecurityService 含有方法： boolean hasPermission( User user, String someTokenString ) 。

所以 Action 里面的权限判断几乎是 Delegate 给 SecurityService 。 SecurityService 可以使用动态注入的方式，达到可替换 SecurityService 的实现模式。

QuakeWang 继续给出了“更细粒度的控制，或者是一些特殊逻辑权限检查”。这些手段直接在 Action 里面编码。比如：

!group.getName();.equals("ADMIN_GROUP"); && securityService.hasPermission(RemoteUser.get();, "maintain_group");;

queryString 是否属于权限控制范围

eway 说“我怎么觉得诸如 queryString 之类的权限控制不应在权限系统实现，基本上是个业务实现的问题。我觉得这个 queryString 往往是代表了 “ 在什么情况下 ” 这个权限有效的问题，如果都考虑进入权限系统的话，权限系统会非常庞大，难以维护。这种权限生效的 “situation” 的问题，我往往做到业务逻辑层中去 check 。”

eway 继续说“偶还是觉得用 “ 资源 + 操作 ” 去思考权限的粒度比较合适？比这个粒度粗的权限，就用角色来实现，比这个粒度细的权限就用业务实现。这样权限系统比较适中。”

jackyz 举例说明“如果要精确控制 , 必须要在比 Action 更细的层次做 . 举例来说 :
论坛的帖子显示界面 , 如果当前用户对当前帖子 有删除权限 , 则显示删除链接 . 否则 , 就不显示 .
当前的操作 (Action) 是显示帖子 , 但是显示链接的逻辑判断需要对另外一个功能 ( 删除功能 ) 进行判断 . 这个判断是业务的必须 , 没有办法省略 . ”

ruby 说这样会导致 Action 不纯粹。 ruby 说“如果这样来写 ACTION, 那 Action 也太不 " 纯粹 " 了 , 包含了太多和当前 action 无关的逻辑 , 既然是要进行界面元素的显示控制 , 就在界面上控制好了 , 比如用 taglib, 至于权限列表 , 保存在 session, 显示界面元素时时取出对比一下 , 有此权限就显示此界面元素 , 没有就不显示 . ”

jackyz 指出确实不纯粹，但确实有必要，而且还提出了“权限引擎” 概念。他说“确实不纯粹 . 但是 , 对于实例级别的权限控制 , 似乎没有更好的办法 .

首先 , 明确一下 . 这里的需求是 : 实例级的权限控制 ( 就是控制到谁对什么资源 [ 的哪一个实例 ] 具有什么操作 ). 而不是功能级的权限控制 ( 就是控制到谁对什么资源 [ 不管哪一个实例都 ] 具有什么操作 ).
实例级的权限控制 , 比如 ,A 用户可以删除 A 帖子 , 但不能删除 B 帖子 . 它与具体资源的实例相关 .
功能级的权限控制 , 比如 ,A 用户可以删除帖子 (A 用户具有删除帖子的权限 , 不管什么帖子 ). 它与具体资源的实例无关 .
功能级的权限控制 , 与用户和资源类型相关 , 对于特定的用户来说 , 枚举资源类型得到的列表是确定的 , 确实可以用 Session 保存列表 , 在显示逻辑中处理 . 但是 , 实例级的权限控制 , 与具体的实例相关 , 对特定的用户 , 不可能枚举所有资源的实例 .

这种情况下 , 只有 Action 的处理过程本身能够确定对于特定实例 (ArticleId=xxx) 做出权限判断 .

从另一个角度来看 , 这里的 Action 实际上是一个 " 交互层 ", 即 , 它服务于显示逻辑 , 显示逻辑需要一个 " 是否可以删除 " 的属性 , 那么它就应该提供 , 不管是从 Session 来取 . 还是从权限引擎来运算 , 这是另外一个问题 . ”

后来又引入了 Acegi ，先按下不表，稍后再议。

权限控制切入点

仅仅在 url 层进行控制显然不够，因为这样可以采用手工输入 url 地址来侵入系统。即便模仿“ C/S ”风格，不显示地址栏也不行。地址栏用户还是可以调出来的。

所以不仅要控制前台显示“链接”，“按钮”等要素，还要对后台方法进行拦截，做权限判断。

nihongye 引入 Acegi ，她 [ 不知道是否为女士，我根据头像判断的 ] 说道“如 acegi: 权限控制可以分前后两部分来做 . 前的可以基于 url 来做 . 后的基于方法拦截来做 . 前后的结合通过 runAsManager 来做到 . 例子就是里面的 contact. 后台的可以定义粗粒度的控制资源 , 前台再细化 . 并且分开开发 , 保证前后台的开发无关 . ”