论坛首页 Java企业应用论坛

一个简易实用的web权限管理模块的应用与实现

浏览 99731 次
该帖已经被评为良好帖
作者 正文
   发表时间:2009-01-01   最后修改:2009-01-01
权限应该有几层概念
一、管理内容
1.界面
2.url
3.service
4.data
二、管理实体
1、user
2、role
3、权限
4、voter manager
三、管理方法
1、aop方法


最后忘了说了,spring security也就是acegi完全能实现。不过的确要改很多东西。acegi的颗粒度非常的低。但低的容易集成呀。好东西只有深入研究了才叫好。
Last I really appreciate that you can share the experiences.
0 请登录后投票
   发表时间:2009-01-01  
Augustan 写道
wangjian5748 写道
存在很明显的问题,user与role多对多关系,user与group多对多关系,group与role多对多关系。user-->role的关系可以由user-->group-->role关系推导出来。一个简单的闭环问题?

目前并没有具体实现group的概念。 用户的role可以认为是user-->group-->role以及user-->role的并集。它们是分开设置的,并不互相影响。



有进步,已经接近事物的本质了,再简单点就是完美.
0 请登录后投票
   发表时间:2009-01-01  
haole 写道
楼主设计的不错,我觉得acegi不适用,无论B/S,还是C/S,对于一个界面来说,会有很多功能,如果设计的粒度太细,我感觉不适用,例如,如果允许进入一个界面,则此界面的所有功能都可以使用(当然可以控制不能使用的功能不显示)。
可以举一个例子来说,对于生产系统来说,“系统维护”功能是必须的,用来维护系统中最基础的数据,只能有系统管理员使用,一般来说,系统管理员也就是一个人或者两个人,系统维护中包括若干维护项目,一个人有了系统维护的功能,就可以维护所有基础数据,没有必要在进行区分,一个人可以维护这个数据,而另一个用来维护另外的数据。
所以我认为acegi一点不适用,特别是角色是由用户来维护的,根本不确定,如何能够在程序中写死。

我一直期待业界把超权限的管理员这个概念给消灭,可是失望了
0 请登录后投票
   发表时间:2009-01-01  
laochake 写道
Augustan 写道
Lucas Lee 写道
有个问题:
角色跟功能权限的关系没有描述啊?
实体关系图里也没有,界面里也没提及?

有提及:
四、角色(role):角色对应着某些功能(function)的集合,被分配一个角色意味着有权执行这些功能。角色表中的字段"functions"记录相关的功能id,id之间用逗号隔开。
这种联系无法在图中用箭头直接表述出来。
图片中那棵带选择框的树,就是为某个角色分配相应的功能。


用逗号来保存关联,这种方式还是少用为好

如果要增加组,建议用户与组之间用多对多关系

如果部门的人员比较多,建议部门与组之间、部门与角色之间最好也要建立多对多关联

这样,用户的权限就是以下的并集:

用户-->角色-->功能
用户-->组-->角色-->功能
用户-->部门-->角色-->功能
用户-->部门-->组-->角色-->功能

这自找麻烦的设计也有实际做出来并应用的系统,真为开发这种系统的人感到同情,简单就是美,没听说过?
0 请登录后投票
   发表时间:2009-01-01  
Augustan 写道

 

 

      三、组(group) :是某相同职能的用户的集合,可以和用户一样与角色产生关联。设置组的目的是为了方便用户的角色分配,减少用户与角色的直接对应关系。用户的角色可以是其组角色和其直接分配的角色之合集。限于作者的时间和精力,组功能在该系统中没有具体的实现。

本意是为了简化,结果反倒引入了复杂,增加了工作流,需要理解的概念,可惜.
      四、角色(role):角色对应着某些功能(function)的集合,被分配一个角色意味着有权执行这些功能。角色表中的字段"functions"记录相关的功能id,id之间用逗号隔开。

作为权宜之计的实现勉强可以接受,这个暂时的妥协将带来日后许多隐患.

      五、功能(function):系统的一个或者多个执行准入。

      那么如何表现“功能”以最终实现控制用户的每一个细微动作呢?假如不特定于某种架构,可以这么设计该表字段:

CREATE TABLE  `m2_function` (
  `FUNCTION_ID` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `NAME` varchar(50) NOT NULL,
  `FUNC_TREE_ID` int(10) unsigned NOT NULL,
  `RESOURCE` varchar(100) NOT NULL,
  `SUFFIX` varchar(50) NOT NULL,
  `DESCRIPTION` varchar(100) NOT NULL,
  `PARAMS` varchar(45) NOT NULL,
  PRIMARY KEY (`FUNCTION_ID`)
)  DEFAULT CHARSET=utf8;

    假定有三个web访问路径
  http://127.0.0.1:8080/app/sys/user.jsp?action=index&userid=1203 
  http://127.0.0.1:8080/app/sys/user.yuetong?action=add
  http://127.0.0.1:8080/app/sys/user.yuetong?action=update&userid=1203
     这三个访问点被人为的划分为两个功能准入(当然亦可以是一个或者三个),见下图     

   

     由此可知,“功能”是衡量用户准入的最小刻度。在用户访问某个地址的时候,我们可以通过解析URL对比他拥有的“功能”权限来实现权限管理。

     借助于某些架构或者设计思路,可以避免用户直接访问JSP页面,甚至全系统的访问地址都使用同一后缀,这种情况下可以省去SUFFIX字段。 本系统就是这种情况(JSP页面置于WEB-INF下,采用struts2架构)。

