CN110808964A - 一种权限管理的方法及装置 - Google Patents

Abstract

本申请一种权限管理的方法及装置，通过服务器端获取用户的访问请求，访问请求中包括用户信息及请求路由；根据用户信息从权限管理数据库中获取对应的用户角色权限；根据请求路由从XML文件中获取对应的所需权限；确定所述用户角色权限中是否包括所述所需权限，如果否则拒绝访问；如果是，则继续访问。本申请把权限分为两层进行判断，首先控制层通过请求路由，判断是否有访问权限，而视图层则通过ActionType属性判断是否显示某一标签或控件。控制层只需要在构造函数中处理权限即可，而视图层只需要提取一个公共函数进行权限判断即可，这样形成了权限的集中管理，权限层次清楚。并且可通过XML文件很方便的对权限进行扩展。

Description

一种权限管理的方法及装置

技术领域

本申请涉及网络技术领域，尤其涉及一种权限管理方法及装置。

背景技术

在开发系统过程中，对于权限处理总会有一些问题。

(一)权限错综复杂不好管理：不同的账号需要有不同的权限，相同的账号也会存在不同的角色，所以相同账号不同角色的权限不同。

(二)权限管理不统一，维护困难：不同的入口需要判断是否拥有某一权限，随着入口的增多，权限种类的变化，需要去改变相应的入口。

(三)权限处理复杂：不同的权限需要保存不同的值，权限保存的方式一般是用某一符号分割权限进行保存，或者每个权限保存一条数据，这种存储权限方式很难看出权限层级关系，在获取权限时，每个路由进行权限判断，对于客户端的视图层是否有权限展示也需要一个一个的判断。

发明内容

本申请提供了一种权限管理方法及装置，以解决现有权限错综复杂不好管理等问题。

第一方面，为实现上述目的，本申请提供了一种权限管理方法，所述方法包括：

服务器端获取用户的访问请求，所述访问请求中包括用户信息及请求路由；

根据所述用户信息从权限管理数据库中获取对应的用户角色权限；

根据所述请求路由从XML文件中获取对应的所需权限；

确定所述用户角色权限中是否包括所述所需权限，如果否则拒绝访问；如果是，则继续访问。

第二方面，为实现上述目的，本申请提供了另一种权限管理方法，所述方法包括：

获取用户的访问请求，所述访问请求中包括用户信息及请求路由；

根据所述请求路由从XML文件中获取对应的所需权限；

根据所述用户信息从权限管理数据库中获取对应的用户角色权限；

确定所述用户角色权限中是否包括所述所需权限，如果否则拒绝访问；如果是，则继续访问。

进一步地，所述根据所述用户信息从权限管理数据库中获取对应的用户角色权限，具体包括：

从所述用户信息中获取用户标识；

遍历所述权限管理数据库，获取与所述用户标识相对应的用户角色权限。

进一步地，所述根据所述请求路由从XML文件中获取对应的所需权限，具体包括：

遍历所述XML文件，获取与所述请求路由相对应的预设权限；

分解所述预设权限，获取对应的所需权限。

进一步地，所述预设权限包括权限名称和所述权限名称对应的路由地址。

进一步地，所述用户角色权限为预设格式权限。

进一步地，如果是，则继续访问，具体为：

所述服务端将所述用户角色权限反馈给客户端。

进一步地，所述服务端将所述用户角色权限反馈给客户端之后，还包括：

所述客户端接收所述用户角色权限；

遍历每一个需要权限验证的控件；

通过显示权限判断是否显示所述控件。

第三方面，本申请还提供一种权限管理装置，所述装置包括：

第一访问请求获取单元，用于服务器端获取用户的访问请求，所述访问请求中包括用户信息及请求路由；

第一用户角色权限获取单元，用于根据所述用户信息从权限管理数据库中获取对应的用户角色权限；

第一所需权限获取单元，用于根据所述请求路由从XML文件中获取对应的所需权限；

