一种后台管理系统的权限控制方法和装置与流程

本发明实施例涉及网络技术领域，特别是涉及一种后台管理系统的权限控制方法和装置。

背景技术：

权限控制一般是指一个系统的安全规则或者安全策略，其中规定用户可以访问而且只能访问自己被授权的资源，不多不少。一般来说，只要某个系统有用户和密码，就需要在该系统的后台管理系统中进行权限控制。目前的权限控制系统都是基于关系型数据库实现的。在现有的权限控制系统中，需要设计一个URL关系对应表，其中存放有所有的功能的URL，当用户发送请求时，系统会判断此URL+请求类型所对应的功能与用户的角色权限是否相符，如果相符则执行相关的请求，反之则拒绝该请求。

发明人在实施本申请的过程中发现，在上述操作中会涉及很多许多复杂的关系表，增加了数据库的操作复杂性，速度和性能均受到关系型数据库的影响，从而使权限控制的执行效率较低，用户体验较差。

技术实现要素：

有鉴于此，本发明实施例提供了一种后台管理系统的权限控制方法和装置，以解决现有权限控制的执行效率较低的问题。

为了解决上述问题，本发明实施例公开了一种后台管理系统的权限控制方法，具体包括如下步骤：

预置用户关系、部门关系和角色；

在对一个用户开通权限时，根据所述用户关系和所述部门关系将所述用户授予相应的所述角色；

根据所述角色生成与用户对应的搜索引擎索引项；

当用户发送请求时，利用搜索引擎从所述搜索引擎索引项中查询所述用户是否拥有与所述请求对应的操作权限。

可选的，所述预置用户关系、部门关系和角色，包括：

获取所述用户关系和所述部门关系；

根据管理需要预置多个角色，所述角色包含一种或多种操作权限；

将所述用户关系、所述部门关系和所述角色存入一个非关系型数据库。

可选的，所述搜索引擎索引项中包含所述用户的操作权限。

可选的，所述当用户发送请求时，利用搜索引擎从所述搜索引擎索引项中查询所述用户是否拥有与所述请求对应的操作权限，包括：

当所述用户发送请求时，利用所述搜索引擎查询所述搜索引擎索引项；

判断所述搜索引擎索引项中包含的操作权限是否允许所述请求包含的当前操作请求执行；

如果所述操作权限允许所述当前操作请求的执行，则判定发出所述请求的用户具有与所述请求对应的操作权限，反之则不具有所述操作权限。

相应地，为了保证上述权限控制方法的实施，本发明实施例还提供了一种后台管理系统的权限控制装置，具体包括：

数据预置模块，用于预置用户关系、部门关系和角色；

角色授予模块，用于在对一个用户开通权限时，根据所述用户关系和所述部门关系将所述用户授予相应的所述角色；

索引项生成模块，用于根据所述角色生成与用户对应的搜索引擎索引项；

权限验证模块，用于当用户发送请求时，利用搜索引擎从所述搜索引擎索引项中查询所述用户是否拥有与所述请求对应的操作权限。

可选的，所述数据预置模块包括：

数据获取单元，用于获取所述用户关系和所述部门关系；

角色配置单元，用于根据管理需要预置多个角色，所述角色包含一种或多种操作权限；

数据存储单元，用于将所述用户关系、所述部门关系和所述角色存入一个非关系型数据库。

可选的，所述搜索引擎索引项中包含所述用户的操作权限。

可选的，所述权限验证模块包括：

索引项查询单元，用于当所述用户发送请求时，利用所述搜索引擎查询所述搜索引擎索引项；

权限判断单元，用于判断所述搜索引擎索引项中包含的操作权限是否允许所述请求包含的当前操作请求执行；

权限判定单元，用于当所述操作权限允许所述当前操作请求执行时，判定发出所述请求的用户具有与所述请求对应的操作权限，反之则判定不具有所述操作权限。

从上述技术方案可以看出，本发明实施例提供了一种后台管理系统的权限控制方法和装置，即通过该后台管理系统实现对网站的用户的操作权限进行控制，具体为首先预置用户关系、部门关系和角色；在对一个用户开通权限时，根据用户关系和部门关系将用户授予相应的所述角色；根据授予的角色生成与用户对应的搜索引擎索引项；当用户发送请求时，利用搜索引擎搜索从搜索引擎索引项中查询用户是否拥有与所述请求对应的操作权限。由此可以看出，本发明实施例提供的权限控制方法和装置不涉及复杂的关系表，从而无需复杂的查表操作，仅利用搜索引擎进行查询即可实现对用户的操作权限的控制，执行效率较高，进而能提高了用户体验。

附图说明

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

图1是本发明实施例的一种后台管理系统的权限控制方法的步骤流程图；以及

图2是本发明实施例的一种后台管理系统的权限控制装置的结构框图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

实施例一

图1为本发明实施例的一种后台管理系统的权限控制方法的步骤流程图。

