B/S系统中对用户功能权限控制的权限系统

B/S系统中对用户功能权限控制的权限系统

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

B/S系统中的权限比C/S系统中的权限更重要。 由于C/S系统有专门的客户端,访问用户权限检测可以通过客户端实现,也可以通过客户端+服务器检测的方式实现java用户角色权限设计,而B/S系统中,每台计算机都有浏览器。 如果没有建立完整的权限检测,那么“非法用户”很可能能够通过浏览器轻松访问B/S系统中的所有功能。 。 因此,B/S业务系统需要有一个或多个权限系统来实现访问权限检测,让授权用户可以正常合法地使用授权功能,而那些未经授权的“非法用户”将被彻底“拒之门外”。 我们来看看如何设计一个能够满足大多数B/S系统中用户功能权限控制的权限系统。

要求说明

关于设计

借助NoahWeb的动作编程理念,系统设计者在设计阶段不需要考虑程序结构的设计,而是从程序流程和数据库结构入手。 为了实现需求,数据库的设计极其重要。 无论是“组”操作的概念,还是整个权限管理系统的复用性,都取决于数据库的设计。

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

首先是action表(以下简称“权限表”)、gorupmanager表(以下简称“管理组表”)、master表(以下简称“人员表”)是三个实体表,依次记录“权限”信息、“管理组”信息和“人员”信息。 如下所示:

用户角色权限java代码_java角色权限管理系统_java用户角色权限设计

这三个表之间的关系是多对多的。 一个权限可能同时属于多个管理组,一个管理组也可能同时包含多个权限。 同理,一个人可能同时属于多个管理组,一个管理组也可能同时包含多个人。 如下所示:

由于这三个表之间存在多对多关系,因此最好使用另外两个表来完成它们之间的交互。 这两张表起到映射作用,即“actiongroup”表(以下简称“权限映射表”)和“mastergroup”表(以下简称“人员映射表”)。 前者映射权限表和管理组表。 之间的相互作用。 后者映射人员表和管理组表之间的交互。 如下所示:

另外,系统运行时还需要一张表来控制左侧菜单中的权限列java用户角色权限设计,即“权限列表”,如下图:

基于以上分析,我们设计数据库结构,如下图:

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

java角色权限管理系统_用户角色权限java代码_java用户角色权限设计

为了更好的进行分析,我们将数据库结构图进行了拆分。 三个实体表的作用已经很清楚了。 现在我们来看看这两个映射表的作用。

权限映射表如下所示:

首先我们看一下权限映射表、管理组表、权限表之间的字段关联。

看图中红圈,首先看gorupid场相关性。 这种关联方法在实际数据库中的表现如下:

如图所示,管理组表中“超级管理员”的groupid为1,因此权限映射表中groupid为1的权限就是“超级管理员”拥有的权限。

使用groupid字段关联的目的是为了找出一个管理组可以执行哪些权限。 但这些权限的详细信息是通过action字段关联来查询的。

数据库中action字段关联的性能如下:

java角色权限管理系统_java用户角色权限设计_用户角色权限java代码

通过这种关联,可以查询权限映射表中那些权限的详细信息。 总而言之3D角色,我们知道管理组可以执行哪些权限以及这些权限的详细信息。

你可能会问,为什么不使用actionid字段来关联呢? 因为:

考虑到上述情况,应该使用action字段来关联,因为:

两人映射表如下:

我们看一下人员映射表、管理组表、人员表之间的字段关联,如下图:

用户角色权限java代码_java用户角色权限设计_java角色权限管理系统

看图中红圈,首先看groupid字段关联。 这种关联方法在数据库中的表现如下:

用户角色权限java代码_java用户角色权限设计_java角色权限管理系统

如图所示,“超级管理员”组的groupid为1,我们看一下人员映射表。 Admin属于超级管理员组,administrator属于超级管理员组,也属于管理员组。

此关联方法用于找出管理组中的人员。 如上,通过关联id字段(人员映射表中的masterid字段)来查询人员的详细信息。

id字段(人员映射表中的masterid字段)在数据库中以下图的形式展示:

java角色权限管理系统_java用户角色权限设计_用户角色权限java代码

一个人可能同时属于多个“管理组”。 图中,管理员同时属于两个“管理组”。 因此,人员映射表中将会有两条关于管理员的记录。

通过这种关联方式可以查询管理组中人员的详细信息。 综合起来,我们可以知道一个管理组中有哪些人,以及这个人的详细信息。

结合上面提到的权限表和权限映射表,实现了需求中的“分组”操作,如下图:

实际上,管理组表只记录了组的基本信息,如名称、组ID等。组内人员的详细信息,以及该组可以执行的权限的详细信息都记录在人员表和权限表。 这两个映射表真正记录了谁在一个组中以及他们可以执行什么权限。 通过两个映射表的连接,可以实现三个实体表之间的交互,从而完成需求中提到的“分组”操作。

我们来看一下权限列表和权限表之间的交互。 这两个表的字段关系如下:

这两个表使用 actioncolumnid 字段关联。 这个关联在数据库中的表现如下:

java角色权限管理系统_java用户角色权限设计_用户角色权限java代码

如图所示,通过这种关联方法,我们可以非常清楚的看到权限表中的权限属于哪一列。

现在,数据库结构已经非常清晰了,权限分配和“分组”操作的功能都已经实现了。 接下来我们来分析一下权限管理系统需求中提到的复用性问题。

为什么使用这种数据库设计方法构建的系统可以被重用?

综上所述,通过这样设计数据库,系统是完全可重用的,能够经受住“变化”的考验。

总结:

这个系统的关键点在于三个实体表牢牢抓住了系统的核心组件,两个映射表完美映射了三个实体表之间的交互。 困难在于理解映射表的工作原理,映射表记录关系并实现“组”操作的概念。 系统总体设计的思想是可以在不同的MIS系统中“复用”,以满足不同系统的功能权限设置。

附录:

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

我们看一下权限管理系统的数据库表设计,分为六张表,如下图:

动作表:

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

动作列表:

动作列表记录了动作的列。 系统运行时,左侧菜单栏提供了多种不同的功能。 每列都是一列。 每添加一列,表中就会添加一条记录。 相应地,左侧菜单栏中将添加一个新栏目。

动作组表:

java角色权限管理系统_java用户角色权限设计_用户角色权限java代码

动作组表记录了动作所在的组。

组经理表:

groupmanager表记录了管理组的相关信息。 每次添加管理组时,都会在此处添加一条记录。

主组表:

mastergroup表记录了管理员所属的管理组。 由于一个管理员可能同时属于多个组,因此表中可能存在一个管理员的多条记录。

主表:

主表记录了所有管理员的信息。 每次添加管理员时3D植物,都会在表中添加一条记录。

文章来源:https://my.oschina.net/geewer/blog/174697?p=1