第一访问权限判断单元，用于确定所述用户角色权限中是否包括所述所需权限，如果否则拒绝访问；如果是，则继续访问。

第四方面，本申请还提供另一种权限管理装置，所述装置包括：

第二访问请求获取单元，用于服务器端获取用户的访问请求，所述访问请求中包括用户信息及请求路由；

第二所需权限获取单元，根据所述请求路由从XML文件中获取对应的所需权限；

第二用户角色权限获取单元，根据所述用户信息从权限管理数据库中获取对应的用户角色权限；

第二访问权限判断单元，确定所述用户角色权限中是否包括所述所需权限，如果否则拒绝访问；如果是，则继续访问。

第五方面，为实现上述目的，本申请提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现第一方面任一项权限管理方法的步骤。

第六方面，为实现上述目的，本申请提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现第一方面任一项权限管理方法的步骤。

由以上技术方案可见，本申请实施例提供的一种权限管理的方法及装置，通过服务器端获取用户的访问请求，所述访问请求中包括用户信息及请求路由；根据所述用户信息从权限管理数据库中获取对应的用户角色权限；根据所述请求路由从XML文件中获取对应的所需权限；确定所述用户角色权限中是否包括所述所需权限，如果否则拒绝访问；如果是，则继续访问。本申请把权限分为两层进行判断，首先控制层通过请求路由，判断是否有访问权限，而视图层则通过ActionType属性判断是否显示某一标签或控件。控制层只需要在构造函数中处理权限即可，而视图层只需要提取一个公共函数进行权限判断即可，这样形成了权限的集中管理，并且权限层次清楚。并且可通过XML文件很方便的对权限进行扩展。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为数据库中多条数据方式保存权限管理方案的流程示意图；

图2为使用XML文件保存权限的上级关系的权限管理方案的流程示意图；

图3为本申请实施例提供的一种权限管理方法的流程示意图；

图4为本申请实施例提供的所述用户信息从权限管理数据库中获取对应的用户角色权限的流程示意图；

图5为本申请实施例提供的所述请求路由从XML文件中获取对应的所需权限的流程示意图；

图6为本申请实施例提供的另一种权限管理方法的流程示意图；

图7为本申请实施例提供的控件显示判断的流程示意图；

图8为本申请实施例提供的一种权限管理装置的结构示意图；

图9为本申请实施例提供的一种权限管理装置的结构示意图；

图10为本申请实施例提供的另一种权限管理装置的结构示意图。

具体实施方式

下面通过对本申请进行详细说明，本申请的特点和优点将随着这些说明而变得更为清楚、明确。

在这里专用的词“示例性”意为“用作例子、实施例或说明性”。这里作为“示例性”所说明的任何实施例不必解释为优于或好于其它实施例。尽管在附图中示出了实施例的各种方面，但是除非特别指出，不必按比例绘制附图。

在本申请的描述中，需要说明的是，术语“上”、“下”、“内”、“外”、“前”、“后”、“左”和“右”等指示的方位或位置关系为基于本申请工作状态下的方位或位置关系，仅是为了便于描述本申请和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本申请的限制。此外，术语“第一”、“第二”、“第三”和“第四”仅用于描述目的，而不能理解为指示或暗示相对重要性。

本申请人发现，在权限的保存方案上不同的角色保存不同的权限，对于一个角色有多个权限的保存方式有两种：一种是以一种符号分割不同的权限进行保存，另一种是以多条数据的形式进行保存。对于区分权限的关系也有两种方式：一种是把权限以上下级的关系放入到XML文件或其他文件中，如：

其中module下的name、permission为一级权限，item下的name、permission 为二级权限。另一种区分权限的关系是在数据库中保存权限时每一个权限都有一个id，然后把父级权限的id保存到子级权限中，这样来区分上下级权限关系。