参照图1所示，本实施例提供的权限控制方法用于为具有用户和密码的网站的后台管理系统提供权限控制，该权限控制方法的具体步骤包括：

S101：预置用户关系、部门关系和多个角色。

用户关系是指能够获取上述网站服务的多个用户之间的关系，其中包括有每个用户的用户资料，这些用户一般指这些网站中预先注册的合法用户，也可以是临时分配的临时用户。部门之间的关系指这些用户所述部门之间的关系，例如上下级部门关系、平行业务部门关系等。

角色是指预先分配的角色身份，角色可以理解为一定数量的操作权限的集合，操作权限的载体。例如：一个论坛系统，“超级管理员”、“普通管理员”“版主”都是角色。版主可管理版内的帖子、可管理版内的用户等，这些是权限。要给某个用户授予这些权限，不需要直接将权限授予用户，可将“版主”这个角色赋予该用户。

上述操作权限是指对功能模块的操作，例如对上传文件的删改，菜单的访问，甚至页面上某个按钮、某个图片的可见性控制，都属于操作权限的范畴。

具体预置的过程包括如下步骤：

步骤1：获取上述用户关系和部门关系，获取过程可以是接收提前输入的相关数据。

步骤2：根据管理需要预置多个角色，每个角色包含一种或多种的操作权限，例如上述“超级管理员”、“普通管理员”和“版主”等。

步骤3：将上述用户关系、部门关系和角色存入一个非关系型数据库。非关系型数据库是指相对于传统的关系型数据库而提出的一种理念。它以键值对存储，且结构不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加一些自己的键值对，这样就不会局限于固定的结构，可以减少一些时间和空间的开销。利用这种方式，用户可以根据需要去添加自己需要的字段，这样，为了获取用户的不同信息，不需要像关系型数据库中对多表进行关联查询。仅需要根据id取出相应的value就可以完成查询。

S102：根据用户关系和部门关系对用户授予相应的角色。

当对一个用户开通相应的权限时，根据上述用户关系、部门关系和具体的业务需求，对该申请开通权限的用户授予一定的角色，该角色与上述所定义的角色相同，即包含一种或多种的操作权限。

S103：生成与用户对应的搜索引擎索引项。

即根据上述对用户授予的角色，生成与该用户对应的搜索引擎索引项，由于角色实际是包含一系列的操作权限的信息集成，因此上述搜索引擎索引项实际包含了该用户的操作权限。

在根据管理员的操作授予多个用户不同权限时，将分别对应不同用户的多个搜索引擎索引项存储为一个索引表，从而方便搜索引擎查询。这里的搜索引擎是指站内搜索引擎。

S104：当用户发送请求时，对用户的操作权限进行验证。

当用户发送请求时，该请求中一定会包含一定的操作请求，这时对该用户是否拥有该操作请求相对应的操作权限进行验证。该验证过程是通过上述搜索引擎进行的，具体的验证过程包括如下步骤：

步骤1：当用户发送请求时，利用上述搜索引擎从上述索引表中查询与用户对应的搜索引擎索引项。

步骤2：在查询到与用户对应的搜索引擎索引项后，判断该索引项中包含的操作权限是否允许用户所发送的请求所包含的操作请求执行。例如，如果发送请求的用户是“超级管理员”，则其对应的搜索引擎索引项中所包含的操作权限是最全面的，其在发送的请求中包含的任何操作请求都是允许的；但是对于“版主”用户来说，其只能进行简单的审核，而不允许进行删除。

步骤3：通过以上的判断，如果与用户对应的搜索引擎索引项中包含的操作权限运行该用户发送的请求中的操作请求执行，则判定该用户具有与请求操作所对应的操作权限，反之则不具有该操作权限，并进一步拒绝执行该操作请求。通过以上操作可以实现用户的权限控制。

从上述技术方案可以看出，本实施例提供了一种后台管理系统的权限控制方法，即通过该后台管理系统实现对网站的用户的操作权限进行控制，具体为首先预置用户关系、部门关系和角色；在对一个用户开通权限时，根据用户关系和部门关系将用户授予相应的所述角色；根据授予的角色生成与用户对应的搜索引擎索引项；当用户发送请求时，利用搜索引擎搜索从搜索引擎索引项中查询用户是否拥有与所述请求对应的操作权限。由此可以看出，本发明实施例提供的权限控制方法不涉及复杂的关系表，从而无需复杂的查表操作，仅利用搜索引擎进行查询即可实现对用户的操作权限的控制，执行效率较高，进而能提高了用户体验。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明实施例并不受所描述的动作顺序的限制，因为依据本发明实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本发明实施例所必须的。

实施例二

图2为本发明实施例的一种后台管理系统的权限控制装置的结构框图。

参照图2所示，本实施例提供的权限控制装置用于为具有用户和密码的网站的后台管理系统提供权限控制，该权限控制装置具体包括数据预置模块10、角色授予模块20、索引项生成模块30和权限验证模块40。

