实现业务系统中的用户权限管理.docx

资源描述

实现业务系统中的用户权限管理.docx

《实现业务系统中的用户权限管理.docx》由会员分享，可在线阅读，更多相关《实现业务系统中的用户权限管理.docx（24页珍藏版）》请在冰点文库上搜索。

实现业务系统中的用户权限管理.docx

实现业务系统中的用户权限管理

实现业务系统中的用户权限管理--设计篇

B/S系统中的权限比C/S中的更显的重要，C/S系统因为具有特殊的客户端，所以访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现，而B/S中，浏览器是每一台计算机都已具备的，如果不建立一个完整的权限检测，那么一个“非法用户”很可能就能通过浏览器轻易访问到B/S系统中的所有功能。

因此B/S业务系统都需要有一个或多个权限系统来实现访问权限检测，让经过授权的用户可以正常合法的使用已授权功能，而对那些XX的“非法用户”将会将他们彻底的“拒之门外”。

下面就让我们一起了解一下如何设计可以满足大部分B/S系统中对用户功能权限控制的权限系统。

需求陈述

∙不同职责的人员，对于系统操作的权限应该是不同的。

优秀的业务系统，这是最基本的功能。

∙可以对“组”进行权限分配。

对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便的事情。

所以，系统中就提出了对“组”进行操作的概念，将权限一致的人员编入同一组，然后对该组进行权限分配。

∙权限管理系统应该是可扩展的。

它应该可以加入到任何带有权限管理功能的系统中。

就像是组件一样的可以被不断的重用，而不是每开发一套管理系统，就要针对权限管理部分进行重新开发。

∙满足业务系统中的功能权限。

传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源权限则不能。

关于设计

　　借助NoahWeb的动作编程理念，在设计阶段，系统设计人员无须考虑程序结构的设计，而是从程序流程以及数据库结构开始入手。

为了实现需求，数据库的设计可谓及其重要，无论是“组”操作的概念，还是整套权限管理系统的重用性，都在于数据库的设计。

我们先来分析一下数据库结构：

　　首先，action表（以下简称为“权限表”），gorupmanager表（以下简称为“管理组表”），以及master表（以下简称为“人员表”），是三张实体表，它们依次记录着“权限”的信息，“管理组”的信息和“人员”的信息。

如下图：

　　这三个表之间的关系是多对多的，一个权限可能同时属于多个管理组，一个管理组中也可能同时包含多个权限。

同样的道理，一个人员可能同时属于多个管理组，而一个管理组中也可能同时包含多个人员。

如下图：

　　由于这三张表之间存在着多对多的关系，那么它们之间的交互，最好使用另外两张表来完成。

而这两张表起着映射的作用，分别是“actiongroup”表（以下简称“权限映射表”）和“mastergroup”表（以下简称“人员映射表”），前者映射了权限表与管理组表之间的交互。

后者映射了人员表与管理组表之间的交互。

如下图：

　　另外，还需要一张表来控制系统运行时左侧菜单中的权限分栏，也就是“权限分栏表”，如下图：

　　根据上面的分析，我们进行数据库结构设计，如下图：

　　点击这里查看权限管理系统数据表字段设计

　　为了能够进行良好的分析，我们将数据库结构图拆分开来，三张实体表的作用已经很清晰，现在我们来看一下两张映射表的作用。

一权限映射表如下图：

　　首先，我们来了解一下权限映射表与管理组表以及权限表之间的字段关联。

　　看图中的红圈，先看gorupid字段相关联，这种关联方式在实际数据库中的表现如下图：

　　如图中所示，管理组表中“超级管理员”的groupid为1，那么权限映射表中groupid为1的权限也就是“超级管理员”所拥有的权限。

　　使用groupid字段关联，是为了查到一个管理组能够执行的权限有哪些。

但这些权限的详细信息却是action字段关联所查询到的。

　　action字段相关联在数据库中的表现如下图：

　　通过这种关联，才查询到权限映射表之中那些权限的详细信息。

综合起来，我们就知道了一个管理组可以执行的权限有哪些，以及这些权限的详细信息是什么。

　　或许你会问，为什么不使用actionid字段相关联呢？

因为：

∙权限表中的id字段在经过多次的数据库操作之后可能会发生更改。

∙权限映射表中仅仅记录着一个管理组可以执行的权限。

∙一旦权限表中的id更改，那么权限映射表中的记录也就更改了。

∙一个管理组可以执行的权限势必将出错，这是非常不希望的。

　　考虑到上面的情况，所以应该使用action字段相关联，因为：

∙在权限表中，id可能发生变化，而action字段却是在任何情况下也不可能发生变化的。

∙权限映射表中记录的action字段也就不会变。

∙一个管理组可以执行的权限就不会出错了。

二人员映射表如下图：

　　我们来了解一下人员映射表与管理组表以及人员表之间的字段关联，如下图：

　　看图中的红圈部分，先看groupid字段关联，这种关联方式在数据库中的表现如下图：