二者在处理访问权限时，需要在路由对应的相应的方法或函数下进行权限判断，如：访问文章的详情路由www.xxx.com/article/info所对应的方法为 articleInfo()，那就需要在个方法内进行权限判断是否有访问权限。

对于视图界面的展示也是需要进行权限判断的，如：在判断是否可见文章的编辑按钮时，需要判断是否有文章的编辑权限，然后判断是否显示其按钮。这种方式需要在每一个按钮的地方进行权限判断，再进行显示或不显示。

现有技术对权限的保存、权限获取、权限判断、权限访问及视图界面的展示都比较复杂，不便于维护和管理。

如图1所示，是数据库中多条数据方式保存权限管理方案：

首先，用户访问某一页面，事实上每一个页面都会有相应的路由地址，每一个路由地址会访问到所对应的控制器。

然后，控制器从数据库中获取相应角色对应的权限，如果用户没有访问当前控制器的权限，直接通知视图层无权限访问。如果有权限访问，则整理当前用户可访问的权限，并把用户所拥有的权限传递到视图层。

最后，视图层通过所拥有的权限判断页面内所有需要权限的模块进行显示或不显示。

但是上述方案会有以下几个问题：

权限的更改比较麻烦，每一个角色每一个权限都需要保存一条数据，更改权限时需要逐条判断，进行更改。

代码混乱，视图层每一个需要权限判断的地方都需要单独的判断权限，并且需要所对应的控制器把权限传递到视图层。

如图2所述，这是一种使用XML文件保存权限的上级关系的权限管理方案：

首先，用户访问某一页面，事实上每一个页面都会有相应的路由地址，每一个路由地址会访问到所对应的控制器。

然后，控制器从数据库中获取相应角色对应的权限，如果用户没有访问前控制器权限，直接视图层无权限访问。如果有权限访问，则整理当前用户可访问的权限，并把用户所拥有的权限传递到视图层。

最后，视图层通过所拥有的权限判断页面内所有需要权限的模块进行显示或不显示。

但是上述方案会有以下几个问题：权限管理复杂，用户访问的每一个路由地址所对应的判断方法内都要进行权限判断。

代码维护困难，每个路由地址对应的判断方法把相应的权限传递到视图层后，视图层每一个展示的地方都需要进行权限判断再进行展示，不能对权限进行统一管理。

图3为本申请实施例提供的一种权限管理方法的流程示意图，如图3所示，所述方法包括步骤S101至S104。

S101：服务器端获取用户的访问请求，所述访问请求中包括用户信息及请求路由。

具体是实施时，用户访问某一页面，每一个页面都会有相应的路由地址，每一个路由地址会访问到所对应的控制器，但会先进入控制器的构造函数，此时先在构造函数做权限判断，具体判断流程如步骤S101-S104。

S102：根据所述用户信息从权限管理数据库中获取对应的用户角色权限。

具体实施时，所述用户角色权限为预设格式权限。数据库中权限的保存方式是以一种符号分离各个权限，每个权限的子权限用另一种符号分离并紧随其权限之后，如：user|add|edit|info,service|info。这里用“,”分离的user和service 可看成用户的用户管理权限和服务管理权限，而user之后的“|”分离的“add”、“edit”、“info”看成是用户管理权限的添加权限、编辑权限、详情权限。这种权限存储方式便于管理，权限层次也很清晰。

如图4所示，所述根据所述用户信息从权限管理数据库中获取对应的用户角色权限，具体包括：

S201：从所述用户信息中获取用户标识；

S202：遍历所述权限管理数据库，获取与所述用户标识相对应的用户角色权限。

具体实施时，从所述用户信息中获取用户标识，所述用户标识可为关键字或用户ID，之后遍历配置好的所述权限管理数据库，获取与所述用户标识相对应的用户角色权限，获取到的用户角色权限格式，如：user|add|edit|info,service|info，解析所述用户角色权限对应的权限格式，可知用户角色权限包括user和 service，user之后的“|”分离的“add”、“edit”、“info”为其子权限。缓存上述权限数据至页面，这样可以随时获取用户拥有的用户角色权限。

