数据权限确定方法及装置、电子设备及存储介质与流程

文档序号:32061134发布日期:2022-11-04 23:12阅读:80来源:国知局
数据权限确定方法及装置、电子设备及存储介质与流程

1.本公开涉及软件测试技术领域,特别涉及一种测试方法及装置、电子设备及计算机可读存储介质。


背景技术:

2.随着企业信息水平的不断进步,往往一家公司不止一个业务系统,不同的业务系统中每个用户都有着各自的权限,每个业务系统都需要对不同用户的权限进行配置,以只向目标用户提供部分符合权限的数据展示。
3.然而,进行权限控制一般都在本业务系统中开发维护,由于各应用系统独立分散,架构标准不一,针对多个业务系统要开发多套权限控制系统或模块,会导致开发成本太大,以及不利于业务的升级迭代,也不利于后期对用户权限的管理维护的问题。


技术实现要素:

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.角色标识。
50.第五方面,本技术还提供一种电子设备,包括:
51.用于存储处理器可执行指令的存储器;
52.处理器;其中,处理器被配置为:用于执行可执行指令时,实现如第一方面或第二方面及其可能的实施方式的方法。
53.第六方面,本技术提供了一种计算机可读存储介质,计算机可读存储介质存储有可执行程序,其中,可执行程序被处理器执行时实现如第一方面或第二方面及其可能的实施方式的方法。
54.本技术实施例提供的技术方案与现有技术相比存在的有益效果是:
55.在本技术中,接收业务系统的权限访问请求;根据权限访问请求携带的查询依据信息,查询目标用户至少一种权限配置的权限信息;将权限信息返回给业务系统。如此,将各业务系统的权限统一管理,各业务系统可以不需要独立开发多套权限控制系统或模块,即可方便高效的实现各自业务的权限控制,也有利于统一管理维护。
56.应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本公开。
附图说明
57.此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本发明的实施例,并与说明书一起用于解释本发明的原理。
58.图1是本技术实施例中的一种数据权限确定方法的实施例流程示意图。
59.图2是本技术实施例中的另一种数据权限确定方法的实施例流程示意图。
60.图3是本技术实施例提供的一种数据权限确定方法的流程示意图。
61.图4a是权限查询需求为目标用户的角色对应的权限时数据权限查询结果示意图。
62.图4b是权限查询需求为目标用户的角色和公开给目标用户的第二类角色的权限时数据权限查询结果示意图。
63.图4c是目标用户拥有全部权限时的权限查询结果示意图。
64.图5是本技术实施例中各业务系统数据权限隔离接口逻辑示意图。
65.图6是本技术实施例中业务系统的数据权限隔离实现示意图。
66.图7是本技术实施例中在数据权限管理平台中为角色信息下增加权限信息的效果图。
67.图8是本技术实施例中在数据权利管理平台中调整角色权限范围的效果图。
68.图9是本技术实施例中在数据权利管理平台中新增权限信息的效果图。
69.图10是本技术实施例中在数据权利管理平台中新增角色信息的效果图。
70.图11是本技术实施例中在数据权利管理平台中新增用户信息的效果图。
71.图12是本技术实施例中的一种数据权限确定装置的结构示意图。
72.图13是本技术实施例中的一种测试装置的结构示意图。
73.图14是本技术实施例中的一种电子设备结构示意图。
具体实施方式
74.以下描述中,参考形成本技术一部分并以说明之方式示出本技术实施例的具体方面或可使用本技术实施例的具体方面的附图。应理解,本技术实施例可在其它方面中使用,并可包括附图中未描绘的结构或逻辑变化。因此,以下详细描述不应以限制性的意义来理解,且本技术的范围由所附权利要求书界定。例如,应理解,结合所描述方法的揭示内容可以同样适用于用于执行所述方法的对应设备或装置,且反之亦然。例如,如果描述一个或多个具体方法步骤,则对应的设备可以包含如功能单元等一个或多个单元,来执行所描述的一个或多个方法步骤(例如,一个单元执行一个或多个步骤,或多个单元,其中每个都执行多个步骤中的一个或多个),即使附图中未明确描述或说明这种一个或多个单元。另一方面,例如,如果基于如功能单元等一个或多个单元描述具体装置,则对应的方法可以包含一个步骤来执行一个或多个单元的功能性(例如,一个步骤执行一个或多个单元的功能性,或多个步骤,其中每个执行多个单元中一个或多个单元的功能性),即使附图中未明确描述或说明这种一个或多个步骤。进一步,应理解的是,除非另外明确提出,本文中所描述的各示例性实施例和/或方面的特征可以相互组合。
75.下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
76.图1为本技术实施例中的一种数据权限确定方法的实施例流程示意图,参见图1所示,该方法可以包括:
77.s101,接收业务系统的权限访问请求;
78.s102,根据权限访问请求携带的查询依据信息,查询目标用户至少一种权限配置的权限信息;
79.s103,将权限信息返回给业务系统。
80.其中,业务系统可以是多个,每个业务系统通过其数据库实现本系统内的数据存储。各个业务系统支持的数据库类型可以是相同的,也可以是不同的。每个业务系统可以支持一种或多种数据库类型。本技术实施例中的数据权限确定方法可以应用一数据权限管理平台,通过建立数据权限管理平台对各个业务系统的数据权限进行统一管理。
81.可以理解的,数据权限管理,可以是根据系统设置的安全规则或者安全策略,用户可以访问而且只能访问自己被授权的资源。解决的是用户能对哪些数据进行操作的问题,例如,用户只能查看本人的所有业务数据信息而不能查看其他人的业务数据信息。
82.在一个实施例中,上述权限访问请求中可以包含目标用户的用户信息。基于此,上述步骤s102可以包括:
83.根据用户信息,查询目标用户的角色信息;
84.根据目标用户的角色信息,确定目标用户的权限信息。
85.角色信息可以是根据各业务系统组织机构内的职务和岗位进行定义的,不同职务承担不同的职能,所需权限有很大的差异,而同样职务和岗位的用户,所需要的权限大致相同,所以以职务和岗位来划分角色。例如,财务岗位的角色需要对账、发票管理等财务相关权限。
86.用户的权限信息通常可以取决于该用户对应的角色信息。本技术实施例中,上述数据权限管理平台通过存储权限信息、角色信息、用户信息以及三者之间的关联关系,实现对各业务系统的数据权限的统一管理。
87.在一个实施例中,上述权限信息、角色信息、用户信息以及三者之间的关联关系可以以数据库表的形式存储于上述数据权限管理平台的数据库中。其中,各数据库表至少可以包括:
88.权限表,主要实现业务系统权限点存储;其中,一个权限点表示一种数据权限。数据权限即允许访问的数据范围。许多操作的实质都是对数据的读或写,因此需要限定所允许访问的数据范围,在执行操作时根据数据权限进行限制。一个权限点可以对应一个权限编码。
89.角色表,用于保存所有定义的角色的基本信息,实现系统角色信息存储。每个角色对应一个角色编码,角色编码全局唯一。
90.角色权限关联表,存储角色下授权的权限,角色编码可以关联多个权限编码。
91.角色数据权限表,数据权限是挂载在角色下的,主要存储角色下配置数据权限的范围,包括当前用户本人、本人及下属以及全部数据权限。
92.用户表,用于保存用户的基本信息,目标用户是对对应业务系统的当前使用者。用户信息可以包括用户标识(id)、用户名等。
93.用户角色关联表,存储用户下配置的角色信息,用户下可以关联多个角色编码。
94.各业务系统在确定目标用户的权限信息时,可以通过上述数据权限管理平台提供的接口查询当前目标用户对应的角色信息,基于角色信息查询该角色信息具有的权限信息。
95.可以理解的,在一个业务系统中,角色信息可以由该业务系统组织机构内的职务和岗位进行定义。各个职务和岗位通常具有上下级之分,用户对应的角色具有的权限信息通常包含该角色本人以及从属于该角色的其他角色的权限信息的并集。因此,在一个实施例中,上述数据权限确定方法还可以包括:
96.若目标用户的角色为第一类角色,确定从属于目标用户的第二类角色;
97.根据权限访问请求指示的权限查询需求,查询第一类角色的第一权限信息和/或第二类角色的第二权限信息。
98.由于第二类角色从属于目标用户对应的第一类角色,因此,目标用户具有的数据权限即包含目标用户本人对应的权限同时包含从属于目标用户的第二类角色对应的其他用户所有的权限集合。此处的权限查询需求可以是查询目标用户的角色对应的权限,也可
以是目标用户的角色和公开给所述用户的第二类角色的权限。
99.在一个实施例中,当权限查询需求是查询目标用户的角色对应的权限时,查询目标用户的权限信息只需要根据目标用户的用户信息查询对应的角色信息,基于角色信息查询角色信息对应的权限信息。
100.在另一个实施例中,当权限查询需求是目标用户的角色和公开给所述用户的第二类角色的权限时,查询目标用户的权限信息需要查询目标用户对应的角色以及从属于目标用户的角色对应的所有权限信息的并集。
101.在另一个实施例中,上述方法还可以包括,在返回权限信息时增加是否具有全部数据权限的标识。
102.示例性的,以标识字段isalldata表示当前目标用户是否具有全部数据权限。当查询到目标用户具有全部数据权限时,在向对应业务系统返回权限信息时增加具有全部权限信息的标识,例如,以true表示。反之,以false表示目标用户不具有全部数据权限。
103.可以理解的,业务系统基于上述数据权限管理平安提供的接口实现数据权限的查询确定,业务系统可以是多个,基于此,上述权限访问请求至少还包括:业务系统的业务系统标识。
104.其中,业务系统标识用于指示待查询权限信息的目标业务系统。
105.示例性的,业务系统标识可以是业务系统的统一资源定位系统(uniform resource lo cator;url),或者还可以是其他预定义的业务系统标识符号。
106.业务系统通过权限访问请求向上述数据权限管理平台传入该业务系统的业务系统标识以及当前目标用户的用户信息标识,基于该业务系统标识可以通过查询上述数据权限管理平台中的权限表找到对应的权限编码,基于该权限编码可以查询出具有该权限编码对应的权限的所有角色。当需要更精确地查询时,本技术实施例中,可以通过在上述权限访问请求中携带权限标识和/或角色标识来实现更精确的查询。
107.在一个可选的实施例中,当权限访问请求包含权限标识时,查询权限标识对应的权限信息。
108.在另一个可选的实施例中,当权限访问请求包含角色标识时,查询角色信息对应的权限标识,并查询角色信息对应的权限标识的权限信息。
109.在另一个可选的实施例中,当访问请求包含权限信息和/或权限标识时,查询权限信息和/或权限标识对应的角色信息。
110.在一个实施例中,上述数据权限管理平台在基于接收到的业务系统的权限访问请求进行权限查询时,可以通过缓存数据库技术(redis)来提高查询的效率。
111.其中,redis是一个开源的内存中的数据结构存储系统,它可以用作数据库、缓存和消息中间件。支持多种类型的数据结构。在进行信息查询时,可以直接读取缓存中的存储的信息。而不用每次从数据库中重新读取查询,提高查询的效率。
112.在一个实施例中,若通过redis进行权限信息的查询是直接读取缓存中存储的信息,因此,当上述数据权限管理平台存储的信息发生变化时,缓存的信息可能会存在与数据库汇总的信息不一致的情况。例如用户信息的增删改、角色信息的增删和授权、权限信息的增删改等情况下,本技术实施例会进行缓存的清理,以保证数据信息的一致。
113.图2为本技术实施例中的另一种数据权限确定方法的实施例流程示意图,参见图2
所示,上述数据权限确定方法可以包括:
114.s201,发送权限访问请求至用户权限确定系统;所述权限访问请求中携带查询依据信息,用于查询目标用户至少一种权限配置的权限信息;
115.s202,接收所述用户权限确定系统返回的权限信息。
116.在一些可能的实施方式中,权限访问请求至少还包含:业务系统的业务系统标识;其中,业务系统标识,用于指示待查询权限信息的目标业务系统。
117.在一些可能的实施方式中,权限访问请求还包含以下至少之一:
118.用户信息;
119.权限标识;
120.角色标识。
121.本技术实施例中,接收业务系统的权限访问请求;根据权限访问请求携带的查询依据信息,查询目标用户至少一种权限配置的权限信息;将权限信息返回给业务系统。如此,将各业务系统的权限统一管理,各业务系统可以不需要独立开发多套权限控制系统或模块,即可方便高效的实现各自业务的权限控制,也有利于统一管理维护。
122.以下以具体的实施例来对上述数据权限确定方法进行说明。
123.图3为本技术实施例提供的一种数据权限确定方法的流程示意图,参见图3所示,上述数据权限管理平台可以是通用用户权限系统(user permissions management system,up ms)。通过redis进行查询操作,在发生用户信息的增删改、角色信息的增删和授权、权限信息的增删改等情况下,进行缓存的清理,以保证数据信息的一致。业务系统标识用url标识,用户信息标识以shareid表示。
124.业务系统根据数据权限管理平台提供的接口向数据权限管理平台发送权限访问请求,其中访问请求携带的查询依据信息至少包括url和shareid。查询依据信息可以不包含权限编码和/或角色编码。
125.数据权利管理平台根据接收到的权限访问请求携带的查询依据信息,通过redis查询当前业务系统的目标用户对应的数据权限。数据权限管理平台基于查询依据信息中的ur l、权限编码、角色编码查询对对应的所有角色,其中,url不能为空,权限编码和/或角色编码可以为空,根据三者的交集查询对应的角色。
126.根据目标用户的用户信息标识和上述获取到的角色确定目标用户对应角色拥有的数据权限。例如,目标用户的只包含本人的数据权限,或者目标用户包含本人及从属于目标用户的角色的所有数据权限,或者目标用户包含所有数据权限。
127.根据上述获取到的目标用户的数据权限通过用户表获取目标用户的数据权限对应的用户列表。例如,用户表的数据源可以是来自公司内部即时通讯管理系统例如钉钉。通过钉钉获取目标用户本人基本信息、或者目标用户和从属于目标用户的下属的用户列表、或者获取数据权限管理系统的所有用户列表。
128.图4为本技术实施例中查询目标用户数据权限的结果示意图。其中,图4a为权限查询需求为目标用户的角色对应的权限时查询目标用户数据权限的结果示意图。图4b为权限查询需求为目标用户的角色和公开给目标用户的第二类角色的权限的结果示意图。图4c为目标用户拥有全部权限信息时的权限查询结果示意图。
129.以下以一具体实施例来说明本技术实施例中各业务系统数据权限隔离接口的逻
辑。
130.参见图5所示,图5为本技术实施例中各业务系统数据权限隔离接口逻辑示意图。此处业务系统以基于【商户bd】【商户am】两个角色的数据权限隔离来说明业务接入实现。例如,业务系统希望商户bd以及商户am只能看到各自商户的数据以保证数据隔离。其中,业务系统请求数据权限管理平台查询用户数据权限的所需要的查询依据如下表1所示:
[0131][0132]
表1
[0133]
返回的数据如下述内容所示:
[0134]
bduser:有数据权限的【商户bd】列表
[0135]
amuser:有数据权限的【商户am】列表
[0136]
allbduser:所有【商户bd】列表
[0137]
allamuser:所有【商户am】列表
[0138]
userrole可以表示为:
[0139]
1:有【商户bd】角色
[0140]
2:有【商户am】角色
[0141]
12:有【商户bd】和【商户am】角色
[0142]
0:无【商户bd】和【商户am】角色
[0143]
此时,业务系统调用数据全称关联平台的数据权限接口获取当前系统登陆的目标用户对应的【商户bd】【商户am】的数据权限,有以下几种场景:
[0144]
1、目标用户下只有【商户bd】角色,无【商户am】角色,则根据【商户bd】角色的数据权限范围返回商务拓展列表即bduser字段,返回所有商务支持列表,即allamuser字段;
[0145]
2、目标用户下只有【商户am】角色,无【商户bd】角色,则根据【商户am】角色的数据权限范围返回商务支持列表即amuser字段,返回所有商务拓展列表,即allbduser字段;
[0146]
3、目标用户下即有【商户bd】角色,也有【商户am】角色,则根所有【商户bd】列表即allbduser字段,所有【商户am】列表即allamuser字段;
[0147]
4、目标用户下即没有【商户bd】角色,也无【商户am】角色,则【商户bd】角色列表返回空即bduser字段,【商户am】角色列表返回空即amuser字段。
[0148]
一个目标用户通常只会从属于一个业务系统,所在业务系统也只会挂载【商户bd】或者【商户am】其中一个角色。参见图6所示,图6为本技术实施例中业务系统的数据权限隔
离实现示意图。此时,业务系统的数据隔离实现可以包括:
[0149]
1、当用户只有【商户bd】角色,设计上【商户am】允许看到所有的商户支持列表,但最终的业务数据隔离最小集展示会以【商户bd】的数据权限范围为准;
[0150]
2、当用户只有【商户am】角色,设计上【商户bd】允许看到所有的商户支持列表,但最终的业务数据隔离最小集展示会以【商户am】的数据权限范围为准;
[0151]
3、特殊情况既有【商户bd】又有【商户am】角色,则最终的业务数据隔离会以【商户bd】的数据权限范围和【商户am】的数据范围中的最小集合展示。
[0152]
本技术实施例中,数据权利管理平台可以包括权限信息、角色信息、用户信息三级,权限挂载在角色下,用户下添加角色。图7为本技术实施例中在数据权限管理平台中为角色信息下增加权限信息的效果图;图8为本技术实施例中在数据权利管理平台中调整角色权限范围的效果图。
[0153]
本技术实施例中,权限信息、角色信息、用户信息的可以通过可视化的数据权限管理平台集中配置集中管理,避免了权限分散在各个业务系统带来的管理和配置成本。
[0154]
示例性的,可视化的数据权限管理平台配置可以参见图9至图11所示。其中图9为本技术实施例中在数据权利管理平台中新增权限信息的效果图;图10为本技术实施例中在数据权利管理平台中新增角色信息的效果图;图11为本技术实施例中在数据权利管理平台中新增用户信息的效果图。
[0155]
本技术实施例中,接收业务系统的权限访问请求;根据权限访问请求携带的查询依据信息,查询目标用户至少一种权限配置的权限信息;将权限信息返回给业务系统。如此,将各业务系统的权限统一管理,各业务系统可以不需要独立开发多套权限控制系统或模块,即可方便高效的实现各自业务的权限控制,也有利于统一管理维护。
[0156]
基于相同的发明构思,本技术实施例提供一种数据权限确定装置,该种数据权限确定装置包括用于实施上述数据权限确定方法的若干个功能单元。
[0157]
图12为本技术实施例中的一种数据权限确定装置的结构示意图,参见图12所示,该数据权限确定装置1200可以包括:
[0158]
接收模块1201,用于接收业务系统的权限访问请求;
[0159]
查询模块1202,用于根据权限访问请求携带的查询依据信息,查询目标用户至少一种权限配置的权限信息;
[0160]
返回模块1203,用于将权限信息返回给业务系统。
[0161]
在一些可能的实施方式中,查询模块1202,具体用于根据权限访问请求包含的目标用户的用户信息,查询目标用户的角色信息;根据目标用户的角色信息,确定目标用户的权限信息。
[0162]
在一些可能的实施方式中,查询模块1202,具体用于若目标用户的角色为第一类角色,确定从属于目标用户的第二类角色;根据权限访问请求指示的权限查询需求,查询第一类角色的第一权限信息和/或第二类角色的第二权限信息。
[0163]
在一些可能的实施方式中,查询模块1202,具体用于当权限查询需求为查询目标用户的角色对应的权限时,查询第一权限信息;当权限查询需求为目标用户的角色和公开给用户的第二类角色的权限时,查询第一权限信息和第二权限信息。
[0164]
在一些可能的实施方式中,权限访问请求至少包括:业务系统的业务系统标识;其
中,业务系统标识,用于指示待查询权限信息的目标业务系统。
[0165]
在一些可能的实施方式中,查询模块1202,具体用于当权限访问请求包含权限标识时,查询权限标识对应的权限信息;当权限访问请求包含角色标识时,查询角色信息对应的权限标识,并查询角色信息对应的权限标识的权限信息。
[0166]
在一些可能的实施方式中,查询模块1202,还用于当访问请求包含权限信息和/或权限标识时,查询权限信息和/或权限标识对应的角色信息。
[0167]
基于相同的发明构思,本技术实施例提供一种数据权限确定装置,该种数据权限确定装置包括用于实施上述数据权限确定方法的若干个功能单元。
[0168]
图13为本技术实施例中的一种测试装置的结构示意图,参见图13所示,该测试装置1300可以包括:
[0169]
发送模块1301,用于发送权限访问请求至用户权限确定系统;权限访问请求中携带查询依据信息,用于查询目标用户至少一种权限配置的权限信息;
[0170]
接收模块1302,用于接收用户权限确定系统返回的权限信息。
[0171]
在一些可能的实施方式中,权限访问请求至少包含:业务系统的业务系统标识;其中,业务系统标识,用于指示待查询权限信息的目标业务系统。
[0172]
在一些可能的实施方式中,权限访问请求权限访问请求还包含以下至少之一:
[0173]
用户信息;
[0174]
权限标识;
[0175]
角色标识。
[0176]
基于相同的发明构思,本技术实施例提供一种电子设备,该电子设备可以与上述一个或者多个实施例中所述的数据权限确定方法一致。图14为本技术实施例中的一种电子设备结构示意图,参见图14所示,电子设备1400,可以采用通用的计算机硬件,包括处理器601、存储器602。
[0177]
在一些可能的实施方式中,至少一个处理器可以构成具有对一个或多个输入执行逻辑运算的电路的任何物理设备。例如,至少一个处理器可以包括一个或多个集成电路(ic),包括专用集成电路(asic)、微芯片、微控制器、微处理器、中央处理单元(cpu)的全部或部分、图形处理单元(gpu)、数字信号处理器(dsp)、现场可编程门阵列(fpga)或者适于执行指令或执行逻辑运算的其它电路。由至少一个处理器执行的指令可以例如被预加载到与控制器集成的或嵌入在控制器中的存储器中,或者可以存储在分离的存储器中。存储器可以包括随机存取存储器(ram)、只读存储器(rom)、硬盘、光盘、磁介质、闪存,其它永久、固定或易失性存储器,或者能够存储指令的任何其它机制。在一些实施例中,至少一个处理器可以包括多于一个处理器。每个处理器可以具有相似的结构,或者处理器可以具有彼此电连接或断开的不同构造。例如,处理器可以是分离的电路或集成在单个电路中。当使用多于一个处理器时,处理器可以被配置为独立地或协作地操作。处理器可以以电、磁、光学、声学、机械或通过允许它们交互的其它手段来耦合。
[0178]
基于相同的发明构思,本技术提供一种计算机存储介质,计算机存储介质存储有计算机可执行指令,计算机可执行指令被处理器执行后,能够实现如上述一个或者多个实施例所述的测试方法。
[0179]
本领域技术人员可以理解,上述实施例中各步骤的序号的大小并不意味着执行顺
序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本发明实施例的实施过程构成任何限定。
[0180]
以上所述,仅为本技术示例性的具体实施方式,但本技术的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本技术揭露的技术范围内,可轻易想到的变化或替换,都应涵盖在本技术的保护范围之内。因此,本技术的保护范围应该以权利要求的保护范围为准。
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1