一个简易实用的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登陆（该帐号拥有全部的权限，帐号信息应该预先写入数据库或者以配置文件方式放到类路径下）：
     首先是机构管理部分，这里可以编辑某个公司或者单位的组织结构：

    

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

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

 

 

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

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

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

 

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

 

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

 

 

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

 

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

 

 

 

 

 

很好 支持

支持一下!

继续关注，期待后续

支持一下

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

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

嗯，不错呀，
常用的功能基本都能实现了

这个只是功能权限上，如果全面的话，最好也支持user与function直接关联。

因为有的时候，一个人与其他人都是同一个role，突然要给这个人多增加个菜单，要怎么办？如果新增一个角色，对于一个人还可以，如果是多个人呢而且是新增不同的菜单？这样管理起来很麻烦。

好的功能管理还应该提供复制、对换的功能

我大致看了下,界面是不错的.但我没有看到除了页面展示层之外的相关逻辑层的设计.
也就是规定了不同形色的人,他们的实际区分是什么,以及使用相应功能模块所具备的不同权限.另外,就是对数据的敏感把握,什么样的人看什么样的数据包括搜索出的结果针对权限方面的设计.
值得注意的是,数据的迁移\组织架构的嵌入.比如,发邮件通过类似组织结构选择人员可以自动填充其Email;又或者发短信,可以自动输入其手机号码.