S103：根据所述请求路由从XML文件中获取对应的所需权限。

具体实施时，所述XML文件中包括系统中所有权限，为预先配置的预设权限。所述XML文件与所述权限管理数据库独立设置。所述预设权限包括权限名称和所述权限名称对应的路由地址，如：

通过上述XML文件内容可以清晰的看出权限的层级关系及每个权限对应的路由地址，并且XML文件中的type用于扩展，比如type＝"admin"表示只有管理员可以访问，type＝"doctor"表示只有医生可访问，比如某一账号拥有某一角色权限同时也有不同的身份，这时这个type中的admin，doctor就是用来表示身份的。

另外还可以通过可通过xml很方便的对权限进行扩展。比如场景：同一个账号，在不同的区域(A区，B区)，有不同的角色(管理员，医生)，假如当前账号在A区的权限包括用户的添加、查看、修改，在B区的权限包括新闻的添加、查看、修改。但是规定当前账号切换不同角色时(管理员，医生)权限不同，如管理员只有查看权限，医生有添加、查看、修改权限，那就可以在xml 上添加属性，比如添加type,并给type赋值，比如当type＝”doctor”表示当前权限只能是医生才能访问。

如图5所示，所述根据所述请求路由从XML文件中获取对应的所需权限，具体包括：

S301：遍历所述XML文件，获取与所述请求路由相对应的预设权限；

S302：分解所述预设权限，获取对应的所需权限。

具体实施时，遍历所述XML文件，通过已知的请求路由，从XML文件中获取与所述请求路由相对应的预设权限。如所述请求路由为url＝"/user/doAdd"，遍历所述XML文件，查询到对应的预设权限为：<SubModule name＝"添加" type＝"doctor"permission＝"add"url＝"/user/doAdd"/>，从中获知所述所需权限为 "add"。

S104：确定所述用户角色权限中是否包括所述所需权限，如果否则拒绝访问；如果是，则继续访问。

S105：如果是，则继续访问具体为：所述服务器端将所述用户角色权限反馈给客户端。

在前述步骤中获取了权限管理数据库中所述用户角色权限，和XML文件中的所述所需权限，在步骤S104中，则进行访问权限的判断，即确定所述用户角色权限中是否包括所述所需权限，如果缓存的所述用户角色权限中没有所述所需权限，说明该用户没有访问权限，则直接结束访问。如果缓存的所述用户角色权限中有所述所需权限，则进入该请求路由对应的控制器，控制器整理当前请求路由下用户所拥有的用户角色权限返回给客户端对应的视图层。把所有权限都返回视图层可以减少客户端与服务器端的频繁交互。

图6为本申请实施例提供的另一种权限管理方法的流程示意图，如图6所示，所述方法包括步骤S106至S109。

S106：获取用户的访问请求，所述访问请求中包括用户信息及请求路由。

S107：根据所述请求路由从XML文件中获取对应的所需权限。

S108：根据所述用户信息从权限管理数据库中获取对应的用户角色权限。

S109：确定所述用户角色权限中是否包括所述所需权限，如果否则拒绝访问；如果是，则继续访问。

因为所述权限管理数据库与所述XML文件为独立设置，因此步骤S107与步骤S108可以不区分先后顺序，具体实现方式如前所述，在此不再赘述。

本申请中将访问权限判断和控件显示判断分为两步独立判断，所以在所述服务端将所述用户角色权限反馈给客户端之后，控件显示判断如图7所示，还包括：

S1001：所述客户端接收所述用户角色权限。

S1002：遍历每一个需要权限验证的控件。

S1003：通过显示权限判断是否显示所述控件。