数据预置模块10用于预置用户关系、部门关系和多个角色。

用户关系是指能够获取上述网站服务的多个用户之间的关系，其中包括有每个用户的用户资料，这些用户一般指这些网站中预先注册的合法用户，也可以是临时分配的临时用户。部门之间的关系指这些用户所述部门之间的关系，例如上下级部门关系、平行业务部门关系等。

角色是指预先分配的角色身份，角色可以理解为一定数量的操作权限的集合，操作权限的载体。例如：一个论坛系统，“超级管理员”、“普通管理员”“版主”都是角色。版主可管理版内的帖子、可管理版内的用户等，这些是权限。要给某个用户授予这些权限，不需要直接将权限授予用户，可将“版主”这个角色赋予该用户。

上述操作权限是指对功能模块的操作，例如对上传文件的删改，菜单的访问，甚至页面上某个按钮、某个图片的可见性控制，都属于操作权限的范畴。

数据预置模块具体包括数据获取单元11、角色配置单元12和数据存储单元13。

数据获取单元11用于获取上述用户关系和部门关系，获取过程可以是接收提前输入的相关数据。

角色配置单元用于根据管理需要预置多个角色，每个角色包含一种或多种的操作权限，例如上述“超级管理员”、“普通管理员”和“版主”等。

数据存储单元13用于将上述用户关系、部门关系和角色存入一个非关系型数据库。非关系型数据库是指相对于传统的关系型数据库而提出的一种理念。它以键值对存储，且结构不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加一些自己的键值对，这样就不会局限于固定的结构，可以减少一些时间和空间的开销。利用这种方式，用户可以根据需要去添加自己需要的字段，这样，为了获取用户的不同信息，不需要像关系型数据库中对多表进行关联查询。仅需要根据id取出相应的value就可以完成查询。

角色授予模块20用于根据用户关系和部门关系对用户授予相应的角色。

当对一个用户开通相应的权限时，角色授予模块20用于根据上述用户关系、部门关系和具体的业务需求，对该申请开通权限的用户授予一定的角色，该角色与上述所定义的角色相同，即包含一种或多种的操作权限。

索引项生成模块30用于生成与用户对应的搜索引擎索引项。

即根据上述对用户授予的角色，生成与该用户对应的搜索引擎索引项，由于角色实际是包含一系列的操作权限的信息集成，因此上述搜索引擎索引项实际包含了该用户的操作权限。

在根据管理员的操作授予多个用户不同权限时，将分别对应不同用户的多个搜索引擎索引项存储为一个索引表，从而方便搜索引擎查询。这里的搜索引擎是指站内搜索引擎。

权限验证模块40用于当用户发送请求时，对用户的操作权限进行验证。

当用户发送请求时，该请求中一定会包含一定的操作请求，这时对该用户是否拥有该操作请求相对应的操作权限进行验证。该验证过程是通过上述搜索引擎进行的，该权限验证模块具体包括索引项查询单元41、权限判断单元42和权限判定单元43。

索引项查询单元41用于当用户发送请求时，利用上述搜索引擎从上述索引表中查询与用户对应的搜索引擎索引项。

权限判断单元42用于在查询到与用户对应的搜索引擎索引项后，判断该索引项中包含的操作权限是否允许用户所发送的请求所包含的操作请求执行。例如，如果发送请求的用户是“超级管理员”，则其对应的搜索引擎索引项中所包含的操作权限是最全面的，其在发送的请求中包含的任何操作请求都是允许的；但是对于“版主”用户来说，其只能进行简单的审核，而不允许进行删除。

权限判定单元43用于当与用户对应的搜索引擎索引项中包含的操作权限运行该用户发送的请求中的操作请求执行时，判定该用户具有与请求操作所对应的操作权限，反之则不具有该操作权限，并进一步拒绝执行该操作请求。通过以上操作可以实现用户的权限控制。

从上述技术方案可以看出，本实施例提供了一种后台管理系统的权限控制装置，即通过该后台管理系统实现对网站的用户的操作权限进行控制，具体为首先预置用户关系、部门关系和角色；在对一个用户开通权限时，根据用户关系和部门关系将用户授予相应的所述角色；根据授予的角色生成与用户对应的搜索引擎索引项；当用户发送请求时，利用搜索引擎搜索从搜索引擎索引项中查询用户是否拥有与所述请求对应的操作权限。由此可以看出，本发明实施例提供的权限控制装置不涉及复杂的关系表，从而无需复杂的查表操作，仅利用搜索引擎进行查询即可实现对用户的操作权限的控制，执行效率较高，进而能提高了用户体验。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述地比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域内的技术人员应明白，本发明实施例可提供为方法、装置、或计算机程序产品。因此，本发明实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明实施例是参照根据本发明实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解，可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本发明实施例所提供的技术方案进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。