权限控制方法、装置、计算机设备、存储介质与流程

1.本技术涉及大数据数据访问技术领域，特别是涉及一种权限控制方法、装置、计算机设备、存储介质和计算机程序产品。


背景技术：

2.随着时代发展和技术的进步，系统也在不断发展和完善，从原有的单一企业开发使用，到现在跨平台、多系统、多渠道、多用户的集成对接开发模式。系统安全在系统开发过程中已经成为一个不可规避的问题，权限控制跟系统安全密不可分。针对不同渠道、不同系统以及不同用户就必须考虑越权问题，明确用户职责、控制渠道访问权限，防止小权限的用户可以使用高权限的管理操作，对保护系统数据安全具有重大意义。
3.传统的权限控制是基于shiro实现的，shiro是一个开源安全框架，能够处理认证、授权、管理会话以及密码加密，可通过编程式、注解式、标签式实现对权限的编码，既能配合spring使用也可以单独使用。但是该方法在使用时，用户权限一旦发生改变，需要修改代码，维护成本高。


技术实现要素：

4.基于此，有必要针对传统的权限控制维护成本高的问题，提供一种能够减少维护成本，使用可靠的权限控制方法、装置、计算机设备、存储介质和计算机程序产品。
5.第一方面，本技术提供了一种权限控制方法。所述方法包括：
6.接收服务请求，获取所述服务请求对应的登录态信息和服务请求对象；所述登录态信息包括用户标识和渠道标识；
7.在配置的登录态信息与服务请求对象的对应关系中，确定是否存在所述登录态信息与所述服务请求对象的对应关系，所述服务请求对象包括接口；
8.若存在，确定所述登录态信息具有使用所述服务请求对象的权限，将所述登录态信息对应的服务请求下发至下游服务模块。
9.在其中一个实施例中，所述服务请求对象还包括角色和菜单，所述对应关系为登录态信息、角色、菜单以及接口的对应关系，所述对应关系中，一个所述登录态信息对应至少一个所述角色，一个所述角色对应至少一个所述菜单，一个所述菜单对应至少一个所述接口。
10.在其中一个实施例中，通过两层缓存结构存储所述对应关系，其中，第一层缓存结构中存储所述登录态信息与所述角色的对应关系，第二层缓存结构中存储所述角色与所述接口的对应关系。
11.在其中一个实施例中，所述方法还包括：
12.在获取到所述服务请求对应的登录态信息之后，对所述第一层缓存结构进行刷新；
13.在获取所述服务请求对应的登录态信息之后，若当前时间与上一次获取到登录态
信息的时间间隔大于预设时间间隔，对所述第二层缓存结构进行刷新。
14.在其中一个实施例中，所述配置的登录态信息与服务请求对象的对应关系的获取方式包括：
15.调用用户服务中的刷新资源表接口，获取系统内所有应用程序接口；
16.获取各所述应用程序接口所在的服务名和接口路径，得到预设接口标识列表。
17.在其中一个实施例中，所述获取各所述应用程序接口所在的服务名和接口路径，得到预设接口标识列表，包括：
18.分别计算各所述应用程序接口所在的服务名和接口路径组成的字符串的消息摘要；
19.分别对各所述消息摘要进行十六进制编码，获得各所述应用服务接口的接口标识；
20.根据各所述应用服务接口的接口标识得到预设接口标识列表。
21.在其中一个实施例中，所述方法还包括：
22.接收运营人员发送的配置关系设置指令，所述配置关系设置指令包括登录态信息与角色的对应关系、以及角色与菜单的对应关系；
23.根据所述配置关系设置指令更新所述登录态信息、角色、菜单以及接口的对应关系。
24.在其中一个实施例中，当所述登录态信息中的渠道标识为终端用户渠道时，与所述登录态信息匹配的菜单为虚拟菜单标识。
25.第二方面，本技术还提供了一种权限控制装置。所述装置包括：
26.请求接收模块，用于接收服务请求，获取所述服务请求对应的登录态信息和服务请求对象；所述登录态信息包括用户标识和渠道标识；
27.对应关系确定模块，用于在配置的登录态信息与服务请求对象的对应关系中，确定是否存在所述登录态信息与所述服务请求对象的对应关系，所述服务请求对象包括接口；
28.权限处理模块，用于在所述对应关系确定模块确定存在对应关系时，确定所述登录态信息具有使用所述服务请求对象的权限，将所述登录态信息下发至下游服务模块。
29.在其中一个实施例中，所述服务请求对象还包括角色和菜单，所述对应关系为登录态信息、角色、菜单以及接口的对应关系，所述对应关系中，一个所述登录态信息对应至少一个所述角色，一个所述角色对应至少一个所述菜单，一个所述菜单对应至少一个所述接口。
30.在其中一个实施例中，通过两层缓存结构存储所述对应关系，其中，第一层缓存结构中存储所述登录态信息与所述角色的对应关系，第二层缓存结构中存储所述角色与所述接口的对应关系。
31.在其中一个实施例中，权限控制装置还包括更新模块，所述更新模块用于在获取到所述服务请求对应的登录态信息之后，对所述第一层缓存结构进行刷新；在获取所述服务请求对应的登录态信息之后，若当前时间与上一次获取到登录态信息的时间间隔大于预设时间间隔，对所述第二层缓存结构进行刷新。
32.在其中一个实施例中，权限控制装置还包括配置对应关系获取模块，所述配置对
应关系获取模块用于调用用户服务中的刷新资源表接口，获取系统内所有应用程序接口；获取各所述应用程序接口所在的服务名和接口路径，得到预设接口标识列表。
33.在其中一个实施例中，所述配置对应关系获取模块还用于分别计算各所述应用程序接口所在的服务名和接口路径组成的字符串的消息摘要；分别对各所述消息摘要进行十六进制编码，获得各所述应用服务接口的接口标识；根据各所述应用服务接口的接口标识得到预设接口标识列表。
34.在其中一个实施例中，权限控制装置还包括配置模块，所述配置模块用于接收运营人员发送的配置关系设置指令，所述配置关系设置指令包括登录态信息与角色的对应关系、以及角色与菜单的对应关系；根据所述配置关系设置指令更新所述登录态信息、角色、菜单以及接口的对应关系。
35.在其中一个实施例中，当所述登录态信息中的渠道标识为终端用户渠道时，与所述登录态信息匹配的菜单为虚拟菜单标识。
36.第三方面，本技术还提供了一种计算机设备。所述计算机设备包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现以下步骤：
37.接收服务请求，获取所述服务请求对应的登录态信息和服务请求对象；所述登录态信息包括用户标识和渠道标识；
38.在配置的登录态信息与服务请求对象的对应关系中，确定是否存在所述登录态信息与所述服务请求对象的对应关系，所述服务请求对象包括接口；
39.若存在，确定所述登录态信息具有使用所述服务请求对象的权限，将所述登录态信息对应的服务请求下发至下游服务模块。
40.第四方面，本技术还提供了一种计算机可读存储介质。所述计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现以下步骤：
41.接收服务请求，获取所述服务请求对应的登录态信息和服务请求对象；所述登录态信息包括用户标识和渠道标识；
42.在配置的登录态信息与服务请求对象的对应关系中，确定是否存在所述登录态信息与所述服务请求对象的对应关系，所述服务请求对象包括接口；
43.若存在，确定所述登录态信息具有使用所述服务请求对象的权限，将所述登录态信息对应的服务请求下发至下游服务模块。
44.第五方面，本技术还提供了一种计算机程序产品。所述计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现以下步骤：
45.接收服务请求，获取所述服务请求对应的登录态信息和服务请求对象；所述登录态信息包括用户标识和渠道标识；
46.在配置的登录态信息与服务请求对象的对应关系中，确定是否存在所述登录态信息与所述服务请求对象的对应关系，所述服务请求对象包括接口；
47.若存在，确定所述登录态信息具有使用所述服务请求对象的权限，将所述登录态信息对应的服务请求下发至下游服务模块。
48.上述权限控制方法、装置、计算机设备、存储介质和计算机程序产品，首先接收服务请求，获取服务请求对应的登录态信息和服务请求对象，登录态信息包括用户标识和渠道标识，然后在配置的登录态信息与服务请求对象的对应关系中，确定是否存在登录态信
息与服务请求对象的对应关系，服务请求对象包括接口，若存在，确定登录态信息具有使用服务请求对象的权限，将登录态信息下发至下游服务模块。通过将用户标识和渠道标识引入到登录态信息内，然后对登录态信息进行服务请求对象匹配和权限认证，实现一套系统，同一个数据库，无需重复部署，即可实现对不同渠道来源用户的权限控制，不需要修改代码，维护成本小，且能实现用户操作和数据上的隔离，有利于提高系统安全，使用可靠。
附图说明
49.图1为一个实施例中权限控制方法的应用环境图；
50.图2为一个实施例中权限控制方法的流程示意图；
51.图3为另一个实施例中权限控制方法的流程示意图；
52.图4为一个实施例中权限控制装置的结构框图；
53.图5为一个实施例中计算机设备的内部结构图。
具体实施方式
54.为了使本技术的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本技术进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本技术，并不用于限定本技术。
55.本技术实施例提供的权限控制方法，可以应用于如图1所示的应用环境中。其中，用户可通过请求渠道发送服务请求，服务请求通过反向代理后到达网关，网关对接收到服务请求及相关信息进行权限判断，从而决定是拒绝请求还是通过请求，当请求通过后，下发至下游服务模块。权限系统可对相关数据进行预处理，例如配置本技术中的对应关系，使用时可以直接调用，工作效率高。
56.在一个实施例中，如图2所示，提供了一种权限控制方法，以该方法应用于图1中的网关为例进行说明，包括以下步骤：
57.步骤200，接收服务请求，获取服务请求对应的登录态信息和服务请求对象。
58.其中，登录态信息包括用户标识和渠道标识。用户标识用于表征用户的身份信息，渠道标识可以包括渠道类型标识，渠道类型标识用于表征渠道的类型，还可以包括设备标识，用于表征当某一渠道类型下具体设备的信息。可以理解为，登录态信息是形如(clientid，userid)的二元组。同一个用户，使用不同渠道的登陆(例如fic/ops/app/pc等)时，对应的服务请求对象是不同的，例如可调用的接口集合是不同的。
59.具体地，可通过网关从请求渠道处接收服务请求，并获取与服务请求对应的登录态信息和服务请求对象。服务请求的类型并不限定，例如可以为登录请求等。服务请求对象的类型也不是唯一的，例如可包括接口，还可以包括其他，只要本领域技术人员认为可以实现即可。进一步地，请求渠道的类型也不是唯一的，在本技术中，请求渠道可以包括面向运营人员的管理系统(ops)，面向各个机构的业务系统(fic)，面向c端用户的对客系统这三个层面。其中面向c端用户的对客系统从渠道来源上又可以包括app手机端、pc网页端、第三方接入端等，第三方接入端可包括平板电脑、物联网设备和便携式可穿戴设备，物联网设备可为智能音箱、智能电视、智能空调、智能车载设备等，便携式可穿戴设备可为智能手表、智能手环、头戴设备等。
60.步骤400，在配置的登录态信息与服务请求对象的对应关系中，确定是否存在登录态信息与服务请求对象的对应关系。
61.其中，服务请求对象包括接口，接口一般为api(application program interface，应用程序接口)。对应地，配置的登录态信息与服务请求对象的对应关系可以包括登录态信息与接口的对应关系。
62.具体地，在接收到登录态信息和服务请求对象后，从配置的登录态信息与服务请求对象的对应关系中查找，确定是否存在登录态信息与服务请求对象的对应关系。配置的登录态信息与服务请求对象的对应关系已经预处理好，配置的登录态信息与服务请求对象的对应关系用于表征可以对对应关系中的登录态信息对应的服务请求对象开放权限。在本实施例中，配置的登录态信息与服务请求对象的对应关系存储在redis(remote dictionary server，远程字典服务器)中，可以减小网关的工作压力。
63.步骤600，若存在，确定登录态信息具有使用服务请求对象的权限，将登录态信息对应的服务请求下发至下游服务模块。
64.具体地，若在配置的登录态信息与服务请求对象的对应关系中，存在接收到的登录态信息与服务请求对象的对应关系，认为接收到的登录态信息和服务请求对象通过权限认证，登录态信息具有使用服务请求对象的权限，例如当服务请求对象包括接口时，即登录态信息具有调用该接口的权限，则将登录态信息以及对应的服务请求下发至下游服务模块，允许该登录态信息对应的用户和渠道执行相关操作，实现服务请求。可以理解，在其他实施例中，若在配置的登录态信息与服务请求对象的对应关系中不存在接收到的登录态信息与接收到的服务请求对象的对应关系，则考虑该登录态信息不具有使用该服务请求对象的权限，网关可以拒绝与登录态信息对应的服务请求。
65.进一步地，权限控制方法还可以包括步骤800。
66.步骤800，若不存在，拒绝服务请求。
67.具体地，若在配置的登录态信息与服务请求对象的对应关系中，不存在接收到的登录态信息与服务请求对象的对应关系，认为接收到的登录态信息和服务请求对象不能通过权限认证，登录态信息不具有使用服务请求对象的权限。在这种情况下拒绝服务请求，可以有效防止非法接入，提高系统安全性。
68.上述权限控制方法中，首先接收服务请求，获取服务请求对应的登录态信息和服务请求对象，登录态信息包括用户标识和渠道标识，然后在配置的登录态信息与服务请求对象的对应关系中，确定是否存在登录态信息与服务请求对象的对应关系，服务请求对象包括接口，若存在，确定登录态信息具有使用服务请求对象的权限，将登录态信息下发至下游服务模块。通过将用户标识和渠道标识引入到登录态信息内，然后对登录态信息进行服务请求对象匹配和权限认证，实现一套系统，同一个数据库，无需重复部署，即可实现对不同渠道来源用户的权限控制，不需要修改代码，维护成本小，且能实现用户操作和数据上的隔离，有利于提高系统安全，使用可靠。
69.在一个实施例中，服务请求对象还包括角色和菜单，对应关系为登录态信息、角色、菜单以及接口的对应关系，对应关系中，一个登录态信息对应至少一个角色，一个角色对应至少一个菜单，一个菜单对应至少一个接口。
70.服务请求对象的类型并不是唯一的，当服务请求对象还包括角色和菜单时，对应
关系为登录态信息、角色、菜单以及接口的对应关系。具体地，在对应关系中，一个登录态信息对应至少一个角色，一个角色对应至少一个菜单，一个菜单对应至少一个接口。在本实施例中，一个登录态信息对应两个以上角色，一个角色对应两个以上菜单，一个菜单对应两个以上接口，即一个登录态信息拥有若干角色，每个角色拥有若干菜单，每个菜单包含多个接口权限，相互之间为多对多的关系：
[0071][0072]
其中，登录态信息包括用户标识和渠道标识，增强了系统的可扩展性，可以适配于多层次的渠道用户。菜单就是系统菜单栏，将系统可以执行的命令以阶层的方式显示出来的一个界面。用户(具体指的是登录态信息)可以拥有不同角色，每个角色所能操作的菜单栏的权限也不一样，每个菜单的功能实现又都是由若干个接口组成的。实现了“用户(登录态)-角色-菜单-接口”四级联动权限管理，基于角色的访问控制之上增加了菜单的概念，对于多渠道系统的权限管控更加精细。
[0073]
在一个实施例中，通过两层缓存结构存储对应关系，其中，第一层缓存结构中存储登录态信息与角色的对应关系，第二层缓存结构中存储角色与接口的对应关系。
[0074]
具体地，当对应关系为登录态信息、角色、菜单以及接口的对应关系时，可通过两层缓存结构存储对应关系，两层缓存结构包括第一层缓存结构和第二层缓存接口，其中，第一层缓存结构中存储登录态信息与角色的对应关系，第二层缓存结构中存储角色与接口的对应关系，角色与菜单的对应关系存储在第一层缓存结构中或第二层缓存结构中，采用双层缓存结构逻辑清晰，优化了查询性能。可扩展地，角色与菜单的对应关系可以存储在第一层缓存结构中或第二层缓存结构中，也可以直接存储在数据库中。以将对应关系缓存在redis中为例，可采用双层hashmap的结构，第一层hashmap结构缓存的是用户-角色的关联关系，key值是global:authuserrole:《clientid》:《userid》，其value为该登录态持有的角色id，而第二层hashmap结构缓存是角色-接口的关联关系，隐去了一些关联关系：key值是global:authroleresource:《roleid》，拼接量为roleid，可以从第一层的value中遍历，其value为该角色持有的所有接口resource。
[0075]
在一个实施例中，如图3所示，权限控制方法还包括步骤310与步骤320。
[0076]
步骤310，在获取到服务请求对应的登录态信息之后，对第一层缓存结构进行刷新。
[0077]
在获取到服务请求对应的登录态信息之后，对第一层缓存结构进行刷新，具体可以为对第一层缓存结构中存储的权限数据，例如配置的登录态信息与角色的对应关系进行刷新，以便及时获取到准确的权限数据，提高系统安全性能。
[0078]
步骤320，在获取服务请求对应的登录态信息之后，若当前时间与上一次获取到登录态信息的时间间隔大于预设时间间隔，对第二层缓存结构进行刷新。
[0079]
具体地，记录当前获取到服务请求对应的登录态信息的时刻与下一次获取到服务请求对应的登录态信息的时刻，如两个时刻的间隔时间大于预设时间间隔时，对第二层缓存结构进行刷新，或者将当前获取到服务请求对应的登录态信息的时刻作为计时起点，将
下一次获取到服务请求对应的登录态信息的时刻作为计时终点，当计时起点与计时终点之间的时间间隔大于预设时间间隔时，对第二层缓存结构进行刷新，可以避免数据存储接口的压力太大。对第二层缓存结构进行刷新，具体可以为对第二层缓存结构中存储的权限数据，例如配置的角色与接口的对应关系进行刷新，以便及时获取到准确的权限数据，提高系统安全性能。预设时间间隔的取值并不是唯一的，例如可以为30秒。可以理解，在其他实施例中，预设时间间隔也可以为其他取值，只要本领域技术人员认为可以实现即可。
[0080]
进一步地，权限控制方法还可以包括步骤330。
[0081]
步骤330，在获取服务请求对应的登录态信息之后，若当前时间与上一次获取到登录态信息的时间间隔小于或等于预设时间间隔，仅对第一层缓存结构进行刷新。
[0082]
具体地，记录当前获取到服务请求对应的登录态信息的时刻与下一次获取到服务请求对应的登录态信息的时刻，如两个时刻的间隔时间小于或等于预设时间间隔时，考虑当前服务请求比较频繁，则仅对第一层缓存结构进行刷新，不对第二层缓存结构进行刷新，可以有效减轻第二层缓存结构的工作负荷。
[0083]
在一个实施例中，配置的登录态信息与服务请求对象的对应关系的获取方式包括步骤110和步骤120。
[0084]
步骤110，调用用户服务(user)中的刷新资源表接口，获取系统内所有应用程序接口。
[0085]
具体地，通过调用用户服务中的刷新资源表接口，获取系统内所有应用程序接口，其本质是调用基础数据服务(bds)中的“获取api列表”得到的，该接口首先依赖于服务发现，调用时会对系统所有服务进行遍历，查询出的接口可以持久化到资源表中。
[0086]
步骤120，获取各应用程序接口所在的服务名和接口路径，得到预设接口标识列表。
[0087]
各应用程序接口所在的服务名和接口路径都是接口本身的信息，通过获取各应用程序接口所在的服务名和接口路径，得到预设接口标识列表，使得预设接口标识列表依赖于接口本身的信息，具有唯一性和防篡改性，对于权限的控制又增加了一层保护，安全性得到了提升。
[0088]
在一个实施例中，步骤120包括步骤122至步骤126。
[0089]
步骤122，分别计算各应用程序接口所在的服务名和接口路径组成的字符串的消息摘要。
[0090]
具体地，将应用程序所在的服务器的字符串与接口路径的字符串拼接起来，然后进行哈希运算后得到散列值，得到各应用程序接口所在的服务名和接口路径组成的字符串的消息摘要，可以提高数据传输的安全性。
[0091]
步骤124，分别对各消息摘要进行十六进制编码，获得各应用服务接口的接口标识。
[0092]
分别对各消息摘要进行十六进制编码，可以是分别对各消息摘要进行md5(message digest algorithm md5，消息摘要算法第五版)转十六进制编码，获得各应用服务接口的接口标识。md5输出长128bit，转为16进制后只占32个字符，由此可以获得占用空间有限，字符串长度定长的接口标识，有利于保持接口标识的唯一性。
[0093]
步骤126，根据各应用服务接口的接口标识得到预设接口标识列表。
[0094]
得到各应用服务接口的接口标识后，将所有的接口标识持久化到预设接口标识列表中，需要时可直接从预设接口标识列表中调用相应的数据，使用便捷。
[0095]
在一个实施例中，如图3所示，权限控制方法还包括步骤130和步骤140。
[0096]
步骤130，接收运营人员发送的配置关系设置指令。
[0097]
其中，配置关系设置指令包括登录态信息与角色的对应关系、以及角色与菜单的对应关系。具体地，网关还可以接收运营人员发送的配置关系设置指令，配置关系设置指令包括登录态信息与角色的对应关系、以及角色与菜单的对应关系，运营人员可以自行维护登录态信息与角色的对应关系，以及角色与菜单的对应关系，增强了系统的可配置性。
[0098]
步骤140，根据配置关系设置指令更新登录态信息、角色、菜单以及接口的对应关系。
[0099]
在接收到配置关系指令后，根据配置关系指令中的登录态信息与角色的对应关系、以及角色与菜单的对应关系对登录态信息、角色、菜单以及接口的对应关系进行更新。此外，还可以接收开发人员发送的预处理关系指令，预处理关系指令包括菜单与接口的对应关系，根据接收到的预处理关系指令更新登录态信息、角色、菜单以及接口的对应关系，可以满足不同渠道用户对于权限系统的需求，增强了系统的可拓展性。
[0100]
在一个实施例中，当登录态信息中的渠道标识为终端用户渠道时，与登录态信息匹配的菜单为虚拟菜单标识。终端用户渠道可以为app或者个人电脑等，由于终端用户渠道通常不涉及到菜单这个组件，因此定义了虚拟菜单标识，例如对不同的终端用户渠道定义虚拟菜单标识为1，2，3等等，便于区分。与登录态信息匹配的菜单为虚拟菜单标识，以适配整个权限体系，提高系统工作性能。
[0101]
例如，在一个实施例中，当用户需要访问网页时，不同的用户(包括个人用户或企业用户等)可通过不同的请求渠道发送服务请求，服务请求可以为登录请求，与请求渠道设备连接的网关对接收到的服务请求及相关信息进行权限判断，在权限验证通过时，对相应的请求渠道开放权限，允许当前渠道登录，并读取服务请求对象内容，例如当服务请求对象包括接口信息时，下发到下游服务模块，下游服务模块允许其接入对应接口，允许访问接口对应的网页内容等。在权限验证不通过时，拒绝服务请求，当前渠道不能顺利登录，从而提高系统安全性。
[0102]
为了更好地理解上述实施例，以下结合一个具体的实施例进行详细的解释说明。在一个实施例中，权限控制方法可以基于图1的权限系统实现。下面从“接口发现”，“登录态-接口关联关系建立”以及“请求权限校验”两个模块对整个权限系统进行介绍与分析，其中“登录态-接口关联关系建立”是整个权限系统的核心，“接口发现”则是其基础，而“请求权限校验”则是其结果。
[0103]
请求渠道包括面向运营人员的管理系统(ops)，面向各个机构的业务系统(fic)，面向c端用户的对客系统这三个层面。ops作为运营方，负责权限的总体把控，小到菜单角色的管控，业务处理机构的增删改查，其中对客端从渠道来源上又分为app手机端、pc网页端、第三方接入端，除了基础通用功能之外，从项目划分上又带有各自地方特色需求。在此框架下，为了维护数据、业务的安全，清晰的权限设计显得尤为重要。我们需要实现针对带有用户登录态的请求，检测登录态持有者是否拥有某个接口的调用权限。授权系统中最小单元是登录态，登录态是指形如(clientid，userid)的二元组。这意味着，同一个用户，使用不同
渠道的登陆(fic/ops/app/pc等)时，他们可调用的接口集合是不同的。
[0104]
权限系统预处理主要由开发人员进行维护，主要分为接口发现和登录态-接口关联关系建立两个部分。如图1所示，a、通过调用用户服务(user)中的刷新资源表接口获取系统内所有api，其本质是调用基础数据服务(bds)中的“获取api列表”得到的，该接口首先依赖于服务发现，调用时会对系统所有服务进行遍历，查询出的接口会持久化到resource表中。为了保持resourceid的唯一性，命名规则至少应当满足以下条件：
[0105]
(1)id仅根据接口本身的信息计算得到，不依赖接口以外的信息。具体获取接口所在的服务名+接口路径，然后md5转十六进制编码。
[0106]
(2)应用于计算唯一id的接口信息，能够通过网络请求完全恢复出来。
[0107]
(3)id的占用空间必须是有限的，最好是定长的。
[0108]
针对以上几点，可以取resource表中关键要素拼接成特征字符串，进行哈希运算后获得散列值，即md5转16进制编码，得到的值就是为resourceid。md5输出长128bit，转为16进制后只占32个字符，有利于保持resourceid的唯一性。
[0109]
登录态-接口关联关系建立最直接的方法就是维护一张“用户-接口”的表，然而多数用户大多拥有多个角色，这样会有大量重复数据，不利于角色的增删操作。所以建立一对多的关系，可以提高可维护性，减少重复性工作。因此目前的关联关系是基于“用户-角色-菜单-接口”的四级联动管控，即一个用户拥有若干角色，每个角色拥有若干菜单，每个菜单包含多个接口权限，相互之间一般是多对多的关系：
[0110][0111]
用户具体指的是登录态，即(clientid，userid)的二元组，系统的可扩展性好，可以适配于多层次的渠道用户。其中，通过ops页面运营人员可以自行维护用户-角色和角色-菜单的关系，开发人员则需要进行预处理维护好菜单-接口的关系(如图1中虚线框步骤b所示)。由于c端渠道不涉及菜单这个组件，我们定义了虚拟菜单id以适配整个权限体系。
[0112]
请求权限校验是指请求到达网关时需要根据此前建立的登录态-接口关联关系对请求的合法性进行校验。请求权限校验就是在接收到登录请求的同时，进行接口权限校验。合法性校验就是校验该登录用户是否具有某个接口的调用权限，即从redis中获取用户所拥有的角色和接口列表，进行比较。具体地，
①
当渠道用户发送服务请求时，经过反向代理后到达网关，
②
网关通过登录态信息从redis中获该用户所拥有的角色和接口列表，进行权限判断从而决定是拒绝该请求还是通过该请求并且下发至下游服务模块。
[0113]
由于网关请求压力较大，一般不直接进行数据库操作，所以权限数据存储在redis中，采用了双层hashmap的结构：第一层缓存是用户-角色的关联关系：key值是global:authuserrole:《clientid》:《userid》，其value为该登录态持有的角色id；而第二层缓存是角色-接口的关联关系，隐去了一些关联关系：key值是global:authroleresource:《roleid》，拼接量为roleid，可以从第一层的value中遍历，其value为该角色持有的所有接口resource。权限数据在用户登录后会进行刷新，为了避免频繁登录导致redis压力太大，仅当登录间隔超过30秒时才刷新权限缓存的第二层，缓存第一层则是每次登陆都刷新。
[0114]
该方案实现了“用户(登录态)-角色-菜单-接口”四级联动权限管理，基于角色的访问控制之上增加了菜单的概念，对于多渠道系统的权限管控更加精细。同时引入了登录态的概念，实现一套系统，同一个数据库，无需重复部署，即可实现对不同渠道来源用户的权限控制，实现用户操作和数据上的隔离。为了增强系统的可配置性和可拓展性，在校验用户权限时，网关的配置项中增加了状态开关和渠道列表，以满足不同渠道用户对于权限系统的需求。不论是开发人员对权限系统的预处理还是运营人员对用户-角色和角色-菜单关系的维护均实现了界面化，不用修改代码即可进行修改，方便快捷。resourceid的计算依赖于接口本身的信息，具有唯一性和防篡改性，对于权限的控制又增加了一层保护，安全性得到了提升。采用双层结构的redis缓存，逻辑清晰，优化了查询性能。
[0115]
应该理解的是，虽然如上的各实施例所涉及的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，如上的各实施例所涉及的流程图中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。
[0116]
基于同样的发明构思，本技术实施例还提供了一种用于实现上述所涉及的权限控制方法的权限控制装置。该装置所提供的解决问题的实现方案与上述方法中所记载的实现方案相似，故下面所提供的一个或多个权限控制装置实施例中的具体限定可以参见上文中对于权限控制方法的限定，在此不再赘述。
[0117]
在一个实施例中，如图4所示，提供了一种权限控制装置，包括：请求接收模块、对应关系确定模块和权限处理模块，其中：
[0118]
请求接收模块，用于接收服务请求，获取服务请求对应的登录态信息和服务请求对象；登录态信息包括用户标识和渠道标识；
[0119]
对应关系确定模块，用于在配置的登录态信息与服务请求对象的对应关系中，确定是否存在登录态信息与服务请求对象的对应关系，服务请求对象包括接口；
[0120]
权限处理模块，用于在对应关系确定模块确定存在对应关系时，确定登录态信息具有使用服务请求对象的权限，将登录态信息下发至下游服务模块。
[0121]
在一个实施例中，权限控制装置还包括更新模块，更新模块用于在获取到服务请求对应的登录态信息之后，对第一层缓存结构进行刷新；在获取服务请求对应的登录态信息之后，若当前时间与上一次获取到登录态信息的时间间隔大于预设时间间隔，对第二层缓存结构进行刷新。
[0122]
在一个实施例中，权限控制装置还包括配置模块，配置模块用于接收运营人员发送的配置关系设置指令，配置关系设置指令包括登录态信息与角色的对应关系、以及角色与菜单的对应关系；根据配置关系设置指令更新登录态信息、角色、菜单以及接口的对应关系。
[0123]
上述权限控制装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。
[0124]
在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图5所示。该计算机设备包括通过系统总线连接的处理器、存储器和网络接口。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质和内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储配置的登录态信息与服务请求对象的对应关系数据等。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种权限控制方法。
[0125]
本领域技术人员可以理解，图5中示出的结构，仅仅是与本技术方案相关的部分结构的框图，并不构成对本技术方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
[0126]
在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现上述各方法实施例中的步骤。
[0127]
在一个实施例中，提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述各方法实施例中的步骤。
[0128]
上述权限控制方法、装置、计算机设备、存储介质和计算机程序产品，首先接收服务请求，获取服务请求对应的登录态信息和服务请求对象，登录态信息包括用户标识和渠道标识，然后在配置的登录态信息与服务请求对象的对应关系中，确定是否存在登录态信息与服务请求对象的对应关系，服务请求对象包括接口，若存在，确定登录态信息具有使用服务请求对象的权限，将登录态信息下发至下游服务模块。通过将用户标识和渠道标识引入到登录态信息内，然后对登录态信息进行服务请求对象匹配和权限认证，实现一套系统，同一个数据库，无需重复部署，即可实现对不同渠道来源用户的权限控制，不需要修改代码，维护成本小，且能实现用户操作和数据上的隔离，有利于提高系统安全，使用可靠。
[0129]
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本技术所提供的各实施例中所使用的对存储器、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(read-only memory，rom)、磁带、软盘、闪存、光存储器、高密度嵌入式非易失性存储器、阻变存储器(reram)、磁变存储器(magnetoresistive random access memory，mram)、铁电存储器(ferroelectric random access memory，fram)、相变存储器(phase change memory，pcm)、石墨烯存储器等。易失性存储器可包括随机存取存储器(random access memory，ram)或外部高速缓冲存储器等。作为说明而非局限，ram可以是多种形式，比如静态随机存取存储器(static random access memory，sram)或动态随机存取存储器(dynamic random access memory，dram)等。本技术所提供的各实施例中所涉及的数据库可包括关系型数据库和非关系型数据库中至少一种。非关系型数据库可包括基于区块链的分布式数据库等，不限于此。本技术所提供的各实施例中所涉及的处理器可为通用处理器、中央处理器、图形处理器、数字信号处理器、可编程逻辑器、基于量子计算的数据处理逻辑器等，不限于此。
[0130]
以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例
中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
[0131]
以上所述实施例仅表达了本技术的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本技术专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本技术构思的前提下，还可以做出若干变形和改进，这些都属于本技术的保护范围。因此，本技术的保护范围应以所附权利要求为准。