由于目前control层的灵活,这样也是能接受的,控制得好仅仅是数据的冗余,不会造成太麻烦的后果

     六、功能模块树(function tree):功能的目录组织,起分类的作用。在为角色设定功能的时候,用户界面可以利用带选择框的js树。而这颗js树是后台的功能树表以及功能表的联合表现形式。功能模块树可以方便的与菜单树建立映射关系,限于作者的时间和精力,该系统并未实现菜单树。

简单点说,功能是不应该有层级关系的.表面看到的并不意味着事实本质就是如此,不小心对待系统就会向失败演化.

 

 

 

 

 

0 请登录后投票
   发表时间:2009-01-01   最后修改:2009-01-01
我还想说的是,企业应用和WEB应用的权限控制模型本质是一样的,但是设计实现如何上大可斟酌.例如在一千万用户数和10用户数相比的情况下,一个可以直接以角色拥有的权限来判断权限,而另外一个可以用户本身拥有的权限来判断
0 请登录后投票
   发表时间:2009-01-01  
有点意思。
0 请登录后投票
   发表时间:2009-01-01   最后修改:2009-01-01
XMLDB 写道
Augustan 写道

 

 

      三、组(group) :是某相同职能的用户的集合,可以和用户一样与角色产生关联。设置组的目的是为了方便用户的角色分配,减少用户与角色的直接对应关系。用户的角色可以是其组角色和其直接分配的角色之合集。限于作者的时间和精力,组功能在该系统中没有具体的实现。

本意是为了简化,结果反倒引入了复杂,增加了工作流,需要理解的概念,可惜.
      四、角色(role):角色对应着某些功能(function)的集合,被分配一个角色意味着有权执行这些功能。角色表中的字段"functions"记录相关的功能id,id之间用逗号隔开。

作为权宜之计的实现勉强可以接受,这个暂时的妥协将带来日后许多隐患.

      五、功能(function):系统的一个或者多个执行准入。

      那么如何表现“功能”以最终实现控制用户的每一个细微动作呢?假如不特定于某种架构,可以这么设计该表字段:

CREATE TABLE  `m2_function` (
  `FUNCTION_ID` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `NAME` varchar(50) NOT NULL,
  `FUNC_TREE_ID` int(10) unsigned NOT NULL,
  `RESOURCE` varchar(100) NOT NULL,
  `SUFFIX` varchar(50) NOT NULL,
  `DESCRIPTION` varchar(100) NOT NULL,
  `PARAMS` varchar(45) NOT NULL,
  PRIMARY KEY (`FUNCTION_ID`)
)  DEFAULT CHARSET=utf8;

    假定有三个web访问路径
  http://127.0.0.1:8080/app/sys/user.jsp?action=index&userid=1203 
  http://127.0.0.1:8080/app/sys/user.yuetong?action=add
  http://127.0.0.1:8080/app/sys/user.yuetong?action=update&userid=1203
     这三个访问点被人为的划分为两个功能准入(当然亦可以是一个或者三个),见下图     

   

     由此可知,“功能”是衡量用户准入的最小刻度。在用户访问某个地址的时候,我们可以通过解析URL对比他拥有的“功能”权限来实现权限管理。

     借助于某些架构或者设计思路,可以避免用户直接访问JSP页面,甚至全系统的访问地址都使用同一后缀,这种情况下可以省去SUFFIX字段。 本系统就是这种情况(JSP页面置于WEB-INF下,采用struts2架构)。

由于目前control层的灵活,这样也是能接受的,控制得好仅仅是数据的冗余,不会造成太麻烦的后果

     六、功能模块树(function tree):功能的目录组织,起分类的作用。在为角色设定功能的时候,用户界面可以利用带选择框的js树。而这颗js树是后台的功能树表以及功能表的联合表现形式。功能模块树可以方便的与菜单树建立映射关系,限于作者的时间和精力,该系统并未实现菜单树。

简单点说,功能是不应该有层级关系的.表面看到的并不意味着事实本质就是如此,不小心对待系统就会向失败演化.

 

 

 

 

 

 本意是为了简化,结果反倒引入了复杂,增加了工作流,需要理解的概念,可惜.

-------这个有待商榷。

作为权宜之计的实现勉强可以接受,这个暂时的妥协将带来日后许多隐患.

------哪些隐患,能具体谈谈么?

简单点说,功能是不应该有层级关系的.

------您并没有看明白我的表结构。功能是没有层级关系的。

 

0 请登录后投票
   发表时间:2009-01-01  
粗略看看还不错

明天再细看

有代码提供,支持
0 请登录后投票
   发表时间:2009-01-02  
还没看你的代码 ,但是思路很清晰啊
0 请登录后投票
论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics