Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1675813
  • 博文数量: 585
  • 博客积分: 14610
  • 博客等级: 上将
  • 技术积分: 7402
  • 用 户 组: 普通用户
  • 注册时间: 2008-05-15 10:52
文章存档

2013年(5)

2012年(214)

2011年(56)

2010年(66)

2009年(44)

2008年(200)

分类:

2008-11-17 09:19:28

通用用户权限系统设计




做了n多的MIS系统,很久以前就有这种想法,想把MIS系统中的用户权限管理和审批流管理独立出来,做成单独的组件,但是因 为各种各样的原因,都没有去做,也许是太懒了。今天终于痛下决心,一定要把这两个东西给做成组件,说干就干。因为代码还没有写完,今天暂时就把数据库设计 发上来,等代码搞好了,并且把代码搞的好看点后,我以后可能会把这个权限管理组件和审批流管理组件开源。

今天暂时就看权限管理系统的数据库表设计吧。子系统表,因为我这里设计的为了能够集成公司内部以后所有的系统的,所以建了子系统这张表,如果单个项目,这张表可以去掉。

模块表,系统中的各个模块。

模块功能表,模块中的各个功能(可以有两种功能,一种是页面的进入权限,一种是页面上的按钮事件)

用户表

角色表

用户分组表

用户部门表

用户权限表(也可以直接对用户赋予权限)

角色权限表(对角色赋予权限)

用户和分组关系表(一个用户可以属于多个分组)

用户和角色关系表(一个用户可以拥有多个角色)

用户分组和角色关系表(一个分组可以拥有若干角色)

非常抱歉,在前几天发的那篇《通用用户权限系统设计》中,文字描述没有表达清楚我的意思,草草的贴出了数据库的表设计,请园子里的朋

友见谅。现在我针对一些朋友提的意见做一些回答,已经把上篇文章中缺少的页面怎么控制的部分,补上去。

首先回答几个主要的问题:

1、一个人是否可以在多个部门?

我这里的设计是不能在多个部门的。虽然我想现实中一个人属于多个部门的情况实存在的,但是在我们的系统里面可以把他放到一个部门里,也不会造成问题,因为我这里的部门仅仅只是让人家看这个用户是属于哪个部门的,跟权限没有关系。权限只跟角色和所属用户组有关系。

2、角色和用户组是否已经重复了?

刚开始我也这么觉得过,后来考虑了再三,并且在网上搜了一些资料,还是留下来了。事实上用户组和角色区别比较小,我自己说不清楚,我借用IT难民的这篇文章《用户、用户组、角色的区别和联系 》来做回答,可能更容易说明问题一点。

3、页面控制权限到底怎么做的?

这个别急好吗,我下面会详细解释。也有朋友问道会不会判断权限会不会频繁读取数据库,我的回答是不会的,在用户登录的时候,我就把所有权限放到session里面,用到的时候,直接判断,不会跟数据库打交道。

4、关于数据的权限控制?

我原来做这个设计的时候,就没有考虑要设计数据权限控制,所以在我这里设计里面这个需求是做不到的。可能都怪我“通用”这个词语吧,其 实我的本意是大部分MIS系统都能拿来用的功能权限控制。也有些朋友提到,我的用户表字段肯定是不行的,还有把子系统表去掉等等。我想我这个权限系统只有 权限控制部分是可以公用的,用户表肯定每个系统都不一样。好了,回答了朋友们的问题。接下来,我相对完整的讲讲我这个权限控制的思路吧,包括页面级怎么控 制功能。

1、权限定义

其实也有朋友提到,权限定义和权限控制是需要分开的,其实我也是这么想的,我们可以把权限定义做成一个专门的工具,最好不要集成在用户系统里面。

我们一起来看看需要定义哪些信息。子系统编号,模块编号,功能编号(用于控制树型菜单是否显示),功能名称,描述,页面名称(用于控制页面是否能够进入),按钮名称(用于控制功能按钮是否可用)(不好意思,上次弄的时候,把这个字段弄丢了)

2、给用户或者角色赋予权限;

3、在用户登录的时候,把用户所属角色,用户组,用户本身的权限都取出来,放到一起,存到session里面中去。

4、在我们的页面基类里面重写onload方法,在里面写上判断权限的代码。判断当前用户的session中是否有访问该页面的权限(没有权限则弹出提示,并且返回到请求页),以及该页面上的按钮(没有权限则置为不可用)

5、在导航树型菜单里面,把当前用户没有的菜单项去掉(其实就是功能编号)

6、这样的话,相当于把权限控制全部封装到基类里面了,业务模块不需要关心权限问题,只需要把做好的业务模块的权限注册到权限表中去就 可以了(第1步)。大概就这样子说吧,如果说的还明白,请朋友们跟贴。代码暂时还没有弄好,特别是页面,比较麻烦,最近时间也不是很多,请大家见谅。

 

(续)

非常抱歉,在前几天发的那篇《通用用户权限系统设计》中,文字描述没有表达清楚我的意思,草草的贴出了数据库的表设计,请园子里的朋友见谅。现在我针对一些朋友提的意见做一些回答,已经把上篇文章中缺少的页面怎么控制的部分,补上去。

首先回答几个主要的问题:
1。一个人是否可以在多个部门?
我这里的设计是不能在多个部门的。虽然我想现实中一个人属于多个部
门的情况实存在的,但是在我们的系统里面可以把他放到一个部门里,也不会造成问题,因为我这里的部门仅仅只是让人家看这个用户是属于哪个部门的,跟权限没有关系。权限只跟角色和所属用户组有关系。
2。角色和用户组是否已经重复了?
刚开始我也这么觉得过,后来考虑了再三,并且在网上搜了一些资料,
还是留下来了。事实上用户组和角色区别比较小,我自己说不清楚,我借用IT难民的这篇文章《用户、用户组、角色的区别和联系 》来做回答

,可能更容易说明问题一点。
3。页面控制权限到底怎么做的?
这个别急好吗,我下面会详细解释。也有朋友问道会不会判断权限会不
会频繁读取数据库,我的回答是不会的,在用户登录的时候,我就把所有权限放到session里面,用到的时候,直接判断,不会跟数据库打交道
4。关于数据的权限控制?
我原来做这个设计的时候,就没有考虑要设计数据权限控制,所以在我
这里设计里面这个需求是做不到的。可能都怪我“通用”这个词语吧,其实我的本意是大部分MIS系统都能拿来用的功能权限控制。也有些朋友提到,我的用户表字段肯定是不行的,还有把子系统表去掉等等。我想我这个权限系统只有权限控制部分是可以公用的,用户表肯定每个系统都不一样。

好了,回答了朋友们的问题。接下来,我相对完整的讲讲我这个权限控制的思路吧,包括页面级怎么控制功能。
1。权限定义
其实也有朋友提到,权限定义和权限控制是需要分开的,其实我也是这
么想的,我们可以把权限定义做成一个专门的工具,最好不要集成在用户系统里面。
我们一起来看看需要定义哪些信息。子系统编号,模块编号,功能编号

(用于控制树型菜单是否显示),功能名称,描述,页面名称(用于控制页面是否能够进入)

,按钮名称(用于控制功能按钮是否可用)(不好意思,上次弄的时候,把这个字段弄丢了;
2。给用户或者角色赋予权限;
3。在用户登录的时候,把用户所属角色,用户组,用户本身的权限都取出来,放到一起,存到session里面中去。
4。在我们的页面基类里面重写onload方法,在里面写上判断权限的代码。判断当前用户的session中是否有访问该页面的权限(没有权限则弹出提示,并且返回到请求页),以及该页面上的按钮(没有权限则置为不可用)
5。在导航树型菜单里面,把当前用户没有的菜单项去掉(其实就是功能编号)
6。这样的话,相当于把权限控制全部封装到基类里面了,业务模块不需要关心权限问题,只需要把做好的业务模块的权限注册到权限表中去就可以了(第1步)。

大概就这样子说吧,如果说的还明白,请朋友们跟贴。代码暂时还没有弄好,特别是页面,比较麻烦,最近时间也不是很多,请大家见谅。

 



 
阅读(1329) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~