预先设置时，在视图层在需要做权限判断的控件或标签上添加一个属性，并给这个属性赋值，如：<button ActionType＝"add"></button>。对于这个button 标签上添加的属性ActionType表示这个button标签是受权限控制的，至于这个ActionType的属性值add则表示当前视图层所对应权限的子权限。比如，某一用户拥有用户管理的添加权限，那这个用户现在就拥有两个权限：一个是用户管理权限，另一个是用户管理权限的子权限添加权限。如果当前视图表示用户管理界面，那上文中提到的ActionType的属性值add就表示用户管理的添加权限。

视图层先隐藏页面所有带有ActionType属性的控件和标签，然后通过控制层返回的权限直接遍历带有ActionType属性的控件和标签，再通过ActionType 的属性值显示带有ActionType属性的控件和标签。

图8为本申请一具体实施例的流程示意图，如图8所示，本申请把权限分为两层进行判断，首先控制层通过请求路由，判断是否有访问权限，而视图层则通过ActionType属性判断是否显示某一标签或控件。控制层只需要在构造函数中处理权限即可，而视图层只需要提取一个公共函数进行权限判断即可，这样形成了权限的集中管理，权限层次清楚，并且可通过XML文件很方便的对权限进行扩展。

与本申请提供的一种权限管理的方法实施例相对应，本申请还提供一种权限管理的装置的实施例。参考图9，为本申请实施例提供的一种权限管理的装置的结构示意图，所述装置包括：

第一访问请求获取单元，用于服务器端获取用户的访问请求，所述访问请求中包括用户信息及请求路由。

第一用户角色权限获取单元，用于根据所述用户信息从权限管理数据库中获取对应的用户角色权限；所述根据所述用户信息从权限管理数据库中获取对应的用户角色权限，具体包括：

从所述用户信息中获取用户标识；

遍历所述权限管理数据库，获取与所述用户标识相对应的用户角色权限。

第一所需权限获取单元，用于根据所述请求路由从XML文件中获取对应的所需权限；所述根据所述请求路由从XML文件中获取对应的所需权限，具体包括：

遍历所述XML文件，获取与所述请求路由相对应的预设权限；

分解所述预设权限，获取对应的所需权限。

第一访问权限判断单元，用于确定所述用户角色权限中是否包括所述所需权限，如果否则拒绝访问；如果是，则继续访问。

与本申请提供的另一种权限管理的方法实施例相对应，本申请还提供另一种权限管理的装置的实施例。参考图10，为本申请实施例提供的另一种权限管理的装置的结构示意图，所述装置包括：

第二访问请求获取单元，用于服务器端获取用户的访问请求，所述访问请求中包括用户信息及请求路由。

第二所需权限获取单元，根据所述请求路由从XML文件中获取对应的所需权限；所述根据所述请求路由从XML文件中获取对应的所需权限，具体包括：

遍历所述XML文件，获取与所述请求路由相对应的预设权限；

分解所述预设权限，获取对应的所需权限。

第二用户角色权限获取单元，根据所述用户信息从权限管理数据库中获取对应的用户角色权限；所述根据所述用户信息从权限管理数据库中获取对应的用户角色权限，具体包括：

从所述用户信息中获取用户标识；

遍历所述权限管理数据库，获取与所述用户标识相对应的用户角色权限。

第二访问权限判断单元，确定所述用户角色权限中是否包括所述所需权限，如果否则拒绝访问；如果是，则继续访问。

本申请实施例提供的一种权限管理的方法及装置，通过服务器端获取用户的访问请求，所述访问请求中包括用户信息及请求路由；根据所述用户信息从权限管理数据库中获取对应的用户角色权限；根据所述请求路由从XML文件中获取对应的所需权限；确定所述用户角色权限中是否包括所述所需权限，如果否则拒绝访问；如果是，则继续访问。本申请把权限分为两层进行判断，首先控制层通过请求路由，判断是否有访问权限，而视图层则通过ActionType属性判断是否显示某一标签或控件。控制层只需要在构造函数中处理权限即可，而视图层只需要提取一个公共函数进行权限判断即可，这样形成了权限的集中管理，并且权限层次清楚。并且可通过XML文件很方便的对权限进行扩展。