　　如图，“超级管理员”组的groupid为1，我们再看人员映射表，admin属于超级管理员组，而administrator属于超级管理员组，同时也属于管理员组。

　　使用这种关联方式，是为了查到一个管理组中的人员有谁。

和上面一样，人员的详细信息是靠id字段（人员映射表中是masterid字段）关联查询到的。

　　id字段（人员映射表中是masterid字段）关联表现在数据库中的形式如下图：

　　一个人员可能同时属于多个“管理组”，如图中，administrator就同时属于两个“管理组”。

所以，在人员映射表中关于administrator的记录就会是两条。

　　这种关联方式才查询到管理组中人员的详细信息有哪些。

综合起来，才可以知道一个管理组中的人员有谁，以及这个人员的详细信息。

　　再结合上面谈到的权限表和权限映射表，就实现了需求中的“组”操作，如下图：

　　其实，管理组表中仅仅记录着组的基本信息，如名称，组id等等。

至于一个组中人员的详细信息，以及该组能够执行的权限的详细信息，都记录在人员表和权限表中。

两张映射表才真正记录着一个组有哪些人员，能够执行哪些权限。

通过两张映射表的衔接，三张实体表之间的交互才得以实现，从而完成了需求中提到的“组”操作。

　　我们再来看一下权限分栏表与权限表之间的交互。

这两张表之间的字段关联如下图：

　　两张表使用了actioncolumnid字段相关联，这种关联方式在数据库中的表现如下图：

　　如图所示，通过这种关联方式，我们可以非常清晰的看到权限表中的权限属于哪个分栏。

　　现在，数据库结构已经很清晰了，分配权限的功能以及“组”操作都已经实现。

下面我们再来分析一下需求中提到的关于权限管理系统的重用性问题。

　　为什么使用这种数据库设计方式搭建起来的系统可以重用呢？

∙三张实体表中记录着系统中的三个决定性元素。

“权限”，“组”和“人”。

而这三种元素可以任意添加，彼此之间不受影响。

无论是那种类型的业务系统，这三个决定性元素是不会变的，也就意味着结构上不会变，而变的仅仅是数据。

∙两张映射表中记录着三个元素之间的关系。

但这些关系完全是人为创建的，需要变化的时候，只是对数据库中的记录进行操作，无需改动结构。

∙权限分栏表中记录着系统使用时显示的分栏。

无论是要添加分栏，修改分栏还是减少分栏，也只不过是操作记录而已。

　　综上所述，这样设计数据库，系统是完全可以重用的，并且经受得住“变更”考验的。

总结：

　　此套系统的重点在于，三张实体表牢牢地抓住了系统的核心成分，而两张映射表完美地映射出三张实体表之间的交互。

其难点在于，理解映射表的工作，它记录着关系，并且实现了“组”操作的概念。

而系统总体的设计是本着可以在不同的MIS系统中“重用”来满足不同系统的功能权限设置。

附录：

权限管理系统数据表的字段设计

　　下面我们来看看权限管理系统的数据库表设计，共分为六张表，如下图：

action表：

　　action表中记录着系统中所有的动作，以及动作相关描述。

actioncolumn表：

　　actioncolumn表中记录着动作的分栏，系统运行时，左侧菜单栏提供了几块不同的功能，每一块就是一个分栏，每添加一个分栏，该表中的记录就会增加一条,相对应的，左侧菜单栏中也会新增机一个栏。

actiongroup表：

　　actiongroup表记录着动作所在的组。

groupmanager表：

　　groupmanager表记录着管理组的相关信息，每添加一个管理组，这里的记录就会增加一条。

mastergroup表：

　　mastergroup表记录着管理员所在的管理组，由于一名管理员可能同同时属于多个组，所以该表中关于某一名管理员的记录可能有多条。

master表：

　　master表记录着所有管理员的信息，每添加一个管理员，该表就会增加一条记录。

实现业务系统中的用户权限管理--实现篇

在设计篇中，我们已经为大家阐述了有关权限管理系统的数据库设计，在本篇中，我们将重点放在其实现代码部分。

为了让你能够更直接更有效的看到全部动作的代码，我们使用“动作分解列表”的方式来陈述每个动作以及相关资源。

实现权限管理功能的动作

动作分解

动作名

相关表名

操作集类型

（S,U,I,D,SQL）

表单

模组

字符资源

是否分页？

返回提示？

权限检测

当管理员第一次进入管理系统时将使用该动作

无

否

系统登录动作，管理员登录系时将使用该动作

master

SQL

无

loginok

loginjumpframe

loginerror

否

是

否

显示窗口TITLE信息

viewtoolstitle

无

managertitle

否

是

否

显示左工具条

list_tools

无

否

是

否

任务系统（预留）

autoviewtask

当用户未进行登录而执行动作时会引发该动作

nosession

无

nosession

nosessionjumpframe

否

是

否

当用户进行删除操作时未点击确认时会引发该动作

nopointid

无

nopointid

否

是

否

当用户试图执行自己没有权限执行的动作时会引发该动作

nopurview

无

nopurview

否

是

否

退出系统

outlogin

无

