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

Augustan

浏览: 52354 次
性别:
来自: 江蘇

最近访客更多访客>>

zhenggz

peiqiang1990715

524791190

chennengwen

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

博客分类：

java

Web 配置管理企业应用项目管理应用服务器

本文介绍一个简易实用的web权限管理模块的应用与实现。

先介绍数据模型和应用界面，后继对实现细节做选择性阐述。

数据表关系如下：

数据模型

该图标明了登陆用户、角色、部门（机构）、用户组、角色和模块功能之间的关系。为方便起见，所有表都只保留必要字段。

在本系统设计中，如下概念有着相对特殊的含义。

一、用户(user)：系统的使用者。

二、部门(org)：体现了用户的行政关系，

三、组(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架构）。

     六、功能模块树（function tree）：功能的目录组织，起分类的作用。在为角色设定功能的时候，用户界面可以利用带选择框的js树。而这颗js树是后台的功能树表以及功能表的联合表现形式。功能模块树可以方便的与菜单树建立映射关系，限于作者的时间和精力，该系统并未实现菜单树。
    下面从实际应用入手做直观的介绍：
     用超级管理员帐号YT000登陆（该帐号拥有全部的权限，帐号信息应该预先写入数据库或者以配置文件方式放到类路径下）：
     首先是机构管理部分，这里可以编辑某个公司或者单位的组织结构：

然后进入用户管理部分，会有一个用户列表：

可以编辑用户的属性，设置其所属机构：

还可以为用户设定多个角色：

接着，再看看角色的列表：

可以为角色设定功能。该角色设定树的生成，在后继文章中会有介绍。

最后，在系统资源部分，可以进行功能模块树的编辑（和机构树的编辑一样）

点击编辑详细功能，可以为选中的结点设置具体功能：

配置妥当以后，当我们以一个普通用户登录，执行某个操作的时候，如果没有权限，系统会做出提示。关于用户的权限验证，后继会有介绍。

相关阐述请关注后继文章。

m2soft.rar (107.5 KB)
下载次数: 8584

分享到：

apusic的双机热备、集群以及系统移植 | 一个简易实用的web权限管理模块的应用与实 ...

2008-12-24 14:55
浏览 16118
评论(127)
论坛回复 / 浏览 (104 / 100283)
分类:企业架构
查看更多

87 楼 hcjdiy 2009-01-05

小嘴看世界写道

强烈要求lz来个完整的包

恩。能不能来个完整的包下载就能用的啊。

86 楼小嘴看世界 2009-01-04

强烈要求lz来个完整的包

85 楼 mrzhanghuzi 2009-01-04

很好，赞一个。

84 楼 crabboy 2009-01-04

kaki 写道

有点意思。

你还在搞技术啊？

83 楼 hexq1983 2009-01-03

用户对角色组，角色组对权限，用户不能对权限，不然就乱套了

82 楼 wym0291 2009-01-02

.....说spring security不适用只是因为没有深入理解这个框架。楼主的部分功能完全可以与spring security集成，而且部分表的设计也可以省略转而使用ldap代替。授权部分则可以封装一下。

81 楼 yangjun101 2009-01-02

还没看你的代码，但是思路很清晰啊

80 楼 BaSaRa 2009-01-01

粗略看看还不错

明天再细看

有代码提供，支持

79 楼 Augustan 2009-01-01

<div class='quote_title'>XMLDB 写道</div>
<div class='quote_div'>
<div class='quote_title'>Augustan 写道</div>
<div class='quote_div'>
 
 
 三、组(group) ：是某相同职能的用户的集合，可以和用户一样与角色产生关联。设置组的目的是为了方便用户的角色分配，减少用户与角色的直接对应关系。用户的角色可以是其组角色和其直接分配的角色之合集。限于作者的时间和精力，组功能在该系统中没有具体的实现。
本意是为了简化,结果反倒引入了复杂,增加了工作流,需要理解的概念,可惜. 四、角色(role)：角色对应着某些功能(function)的集合，被分配一个角色意味着有权执行这些功能。角色表中的字段"functions"记录相关的功能id,id之间用逗号隔开。
作为权宜之计的实现勉强可以接受,这个暂时的妥协将带来日后许多隐患.
 五、功能(function)：系统的一个或者多个执行准入。
 那么如何表现“功能”以最终实现控制用户的每一个细微动作呢？假如不特定于某种架构，可以这么设计该表字段：
<pre name='code' class='sql'>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;
</pre>
 假定有三个web访问路径 <a href='http://127.0.0.1:8080/app/sys/user.jsp?action=index&amp;userid=1203'>http://127.0.0.1:8080/app/sys/user.jsp?action=index&userid=1203</a> <a href='http://127.0.0.1:8080/app/sys/user.yuetong?action=add'>http://127.0.0.1:8080/app/sys/user.yuetong?action=add</a> <a href='http://127.0.0.1:8080/app/sys/user.yuetong?action=update&amp;userid=1203'>http://127.0.0.1:8080/app/sys/user.yuetong?action=update&userid=1203</a> 这三个访问点被人为的划分为两个功能准入（当然亦可以是一个或者三个），见下图 
<img src='/upload/picture/pic/28251/e716dc99-599e-3c30-ae69-e6ab211db836.bmp ' height='89' alt='' width='588'/> 
 由此可知，“功能”是衡量用户准入的最小刻度。在用户访问某个地址的时候，我们可以通过解析URL对比他拥有的“功能”权限来实现权限管理。
 借助于某些架构或者设计思路，可以避免用户直接访问JSP页面，甚至全系统的访问地址都使用同一后缀，这种情况下可以省去SUFFIX字段。　本系统就是这种情况（JSP页面置于WEB-INF下，采用struts2架构）。
由于目前control层的灵活,这样也是能接受的,控制得好仅仅是数据的冗余,不会造成太麻烦的后果
 六、功能模块树（function tree）：功能的目录组织，起分类的作用。在为角色设定功能的时候，用户界面可以利用带选择框的js树。而这颗js树是后台的功能树表以及功能表的联合表现形式。功能模块树可以方便的与菜单树建立映射关系，限于作者的时间和精力，该系统并未实现菜单树。
简单点说,功能是不应该有层级关系的.表面看到的并不意味着事实本质就是如此,不小心对待系统就会向失败演化.
 
 
 
 
</div>



</div>
 本意是为了简化,结果反倒引入了复杂,增加了工作流,需要理解的概念,可惜.
-------这个有待商榷。

作为权宜之计的实现勉强可以接受,这个暂时的妥协将带来日后许多隐患.
------哪些隐患，能具体谈谈么？
简单点说,功能是不应该有层级关系的.
------您并没有看明白我的表结构。功能是没有层级关系的。

78 楼 kaki 2009-01-01

有点意思。

77 楼 XMLDB 2009-01-01

我还想说的是,企业应用和WEB应用的权限控制模型本质是一样的,但是设计实现如何上大可斟酌.例如在一千万用户数和10用户数相比的情况下,一个可以直接以角色拥有的权限来判断权限,而另外一个可以用户本身拥有的权限来判断

76 楼 XMLDB 2009-01-01

<div class='quote_title'>Augustan 写道</div>
<div class='quote_div'>
 
 
 三、组(group) ：是某相同职能的用户的集合，可以和用户一样与角色产生关联。设置组的目的是为了方便用户的角色分配，减少用户与角色的直接对应关系。用户的角色可以是其组角色和其直接分配的角色之合集。限于作者的时间和精力，组功能在该系统中没有具体的实现。
本意是为了简化,结果反倒引入了复杂,增加了工作流,需要理解的概念,可惜. 四、角色(role)：角色对应着某些功能(function)的集合，被分配一个角色意味着有权执行这些功能。角色表中的字段"functions"记录相关的功能id,id之间用逗号隔开。
作为权宜之计的实现勉强可以接受,这个暂时的妥协将带来日后许多隐患.
 五、功能(function)：系统的一个或者多个执行准入。
 那么如何表现“功能”以最终实现控制用户的每一个细微动作呢？假如不特定于某种架构，可以这么设计该表字段：
<pre name='code' class='sql'>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;
</pre>
 假定有三个web访问路径 <a href='http://127.0.0.1:8080/app/sys/user.jsp?action=index&amp;userid=1203'>http://127.0.0.1:8080/app/sys/user.jsp?action=index&userid=1203</a> <a href='http://127.0.0.1:8080/app/sys/user.yuetong?action=add'>http://127.0.0.1:8080/app/sys/user.yuetong?action=add</a> <a href='http://127.0.0.1:8080/app/sys/user.yuetong?action=update&amp;userid=1203'>http://127.0.0.1:8080/app/sys/user.yuetong?action=update&userid=1203</a> 这三个访问点被人为的划分为两个功能准入（当然亦可以是一个或者三个），见下图 
<img src='/upload/picture/pic/28251/e716dc99-599e-3c30-ae69-e6ab211db836.bmp ' height='89' alt='' width='588'/> 
 由此可知，“功能”是衡量用户准入的最小刻度。在用户访问某个地址的时候，我们可以通过解析URL对比他拥有的“功能”权限来实现权限管理。
 借助于某些架构或者设计思路，可以避免用户直接访问JSP页面，甚至全系统的访问地址都使用同一后缀，这种情况下可以省去SUFFIX字段。　本系统就是这种情况（JSP页面置于WEB-INF下，采用struts2架构）。
由于目前control层的灵活,这样也是能接受的,控制得好仅仅是数据的冗余,不会造成太麻烦的后果
 六、功能模块树（function tree）：功能的目录组织，起分类的作用。在为角色设定功能的时候，用户界面可以利用带选择框的js树。而这颗js树是后台的功能树表以及功能表的联合表现形式。功能模块树可以方便的与菜单树建立映射关系，限于作者的时间和精力，该系统并未实现菜单树。
简单点说,功能是不应该有层级关系的.表面看到的并不意味着事实本质就是如此,不小心对待系统就会向失败演化.
 
 
 
 
</div>

75 楼 XMLDB 2009-01-01

laochake 写道

Augustan 写道

Lucas Lee 写道

有个问题：
角色跟功能权限的关系没有描述啊？
实体关系图里也没有，界面里也没提及？

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

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

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

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

这样，用户的权限就是以下的并集：

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

这自找麻烦的设计也有实际做出来并应用的系统,真为开发这种系统的人感到同情,简单就是美,没听说过?

74 楼 XMLDB 2009-01-01

haole 写道

楼主设计的不错，我觉得acegi不适用，无论B/S,还是C/S，对于一个界面来说，会有很多功能，如果设计的粒度太细，我感觉不适用，例如，如果允许进入一个界面，则此界面的所有功能都可以使用（当然可以控制不能使用的功能不显示）。
可以举一个例子来说，对于生产系统来说，“系统维护”功能是必须的，用来维护系统中最基础的数据，只能有系统管理员使用，一般来说，系统管理员也就是一个人或者两个人，系统维护中包括若干维护项目，一个人有了系统维护的功能，就可以维护所有基础数据，没有必要在进行区分，一个人可以维护这个数据，而另一个用来维护另外的数据。
所以我认为acegi一点不适用，特别是角色是由用户来维护的，根本不确定，如何能够在程序中写死。

我一直期待业界把超权限的管理员这个概念给消灭,可是失望了

73 楼 XMLDB 2009-01-01

Augustan 写道

wangjian5748 写道

存在很明显的问题，user与role多对多关系，user与group多对多关系，group与role多对多关系。user-->role的关系可以由user-->group-->role关系推导出来。一个简单的闭环问题？

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

有进步,已经接近事物的本质了,再简单点就是完美.

72 楼 erichua 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.

71 楼 glmichelin 2008-12-31

不错，赞扬一个

70 楼 crabboy 2008-12-31

表之间关联用外键了？

69 楼 Augustan 2008-12-31

wangjian5748 写道

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

68 楼 larry838 2008-12-31

谢谢，能不能搞个完整的工程？

« 上一页 1 2 3 4 5 6 7 下一页 »

发表评论

您还没有登录,请您登录后再发表评论

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论