根据上述权限管理的方法，本申请实施例还提供一种可读存储介质和一种计算机设备。可读存储介质上存储有可执行程序，该程序被处理器执行时实现上述权限管理的方法的步骤；计算机设备包括存储器、处理器及存储在存储器上并可在处理器上运行的可执行程序，处理器执行程序时实现上述权限管理的方法的步骤。

以上结合具体实施方式和范例性实例对本申请进行了详细说明，不过这些说明并不能理解为对本申请的限制。本领域技术人员理解，在不偏离本申请精神和范围的情况下，可以对本申请技术方案及其实施方式进行多种等价替换、修饰或改进，这些均落入本申请的范围内。本申请的保护范围以所附权利要求为准。

Claims (10)

1.一种权限管理方法，其特征在于，所述方法包括：

服务器端获取用户的访问请求，所述访问请求中包括用户信息及请求路由；

根据所述用户信息从权限管理数据库中获取对应的用户角色权限；

根据所述请求路由从XML文件中获取对应的所需权限；

确定所述用户角色权限中是否包括所述所需权限，如果否则拒绝访问；如果是，则继续访问。

2.一种权限管理方法，其特征在于，所述方法包括：

获取用户的访问请求，所述访问请求中包括用户信息及请求路由；

根据所述请求路由从XML文件中获取对应的所需权限；

根据所述用户信息从权限管理数据库中获取对应的用户角色权限；

确定所述用户角色权限中是否包括所述所需权限，如果否则拒绝访问；如果是，则继续访问。

3.根据权利要求1或2所述权限管理方法，其特征在于，所述根据所述用户信息从权限管理数据库中获取对应的用户角色权限，具体包括：

从所述用户信息中获取用户标识；

遍历所述权限管理数据库，获取与所述用户标识相对应的用户角色权限。

4.根据权利要求1或2所述权限管理方法，其特征在于，所述根据所述请求路由从XML文件中获取对应的所需权限，具体包括：

遍历所述XML文件，获取与所述请求路由相对应的预设权限；

分解所述预设权限，获取对应的所需权限。

5.根据权利要求4所述的权限管理方法，其特征在于，所述预设权限包括权限名称和所述权限名称对应的路由地址。

6.根据权利要求3所述的权限管理方法，其特征在于，所述用户角色权限为预设格式权限。

7.根据权利要求1或2所述权限管理方法，其特征在于，如果是，则继续访问，具体为：

所述服务端将所述用户角色权限反馈给客户端。

8.根据权利要求7所述权限管理方法，其特征在于，所述服务端将所述用户角色权限反馈给客户端之后，还包括：

所述客户端接收所述用户角色权限；

遍历每一个需要权限验证的控件；

通过显示权限判断是否显示所述控件。

9.一种权限管理装置，其特征在于，所述装置包括：

第一访问请求获取单元，用于服务器端获取用户的访问请求，所述访问请求中包括用户信息及请求路由；

第一用户角色权限获取单元，用于根据所述用户信息从权限管理数据库中获取对应的用户角色权限；

第一所需权限获取单元，用于根据所述请求路由从XML文件中获取对应的所需权限；

第一访问权限判断单元，用于确定所述用户角色权限中是否包括所述所需权限，如果否则拒绝访问；如果是，则继续访问。

10.一种权限管理装置，其特征在于，所述装置包括：

第二访问请求获取单元，用于服务器端获取用户的访问请求，所述访问请求中包括用户信息及请求路由；

第二所需权限获取单元，根据所述请求路由从XML文件中获取对应的所需权限；

第二用户角色权限获取单元，根据所述用户信息从权限管理数据库中获取对应的用户角色权限；

第二访问权限判断单元，确定所述用户角色权限中是否包括所述所需权限，如果否则拒绝访问；如果是，则继续访问。

Images