loginout

nosessionjumpframe

否

是

否

详解模组：

　　1.setup（数据库初始化、权限设置模组）

　　当布署好一个新的系统后，我们可以通过执行一个动作setup来安装数据库和一些初始值，通过执行这个动作系统可以正常运行。

因为执行setup这个动作时会调用到一个名称为setup的模组，这个模组的作用是初始化系统所用到的数据库，并且在系统中设置动作的权限，否则数据库和有权限的动作就没办法执行。

下面我们来看一下setup模组的代码，点击这里查看代码。

这里我们把代码拆分开看一下，由于setup模组里有好多类似的代码，所以这里我们只找出不同功能的代码做一下介绍：

　　第一段：

数据库安装

　　在模组中首先调用了一个datebase_SQL_setup这个数据库操作集，这个数据库操作集用来为系统中的数据库表（根据情况删除或新建）做初始化。

　　第二段：

添加权限信息

　　代码中调用了action_I_newone这个数据库操作集，在这个操作集中加入权限的名称和它的其它信息。

　　第三段：

添加一个管理员

　　这部分代码中调用了master_I_newone数据库操作集在数据库中添加了一个管理员的信息，这个信息是可以不写在这里的，可以直接在数据库中添加，但是为了减少不必要的麻烦所以直接在这里添入了一个默认的管理员。

　　第四段：

添加管理员组

　　通过调用groupmanager_I_newmaster这个数据库操作集新建了一个管理员组，并加入了详细的管理员组信息，可以把新用户加入到此管理员组。

　　第五段：

添加新的工具分栏

　　通过调用actioncolumn_I_newone数据库操作集在工具栏里加入一个工具栏分栏选项。

　　第六段：

指定管理组

　　通过调用mastergroup_I_newone数据库操作集把admin这个用户加入到第一个管理组里，使该用户成为第一个管理组的成员。

　　最后一段：

指定管理组拥有的权限

　　这段代码首先调用了action_S_all数据库操作集并使用Loop语句列出所有的动作，然后调用actiongroup_I_newone这个数据库操作集，把所有的动作都加入到第一个管理组里，使第一个管理组拥有所有权限。

　　这里之所以把数据库的安装和权限的设置都放在模组里面，是为了使用户使用更加方便，不需要再去重新手动建库，以减不在数据库这方面的错误，使系统更加简单流畅。

如果其它系统也需要权限这方面的管理，可以把模组稍做修改就可以直接拿来用，这样也体现出代码的重用性。

　　2.checkuserpurview（检验当前用户能否执行该动作的模组）

　　在权限管理系统中，模组checkuserpurview得到了反复使用，该模组担负着检测用户权限的任务，在所有需要进行访问权限控制的动作的开始部分都调用了该模组，所以理解该模组的代码也有一定难度。

下面，我们来看一看该模组的代码。

　　我们将整段代码拆分一下，首先看第一段，如下图：

　　判断_SESSION.myloginid的值是否为空，如果为空，在当前页面中执行nosession这个动作。

我们在用户登陆的动作中login会为登陆的用户使用myloginid的SESSION变量记录下该用户的ID，因此如果用户是正常登陆并在SESSION有效期内的话，则_SESSION.myloginid的值是不可能为空的。

通过此部分代码检测用户是否已经登陆成功并获得合法的访问身份。

　　然后看下面的代码，如下图：

　　调用数据库操作集mastergroup_S_bymasterid，使用逻辑层的Loop，使用当前执行的action以及查询返回的groupid作为条件，调用数据库操作集actiongroup_S_byactionandgroupid进行循环查询，如果查询返回值大于0（零），将局部变量purview的值设置为1。

　　这段代码的重点在于使用的Loop进行循环，由于actiongroup表中记录着用户所处的管理组能够执行的权限，并且一个用户可能同时会属于多个组，因此我们需要去检验用户属于的多个组中是否有对该动作执行的权限，因此，我们使用当前需要执行的动作action以及用户所处的管理组groupid循环查询，当前用户所属于的组中只要有一个组具有执行该动作的执行权限，则该用户就可以执行该动作。

　　最后一部分代码如下图：

　　再次使用判断，如果purview的值不为1的话，则在当前页面执行nopurview动作。

　　由于之前的代码中，如果用户拥有执行动作的权限的话，会将局部变量purview的值设置为1，所以这里如果该变量值不为1，就说明了此用户没有执行动作的权限，故执行nopurview动作。

总结

　　从设计到实现，权限管理系统的教程到这里就全部结束了。

在设计阶段，最重要也是最难理解的是那两张映射表的作用，理解了两张映射表，基本上也就理解了整套数据库的设计。

而实现阶段，比较难理解的就是上面说到的模组checkuserpurview了。

理解该模组，需要联合数据库设计，actiongroup表中记录着用户组可以执行的权限，使用action字段和groupid字段进行查询，返回的数大于1，说明了用户所在的组拥有执行该动作的权限。

附录

MYSQL版本权限管理系统源码下载

MSSQL版本权限管理系统源码下载

展开阅读全文