CN114244595A - 权限信息的获取方法、装置、计算机设备及存储介质 - Google Patents

权限信息的获取方法、装置、计算机设备及存储介质 Download PDF

Info

Publication number
CN114244595A
CN114244595A CN202111506120.5A CN202111506120A CN114244595A CN 114244595 A CN114244595 A CN 114244595A CN 202111506120 A CN202111506120 A CN 202111506120A CN 114244595 A CN114244595 A CN 114244595A
Authority
CN
China
Prior art keywords
sub
authority
topological relation
query
relation graph
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202111506120.5A
Other languages
English (en)
Other versions
CN114244595B (zh
Inventor
马晨明
董勇
单荣杨
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Dajia Internet Information Technology Co Ltd
Original Assignee
Beijing Dajia Internet Information Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Dajia Internet Information Technology Co Ltd filed Critical Beijing Dajia Internet Information Technology Co Ltd
Priority to CN202111506120.5A priority Critical patent/CN114244595B/zh
Publication of CN114244595A publication Critical patent/CN114244595A/zh
Application granted granted Critical
Publication of CN114244595B publication Critical patent/CN114244595B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/105—Multiple levels of security

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本公开关于一种权限信息的获取方法、装置、计算机设备及存储介质，属于网络技术领域。该方法包括：获取与目标对象的权限关联的至少一条数据记录；基于该至少一条数据记录，构建拓扑关系图；基于与该权限关联的业务规则信息和该拓扑关系图，获取该权限的管控数据。本公开通过将与权限关联的数据记录转储成对应的拓扑关系图，使得在生成该权限的管控数据时，将业务规则信息解析成查询操作之后，无需对数据记录执行复杂级联查询操作，而是能够直接对拓扑关系图即图数据执行相关的查询操作，从而大大提升了对管控数据的计算效率，打破了RBAC模型的局限性，能够适用于职务种类繁多、业务规则复杂的应用场景。

Description

权限信息的获取方法、装置、计算机设备及存储介质
技术领域
本公开涉及网络技术领域，特别涉及一种权限信息的获取方法、装置、计算机设备及存储介质。
背景技术
随着互联网技术的发展，在一些通讯类应用中，通常使用基于角色的访问控制(Role-Based Access Control，RBAC)模型来对各个用户的账号进行权限分配。比如，在企业通讯应用中，通常会对每个企业创建一系列的角色(如职务)，对不同的角色配置不同的访问控制权限，使得每个用户的账号在建立与角色的对应关系之后，获取为该角色配置的访问控制权限。上述RBAC模型仅支持少量(通常是10～20个)角色的创建，并且在创建角色时需要人工辅助，无法适用于一些职务种类繁多、业务规则复杂的场景。
发明内容
本公开提供一种权限信息的获取方法、装置、计算机设备及存储介质，以至少提供一种适用于职务种类繁多、业务规则复杂场景的权限管控方案。本公开的技术方案如下：
根据本公开实施例的一方面，提供一种权限信息的获取方法，包括：
获取与目标对象的权限关联的至少一条数据记录；
基于所述至少一条数据记录，构建拓扑关系图，所述拓扑关系图用于表征各条数据记录中属性名与属性值的关联关系；
基于与所述权限关联的业务规则信息和所述拓扑关系图，获取所述权限的管控数据，所述管控数据用于提供对所述权限所关联的资源的访问控制策略。
在一种可能实施方式中，所述至少一条数据记录中的每条数据记录对应于目标对象内的一个子对象；
所述拓扑关系图中包括多个节点，具有拓扑关系的不同节点之间通过有向边连接，其中，每个节点对应于一个子对象的一个属性值，每条有向边对应于所指向节点对应属性值的属性名。
在一种可能实施方式中，所述基于所述至少一条数据记录，构建拓扑关系图包括：
基于每条数据记录中的各个属性值，构建所述拓扑关系图中的各个节点；
基于每条数据记录中的各个属性名，构建所述拓扑关系图中连接不同节点的各条有向边。
在一种可能实施方式中，其特征在于，所述基于与所述权限关联的业务规则信息和所述拓扑关系图，获取所述权限的管控数据包括：
解析所述业务规则信息，得到对所述拓扑关系图的至少一个查询指令；
基于所述拓扑关系图，执行所述至少一个查询指令，得到至少一个查询结果；
基于所述至少一个查询结果，生成所述管控数据。
在一种可能实施方式中，所述拓扑关系图以哈希表形式存储，其中，所述哈希表中记录有多个集合，每个集合中存储有所述拓扑关系图中的一个节点的属性值、接入所述节点的有向边的属性名以及与所述节点相连接的其他节点的属性值；
所述基于所述拓扑关系图，执行所述至少一个查询指令，得到至少一个查询结果包括：
基于所述至少一个查询指令，对所述哈希表中的各个集合执行对应的处理操作，得到所述至少一个查询结果。
在一种可能实施方式中，所述基于所述至少一个查询指令，对所述哈希表中的各个集合执行对应的处理操作，得到所述至少一个查询结果包括：
对每个查询指令，确定所述查询指令所携带的目标属性值；
基于所述哈希表中与所述目标属性值对应的目标集合，获取所述查询指令的查询结果，所述目标集合用于表征具有所述目标属性值的各个子对象。
在一种可能实施方式中，在所述查询指令中携带多个所述目标属性值的情况下，所述基于所述哈希表中与所述目标属性值对应的目标集合，获取所述查询指令的查询结果包括：
对多个所述目标属性值对应的目标集合，执行与所述查询指令的查询语义相匹配的处理操作，得到所述查询指令的查询结果。
在一种可能实施方式中，所述管控数据以位图形式存储，所述位图中的每一个元素用于表征所述元素所在行的索引是否对所述元素所在列的索引具有所述权限；
所述基于所述至少一个查询结果，生成所述管控数据包括：
对所述目标对象中的每个子对象分配对应的索引；
基于所述至少一个查询结果，对每个子对象关联的索引所在行和其他子对象关联的索引所在列所确定的元素进行赋值，以生成所述位图。
在一种可能实施方式中，所述目标对象的子对象包括下述至少一项：成员子对象、部门子对象或者与所述目标对象关联的应用子对象；
所述生成的位图包括下述至少一项：对应于所述成员子对象的位图、对应于所述成员子对象和所述部门子对象的位图或者对应于所述成员子对象和所述应用子对象的位图。
在一种可能实施方式中，所述对所述目标对象中的每个子对象分配对应的索引包括：
对所述目标对象中的每个成员子对象、部门子对象和与所述目标对象关联的应用子对象均分配对应的索引；
所述基于所述至少一个查询结果，对每个子对象关联的索引所在行和其他子对象关联的索引所在列所确定的元素进行赋值，以生成所述位图包括：
对每个成员子对象，基于所述至少一个查询结果，对所述成员子对象关联的索引所在行和其他子对象关联的索引所在列所确定的元素进行赋值，以生成所述权限的第一位图、第二位图和第三位图；
其中，所述第一位图中的每一行和每一列均对应于一个成员子对象，所述第二位图中的每一行对应于一个成员子对象且每一列对应于一个部门子对象，所述第三位图中每一行对应于一个成员子对象且每一列对应于一个应用子对象。
在一种可能实施方式中，所述对每个子对象关联的索引所在行和其他子对象关联的索引所在列所确定的元素进行赋值包括：
在所述查询结果指示所述子对象对任一其他子对象具有所述权限时，在所述位图中，将所述元素赋值为1；
在所述查询结果指示所述子对象对任一其他子对象不具有所述权限时，在所述位图中，将所述元素赋值为0。
在一种可能实施方式中，所述方法还包括：
将所述目标对象中的各个子对象划分为多个子对象集合；
所述基于所述至少一个查询结果，生成所述管控数据包括：
对多个计算设备中的每个计算设备，从所述多个子对象集合中确定未生成管控数据的任一子对象集合；
基于所述至少一个查询结果中与所述子对象集合对应的查询结果，生成所述子对象集合对应的部分管控数据；
将所述多个计算设备生成的各个部分管控数据合并得到所述管控数据。
在一种可能实施方式中，所述方法还包括：
每间隔目标时长，获取在所述目标时长内接收到的与所述权限关联的更新指令，所述更新指令用于变更与所述目标对象的所述权限关联的数据记录或业务规则信息中至少一项；
基于所述更新指令，更新所述拓扑关系图；
基于更新后的拓扑关系图，更新所述权限的管控数据。
在一种可能实施方式中，所述方法还包括：
对初次获取的管控数据和每次更新所得的管控数据分配版本号，所述版本号与所述管控数据的生成时间戳呈单调递增；
响应于任一权限查询请求中携带版本号，在携带的版本号与所述管控数据的最大版本号相同时，返回目标状态信息，所述目标状态信息用于表征所述管控数据无变化。
根据本公开实施例的另一方面，提供一种权限信息的获取装置，包括：
第一获取单元，被配置为执行获取与目标对象的权限关联的至少一条数据记录；
构建单元，被配置为执行基于所述至少一条数据记录，构建拓扑关系图，所述拓扑关系图用于表征各条数据记录中属性名与属性值的关联关系；
第二获取单元，被配置为执行基于与所述权限关联的业务规则信息和所述拓扑关系图，获取所述权限的管控数据，所述管控数据用于提供对所述权限所关联的资源的访问控制策略。
在一种可能实施方式中，所述至少一条数据记录中的每条数据记录对应于目标对象内的一个子对象；
所述拓扑关系图中包括多个节点，具有拓扑关系的不同节点之间通过有向边连接，其中，每个节点对应于一个子对象的一个属性值，每条有向边对应于所指向节点对应属性值的属性名。
在一种可能实施方式中，所述构建单元被配置为执行：
基于每条数据记录中的各个属性值，构建所述拓扑关系图中的各个节点；
基于每条数据记录中的各个属性名，构建所述拓扑关系图中连接不同节点的各条有向边。
在一种可能实施方式中，所述第二获取单元包括：
解析子单元，被配置为执行解析所述业务规则信息，得到对所述拓扑关系图的至少一个查询指令；
执行子单元，被配置为执行基于所述拓扑关系图，执行所述至少一个查询指令，得到至少一个查询结果；
生成子单元，被配置为执行基于所述至少一个查询结果，生成所述管控数据。
在一种可能实施方式中，所述拓扑关系图以哈希表形式存储，其中，所述哈希表中记录有多个集合，每个集合中存储有所述拓扑关系图中的一个节点的属性值、接入所述节点的有向边的属性名以及与所述节点相连接的其他节点的属性值；
所述执行子单元被配置为执行：
基于所述至少一个查询指令，对所述哈希表中的各个集合执行对应的处理操作，得到所述至少一个查询结果。
在一种可能实施方式中，所述执行子单元被配置为执行：
对每个查询指令，确定所述查询指令所携带的目标属性值；
基于所述哈希表中与所述目标属性值对应的目标集合，获取所述查询指令的查询结果，所述目标集合用于表征具有所述目标属性值的各个子对象。
在一种可能实施方式中，在所述查询指令中携带多个所述目标属性值的情况下，所述执行子单元被配置为执行：
对多个所述目标属性值对应的目标集合，执行与所述查询指令的查询语义相匹配的处理操作，得到所述查询指令的查询结果。
在一种可能实施方式中，所述管控数据以位图形式存储，所述位图中的每一个元素用于表征所述元素所在行的索引是否对所述元素所在列的索引具有所述权限；
所述生成子单元包括：
分配子子单元，被配置为执行对所述目标对象中的每个子对象分配对应的索引；
生成子子单元，被配置为执行基于所述至少一个查询结果，对每个子对象关联的索引所在行和其他子对象关联的索引所在列所确定的元素进行赋值，以生成所述位图。
在一种可能实施方式中，所述目标对象的子对象包括下述至少一项：成员子对象、部门子对象或者与所述目标对象关联的应用子对象；
所述生成的位图包括下述至少一项：对应于所述成员子对象的位图、对应于所述成员子对象和所述部门子对象的位图或者对应于所述成员子对象和所述应用子对象的位图。
在一种可能实施方式中，所述分配子子单元被配置为执行：
对所述目标对象中的每个成员子对象、部门子对象和与所述目标对象关联的应用子对象均分配对应的索引；
所述生成子子单元被配置为执行：
对每个成员子对象，基于所述至少一个查询结果，对所述成员子对象关联的索引所在行和其他子对象关联的索引所在列所确定的元素进行赋值，以生成所述权限的第一位图、第二位图和第三位图；
其中，所述第一位图中的每一行和每一列均对应于一个成员子对象，所述第二位图中的每一行对应于一个成员子对象且每一列对应于一个部门子对象，所述第三位图中每一行对应于一个成员子对象且每一列对应于一个应用子对象。
在一种可能实施方式中，所述生成子子单元被配置为执行：
在所述查询结果指示所述子对象对任一其他子对象具有所述权限时，在所述位图中，将所述元素赋值为1；
在所述查询结果指示所述子对象对任一其他子对象不具有所述权限时，在所述位图中，将所述元素赋值为0。
在一种可能实施方式中，所述装置还包括：
划分单元，被配置为执行将所述目标对象中的各个子对象划分为多个子对象集合；
所述生成子单元，被配置为执行：
对多个计算设备中的每个计算设备，从所述多个子对象集合中确定未生成管控数据的任一子对象集合；
基于所述至少一个查询结果中与所述子对象集合对应的查询结果，生成所述子对象集合对应的部分管控数据；
将所述多个计算设备生成的各个部分管控数据合并得到所述管控数据。
在一种可能实施方式中，所述装置还包括：
第三获取单元，被配置为执行每间隔目标时长，获取在所述目标时长内接收到的与所述权限关联的更新指令，所述更新指令用于变更与所述目标对象的所述权限关联的数据记录或业务规则信息中至少一项；
所述构建单元，还被配置为执行基于所述更新指令，更新所述拓扑关系图；
所述第二获取单元，还被配置为执行基于更新后的拓扑关系图，更新所述权限的管控数据。
在一种可能实施方式中，所述装置还包括：
分配单元，被配置为执行对初次获取的管控数据和每次更新所得的管控数据分配版本号，所述版本号与所述管控数据的生成时间戳呈单调递增；
返回单元，被配置为执行响应于任一权限查询请求中携带版本号，在携带的版本号与所述管控数据的最大版本号相同时，返回目标状态信息，所述目标状态信息用于表征所述管控数据无变化。
根据本公开实施例的另一方面，提供一种计算机设备，包括：
一个或多个处理器；
用于存储所述一个或多个处理器可执行指令的一个或多个存储器；
其中，所述一个或多个处理器被配置为执行上述一方面的任一种可能实施方式中的权限信息的获取方法。
根据本公开实施例的另一方面，提供一种计算机可读存储介质，当所述计算机可读存储介质中的至少一条指令由计算机设备的一个或多个处理器执行时，使得所述计算机设备能够执行上述一方面的任一种可能实施方式中的权限信息的获取方法。
根据本公开实施例的另一方面，提供一种计算机程序产品，包括一条或多条指令，所述一条或多条指令可以由计算机设备的一个或多个处理器执行，使得所述计算机设备能够执行上述一方面的任一种可能实施方式中的权限信息的获取方法。
本公开的实施例提供的技术方案至少带来以下有益效果：
通过将与权限关联的数据记录转储成对应的拓扑关系图，使得在生成该权限的管控数据时，将业务规则信息解析成查询操作之后，无需对数据记录执行复杂级联查询操作，而是能够直接对拓扑关系图即图数据执行相关的查询操作，从而大大提升了对管控数据的计算效率，打破了RBAC模型的局限性，能够适用于职务种类繁多、业务规则复杂的应用场景。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。
图1是根据一示例性实施例示出的一种权限信息的获取方法的实施环境示意图；
图2是根据一示例性实施例示出的一种权限信息的获取方法的流程图；
图3是根据一示例性实施例示出的一种权限信息的获取方法的流程图；
图4是本公开实施例提供的一种拓扑关系图的原理性示意图；
图5是本公开实施例提供的一种基于内存计算的网络拓扑***的架构示意图；
图6是本公开实施例提供的一种管控数据的位图的示意图；
图7是本公开实施例提供的一种单个子对象的管控数据的存储格式的原理性示意图；
图8是本公开实施例提供的一种权限计算与存储的业务更新流程图；
图9是本公开实施例提供的一种管控数据的在线服务架构示意图；
图10是本公开实施例提供的一种应用程序的交互界面示意图；
图11是本公开实施例提供的一种应用程序的交互界面示意图；
图12是根据一示例性实施例示出的一种权限信息的获取装置的逻辑结构框图；
图13示出了本公开一个示例性实施例提供的一种计算机设备的结构框图；
图14是本公开实施例提供的一种计算机设备的结构示意图。
具体实施方式
为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。
需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。
本公开所涉及的用户信息可以为经用户授权或者经过各方充分授权的信息。
随着互联网技术的发展，在一些通讯类应用中，通常使用基于角色的访问控制(Role-Based Access Control，RBAC)模型来对各个用户的账号进行权限分配。比如，在企业通讯应用中，由于承载了企业通讯录的组织架构、企业中高管理层的用户信息等私密信息，因此此类应用的权限控制和数据安全是十分值得引起重视的。
在RBAC模型中，将用户、权限之间通过角色来进行管理，比如，通常会对每个企业创建一系列的角色(如职务)，对不同的角色配置不同的访问控制权限，使得每个用户的账号在建立与角色的对应关系之后，获取为该角色配置的访问控制权限。上述RBAC模型仅支持少量(通常是10～20个)角色的创建，而在一些企业办公领域中，并不能仅根据部门单一维度来进行权限判断(比如同一部门下有些成员对另一部门的成员具有可见权限，有些成员对另一部门的成员不具有可见权限)，因此普遍会存在需要根据部门和成员的属***叉组合计算来判断权限的情况，这在RBAC模型中需要对每一组交叉组合的情况创建一个角色，在对上述交叉组合的情况初步估算中，需要创建上千个不同的角色，而RBAC模型需要***管理员提前创建角色，这对于RBAC模型来说是不能够支持的。
此外，在一些企业办公领域中，对于不同的部门或成员，希望能够精细化控制部门可见性、成员可见性、成员可搜和/或可聊权限等，以及上述权限还需要进一步划分为单向和/或双向，因此需要根据组织架构属性、实体属性、环境属性和某些特殊规则来对各项权限进行动态计算，随着业务的高速发展，权限的需求也是不稳定的，有时候为了快速响应业务方需求，***需要支持一定的灵活性以保障***的稳定性，也需要在时间上支持一定周期的业务需求变化，而RBAC模型则不支持动态计算权限，也无法对不稳定的权限需求提供灵活性，换言之，RBAC模型无法适用于一些职务种类繁多、业务规则复杂的场景。
有鉴于此，本公开实施例提供一种权限信息的获取方法，能够基于内存构建所有成员的属性值组成的网络拓扑结构(即拓扑关系图)，来应对像传统的MySQL等关系数据库所无法处理的级联查询问题，并且，通过创建业务规则信息的操作原语NetQL，能够应对业务需求的快速变更，此外，最终获取到对应权限的管控数据能够精确表征每个成员到另一成员之间是否具有某一项权限，从而能够对各类业务的权限所关联的资源达到精细化地访问控制。
进一步的，在计算和存储问题上，考虑到存储的数据量扩展、高可用、计算速度等方面的因素，通过定时任务来定期构建各项权限的管控数据的快照，并应用分布式计算架构来缓解单节点的计算负载，以支持计算能力的横向扩展。
进一步的，针对在线服务方面，制定兜底策略和容错机制，保证了服务的稳定性和高可用性，并且，通过对管控数据的读写分离、多级缓存、版本号、限定等方式，提升了服务的在线QPS(Query Per Second，每秒查询率，是衡量吞吐量的一种指标)。
以下，对本公开实施例的实施环境进行介绍。
图1是根据一示例性实施例示出的一种权限信息的获取方法的实施环境示意图，参见图1，在该实施环境中可以包括至少一个终端101和服务器102，下面进行详述：
终端101安装和运行有支持查询权限和/或资源访问的应用程序，可选地，该应用程序包括但不限于：目标对象的办公应用(如企业办公应用)、目标对象的通讯应用(如企业通讯应用)、支持目标对象内成员通讯的社交应用、会议应用、考勤应用等，本公开实施例不对该应用程序的类型进行具体限定。其中，该目标对象唯一对应于组织实体，该组织实体包括但不限于：企业、事业单位、非法人组织等，本公开实施例对此不进行具体限定。
终端101通过有线或无线方式与服务器102进行直接或间接地通信连接。
服务器102包括一台服务器、多台服务器、云计算平台或者虚拟化中心中的至少一种。服务器102用于为支持查询权限和/或资源访问的应用程序提供后台服务，例如，服务器102用于对外提供各种权限的管控数据。可选地，服务器102承担主要计算工作，终端101承担次要计算工作；或者，服务器102承担次要计算工作，终端101承担主要计算工作；或者，终端101和服务器102之间采用分布式计算架构进行协同计算。
可选地，服务器102是独立的物理服务器，或者是多个物理服务器构成的服务器集群或者分布式***，或者是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(Content Delivery Network，CDN)以及大数据和人工智能平台等基础云计算服务的云服务器。
示意性地，假设目标对象为企业，以企业内的通讯和办公场景为例，对支持查询权限和/或资源访问的应用程序来说，主要需要对本应用程序内注册的各个账号之间相互的可见性和可聊性这两种维度的权限进行精细化控制，其中，可见性包括部门可见性、成员可见性和应用可见性，部门可见性是指用户在应用程序中打开通讯录时是否能够查看到某一部门的标签栏，成员可见性是指用户在应用程序中打开通讯录时是否能够查看到某一成员(本部门成员或其他部门成员或高层领导等)，应用可见性是指用户在应用程序中是否能够查看到目标对象关联的第三方应用以及能够查看到哪些第三方应用，其中，可聊性通常与可搜性对应，即指，用户是否能够在应用程序中搜索某一成员并向搜索到的成员发起聊天会话。利用本公开实施例提供的权限信息的获取方法，能够生成以成员为粒度的管控数据，从而精细化地控制每个成员对任一成员或部门或应用的可见性和可聊性。
终端101泛指多个终端中的一个，终端101的设备类型包括：智能手机、平板电脑、智能音箱、智能手表、笔记本电脑或者台式计算机中的至少一种，但并不局限于此。例如，终端101可以是智能手机或其他手持便携式通信设备。
本领域技术人员可以知晓，上述终端101的数量可以更多或更少。比如上述终端101可以仅为一个，或者上述终端101为几十个或几百个，或者更多数量。本公开实施例对终端101的数量和设备类型不加以限定。
图2是根据一示例性实施例示出的一种权限信息的获取方法的流程图，参见图2，该权限信息的获取方法应用于计算机设备，下面以计算机设备为服务器为例进行说明。
在步骤201中，服务器获取与目标对象的权限关联的至少一条数据记录。
在步骤202中，服务器基于该至少一条数据记录，构建拓扑关系图，该拓扑关系图用于表征各条数据记录中属性名与属性值的关联关系。
在步骤203中，服务器基于与该权限关联的业务规则信息和该拓扑关系图，获取该权限的管控数据，该管控数据用于提供对该权限所关联的资源的访问控制策略。
本公开实施例提供的方法，通过将与权限关联的数据记录转储成对应的拓扑关系图，使得在生成该权限的管控数据时，将业务规则信息解析成查询操作之后，无需对数据记录执行复杂级联查询操作，而是能够直接对拓扑关系图即图数据执行相关的查询操作，从而大大提升了对管控数据的计算效率，打破了RBAC模型的局限性，能够适用于职务种类繁多、业务规则复杂的应用场景。
在一种可能实施方式中，该至少一条数据记录中的每条数据记录对应于目标对象内的一个子对象；
该拓扑关系图中包括多个节点，具有拓扑关系的不同节点之间通过有向边连接，其中，每个节点对应于一个子对象的一个属性值，每条有向边对应于所指向节点对应属性值的属性名。
在一种可能实施方式中，基于该至少一条数据记录，构建拓扑关系图包括：
基于每条数据记录中的各个属性值，构建该拓扑关系图中的各个节点；
基于每条数据记录中的各个属性名，构建该拓扑关系图中连接不同节点的各条有向边。
在一种可能实施方式中，基于与该权限关联的业务规则信息和该拓扑关系图，获取该权限的管控数据包括：
解析该业务规则信息，得到对该拓扑关系图的至少一个查询指令；
基于该拓扑关系图，执行该至少一个查询指令，得到至少一个查询结果；
基于该至少一个查询结果，生成该管控数据。
在一种可能实施方式中，该拓扑关系图以哈希表形式存储，其中，该哈希表中记录有多个集合，每个集合中存储有该拓扑关系图中的一个节点的属性值、接入该节点的有向边的属性名以及与该节点相连接的其他节点的属性值；
基于该拓扑关系图，执行该至少一个查询指令，得到至少一个查询结果包括：
基于该至少一个查询指令，对该哈希表中的各个集合执行对应的处理操作，得到该至少一个查询结果。
在一种可能实施方式中，基于该至少一个查询指令，对该哈希表中的各个集合执行对应的处理操作，得到该至少一个查询结果包括：
对每个查询指令，确定该查询指令所携带的目标属性值；
基于该哈希表中与该目标属性值对应的目标集合，获取该查询指令的查询结果，该目标集合用于表征具有该目标属性值的各个子对象。
在一种可能实施方式中，在该查询指令中携带多个该目标属性值的情况下，基于该哈希表中与该目标属性值对应的目标集合，获取该查询指令的查询结果包括：
对多个该目标属性值对应的目标集合，执行与该查询指令的查询语义相匹配的处理操作，得到该查询指令的查询结果。
在一种可能实施方式中，该管控数据以位图形式存储，该位图中的每一个元素用于表征该元素所在行的索引是否对该元素所在列的索引具有该权限；
基于该至少一个查询结果，生成该管控数据包括：
对该目标对象中的每个子对象分配对应的索引；
基于该至少一个查询结果，对每个子对象关联的索引所在行和其他子对象关联的索引所在列所确定的元素进行赋值，以生成该位图。
在一种可能实施方式中，该目标对象的子对象包括下述至少一项：成员子对象、部门子对象或者与该目标对象关联的应用子对象；
该生成的位图包括下述至少一项：对应于该成员子对象的位图、对应于该成员子对象和该部门子对象的位图或者对应于该成员子对象和该应用子对象的位图。
在一种可能实施方式中，对该目标对象中的每个子对象分配对应的索引包括：
对该目标对象中的每个成员子对象、部门子对象和与该目标对象关联的应用子对象均分配对应的索引；
基于该至少一个查询结果，对每个子对象关联的索引所在行和其他子对象关联的索引所在列所确定的元素进行赋值，以生成该位图包括：
对每个成员子对象，基于该至少一个查询结果，对该成员子对象关联的索引所在行和其他子对象关联的索引所在列所确定的元素进行赋值，以生成该权限的第一位图、第二位图和第三位图；
其中，该第一位图中的每一行和每一列均对应于一个成员子对象，该第二位图中的每一行对应于一个成员子对象且每一列对应于一个部门子对象，该第三位图中每一行对应于一个成员子对象且每一列对应于一个应用子对象。
在一种可能实施方式中，对每个子对象关联的索引所在行和其他子对象关联的索引所在列所确定的元素进行赋值包括：
在该查询结果指示该子对象对任一其他子对象具有该权限时，在该位图中，将该元素赋值为1；
在该查询结果指示该子对象对任一其他子对象不具有该权限时，在该位图中，将该元素赋值为0。
在一种可能实施方式中，该方法还包括：
将该目标对象中的各个子对象划分为多个子对象集合；
基于该至少一个查询结果，生成该管控数据包括：
对多个计算设备中的每个计算设备，从该多个子对象集合中确定未生成管控数据的任一子对象集合；
基于该至少一个查询结果中与该子对象集合对应的查询结果，生成该子对象集合对应的部分管控数据；
将该多个计算设备生成的各个部分管控数据合并得到该管控数据。
在一种可能实施方式中，该方法还包括：
每间隔目标时长，获取在该目标时长内接收到的与该权限关联的更新指令，该更新指令用于变更与该目标对象的该权限关联的数据记录或业务规则信息中至少一项；
基于该更新指令，更新该拓扑关系图；
基于更新后的拓扑关系图，更新该权限的管控数据。
在一种可能实施方式中，该方法还包括：
对初次获取的管控数据和每次更新所得的管控数据分配版本号，该版本号与该管控数据的生成时间戳呈单调递增；
响应于任一权限查询请求中携带版本号，在携带的版本号与该管控数据的最大版本号相同时，返回目标状态信息，该目标状态信息用于表征该管控数据无变化。
上述所有可选技术方案，可以采用任意结合形成本公开的可选实施例，在此不再一一赘述。
图3是根据一示例性实施例示出的一种权限信息的获取方法的流程图，参见图3，该权限信息的获取方法由计算机设备执行，下面以计算机设备为服务器为例进行说明。
在步骤301中，服务器获取与目标对象的权限关联的至少一条数据记录，该至少一条数据记录中的每条数据记录对应于目标对象内的一个子对象。
可选地，该目标对象唯一对应于组织实体，该组织实体包括但不限于：企业、事业单位、非法人组织等，该目标对象内的子对象包括下述至少一项：部门子对象、成员子对象或者与该目标对象关联的应用子对象。
可选地，该目标对象的权限是指在应用程序中对目标对象的通讯录信息以及接入的第三方应用的访问权限，该通讯录信息至少包括：目标对象内的部门子对象的组织架构和各个成员子对象的联系人信息，出于数据安全性考虑，并不希望所有的用户都能够访问到全部通讯录信息，因此需要对每个用户所能够看到的部分通讯录信息进行精细化的权限管控。
由于不同的权限可能与不同的子对象相关联，因此，服务器需要根据权限涉及的子对象，从底层的数据库中将各个子对象的数据记录读取到内存中。可选地，该权限包括但不限于：可见性权限、可搜性权限、可聊性权限等，本公开实施例对此不进行具体限定。
在一个示例性场景中，以目标对象为企业为例，对企业办公应用来说，主要需要精细化控制通讯录信息中部门子对象或成员子对象的可见性权限、可搜性权限、可聊性权限等，并且还需要精细化控制对与该目标对象关联的应用子对象的接入访问权限，因此，服务器需要从底层的数据库中读取到通讯录信息相关的部门属性的数据记录和成员属性的数据记录，并读取到与目标对象关联的应用属性的数据记录，其中，该部门属性的数据记录用于存储对应部门子对象的名称、等级、父部门、子部门等属性信息，该成员属性的数据记录用于存储对应成员子对象的名称、性别、年龄、籍贯、所属部门等属性信息，该应用属性的数据记录用于存储对应应用子对象的名称、关联业务类型、对接部门、对接成员等属性信息。其中，本公开所涉及的部门子对象、成员子对象或应用子对象的属性信息均为经授权或者经过各方充分授权的信息。
在步骤302中，服务器基于该至少一条数据记录，构建拓扑关系图，该拓扑关系图用于表征各条数据记录中属性名与属性值的关联关系。
其中，该拓扑关系图中包括多个节点，具有拓扑关系的不同节点之间通过有向边连接，其中，每个节点对应于一个子对象的一个属性值，每条有向边对应于所指向节点对应属性值的属性名。
由于每条数据记录中包括多个字段，每个字段中都存储由一个属性值，而每个属性值都具有对应的属性名，换言之，对一张数据表来说，数据表中的每一行对应于一条数据记录，数据表中的每一列对应于一个字段，列名即字段名就是属性名。
在一些实施例中，由于拓扑关系图中的每个节点对应于一个属性值，每条有向边对应于一个属性名，因此，服务器可基于每条数据记录中的各个属性值，构建该拓扑关系图中的各个节点；基于每条数据记录中的各个属性名，构建该拓扑关系图中连接不同节点的各条有向边。
可选地，在拓扑关系图中，将每一条数据记录中的每个属性值作为拓扑关系图中的一个节点，接着，对每一条数据记录，由于一定会存在一个能够唯一标识该条数据记录的目标属性值(比如，成员子对象、部门子对象或应用子对象的名称，又比如，成员子对象、部门子对象或应用子对象的标识码，又比如，每条数据记录的主键标识等)，因此，以目标属性值所对应的节点作为本条数据记录相关的所有有向边的起点，再连接本条数据记录中存储的其他各个属性值对应的其他节点，而每一条有向边都与所指向节点(即边的终点)对应的属性值的属性名相对应。
在上述过程中，通过将数据表中原本的该至少一条数据记录转换为图数据形式的拓扑关系图，而拓扑关系图中这些节点和边之间的拓扑关系可转换其他形式来存储，使得原本需要对数据记录进行的级联查询，转换成对其他数据结构的相关操作，例如，该拓扑关系可转换为哈希表(HashMap、HashSet等)形式存储，使得对数据记录的级联查询能够转换为对哈希表中集合的交、并、补等操作，以降低数据库的输入(Input)/输出(Output)即I/O操作。
在一些实施例中，服务器将该拓扑关系图以哈希表形式存储，其中，该哈希表中记录有多个集合，每个集合中存储有该拓扑关系图中的一个节点的属性值、接入该节点的有向边的属性名以及与该节点相连接的其他节点的属性值。在上述过程中，相当于将传统的二维表格式的数据记录读取到内存中之后，转换为图数据格式，构建成网状的拓扑结构，类似于一种基于内存构建的图数据库。
下面，将以两条成员子对象的数据记录为例，介绍如何将多条数据记录转换为拓扑关系图。该两条数据记录如下表1所示：
表1
名称 性别 年龄 籍贯
成员A 男 25 安徽省
成员B 男 20 安徽省
上述表1中的两条数据记录可转换为如图4所示的拓扑关系图，其中，该两条数据记录中共存在“成员A”、“男”、“25”、“安徽省”、“成员B”、“20”这6个互不相同的属性值，因此在拓扑关系图中包含6个节点，进一步的，对每条数据记录，以成员名称作为目标属性值(即有向边的起点)，可构建出分别与“性别”、“年龄”、“籍贯”这3个属性名相关的3条有向边，且每条有向边都从成员名称所在节点出发，指向与本条有向边上的属性名对应的属性值所在的节点，例如，从成员A所在节点出发，与“性别”这一属性名对应的有向边指向了“男”这一属性值对应的节点，以此类推，这里不再赘述。
如图4所示的拓扑关系图中各个节点和边之间的拓扑关系，可转换为哈希表形式存储，可选地，对拓扑关系表中的每个节点，将该节点以及周围的拓扑关系构建成一个集合并存储在哈希表中，此时，对图4中的6个节点可构建出6个集合(也称为关系集合Entitynet)，也即是说，在哈希表中存储有如下6个集合：
{成员A，{性别，[男]}，{年龄，[25]}，{籍贯，[安徽省]}}
{成员B，{性别，[男]}，{年龄，[20]}，{籍贯，[安徽省]}}
{男，{～性别，[成员A、成员B]}}
{安徽省，{～籍贯，[成员A、成员B]}}
{20，{～年龄，[成员B]}}
{25，{～年龄，[成员A]}}
示意性地，上述集合以一种类似递归的HashMap与HashSet组合的数据结构存储，在HashMap中保存目标属性值与实体(Entity)关系，例如上述第一个和第二个集合，保存了目标属性值(成员名称)与关联的实体关系(对应数据记录中其他属性值和对应属性名)，此外，在HashMap中还保存关系与关系对应的属性值集合，例如上述第三个到第六个集合，保存了关系(其他属性值与对应的属性名)与关系对应的属性值集合(与该属性名对应的所有成员名称)。
通过将拓扑关系图中边和节点之间的拓扑关系转换为多个集合存储到哈希表中，使得该拓扑关系能够以每个集合所对应的属性值作为Key(键)、对应的属性名作为Value(值)，从而以Key-Value键值对的方式进行存储。例如，对上述第五个集合，以“20”作为Key，以“{～年龄，[成员B]}”作为Value，从而以Key-Value键值对的方式进行存储。其中，符号“～”表示的是反向关系，安徽省对于籍贯的反向关系是成员A和成员B，成员A对于性别的正向关系是男。
本公开实施例涉及拓扑关系图，具有高效的查询性能，非常适合一些数据量相对较小、数据关联复杂，且对查询性能具有一定要求的应用场景，例如企业内部办公和通讯场景。
在步骤303中，服务器解析与该权限关联的业务规则信息，得到对该拓扑关系图的至少一个查询指令。
其中，该业务规则信息是指：根据目标对象的业务需求，对目标对象内部的各个子对象针对本类型的权限所构建的管控规则，例如，假设本类型的权限是指可见性权限，那么一种可能的业务规则信息为职务为领导的成员子对象对所领导部门的所有父部门和子部门具有可见性权限，本公开实施例对业务规则信息的具体内容不进行限定。
在一些实施例中，***管理员输入与该权限关联的业务规则信息之后，通过执行解析器，可将复杂的该业务规则信息均解析为对拓扑关系图的一条条查询指令，从而能够通过执行各条查询指令，得到依照该业务规则信息的约束下，每个子对象是否能够对另一子对象具有相应的权限。示意性地，输入与可见性权限关联的业务规则信息之后，通过执行解析器解析得到各条查询指令，在拓扑关系图上执行各条查询指令，从而能够得到在该可见性权限关联的业务规则信息的约束下，企业内的每个成员子对象是否能够看到通讯录信息中的任一部门子对象、成员子对象或者应用子对象。
可选地，该业务规则信息包括但不限于：组织架构属性、实体属性、环境属性以及特殊规则等，下表2中示出了几种可能的对应于不同权限的业务规则信息：
表2
Figure BDA0003404450500000191
Figure BDA0003404450500000201
可以看出表2中示出了业务规则信息涉及到复杂的级联查询操作，比如规则“领导和人力资源管理者能够看到等级为03和04以及所领导部门的所有父部门和子部门”，如果没有构建拓扑关系图，由于对任一成员属性的变更都会影响到全体成员，比如，以可见性权限为例，某一成员X从兼职劳务转换为全职劳务之后，成员X可见的其他成员和部门，以及其他成员是否能够在通讯录中看到成员X都会发生一系列的变更，因此，在每次查询权限时都需要重新计算一遍全量的业务规则信息，以感知到***内对该权限发生的最新的变更(避免使用陈旧的业务规则信息导致对权限管控出错)，考虑到一些快速发展的企业，每一轮查询权限时都需要遍历上万名成员的相关数据记录，导致对权限查询请求或者需要鉴权的资源访问请求的计算速度和处理效率都很低，并且，观察表2可以看出业务规则信息的影响因素都限定在了通讯录信息相关的成员属性和部门属性，因此只需要通过上述步骤301将相关的各条数据记录加载到内存中，并且将各条数据记录转为一张拓扑关系图，就能够提升***对该权限的管控数据的计算速度，且还能够提高对权限查询请求或者需要鉴权的资源访问请求的响应速度和处理效率。
在一些实施例中，由于本公开实施例已经将传统数据表中的数据记录转换成了基于内存的拓扑关系图，因此在解析业务规则信息时，如果解析成对数据记录进行操作的SQL命令，是无法直接操作拓扑关系图中的图数据的，有鉴于此，本公开实施例提供一种操作原语NetQL，该操作原语NetQL是查询指令的一种示例性说明，通过将业务规则信息转换为至少一个操作原语NetQL，能够使用各个操作原语NetQL来对拓扑关系图的哈希表中的各个集合进行交并补操作，以得到最终的各个查询结果。其中，原语是指一种对计算机进程的控制程序，一般是由若干条指令组成的程序段，用来实现某个特定功能(本公开实施例是指对拓扑关系图的查询功能)，在执行过程中不可被中断，即具有原子操作的性质，因此被称为原语。
在上述过程中，通过将业务规则信息转换为操作原语NetQL，相当于将复杂的业务规则信息转换为基础语法包裹的操作原语NetQL，类似于传统数据库中将复杂的查询语句解析为SQL命令的过程，只是SQL命令和本公开实施例提出的操作原语NetQL两者的基础语法不同。操作原语NetQL可直接在拓扑关系图的哈希表上进行查询操作，示意性地，操作原语NetQL的语法规则如下表3所示：
表3
原语 含义 原语 含义
{} 实体/集合 + 并集
-> 正向关系 - 差集
～ 反向关系 & 交集
* 关系递归 [关系x,集合] 关系过滤器
{集合}？{集合} 三目计算 () 计算优先符
？ 参数 # 结束符/实体符
下面，将以表3中示出的操作原语NetQL的语法规则为例，介绍几种较为简单的查询操作如何解析为NetQL查询指令，对于其他复杂的业务规则信息，也能够按照类似的方式解析为一个个NetQL查询指令。
例如，查询操作为：查询成员性别为男的数据，可通过“男→～性别#”的查询语句进行查询，在执行解析器中将该查询语句解析为“((男→～性别)#)”NetQL查询指令进行执行。
例如，查询操作为：查询成员性别为男和女的数据，可通过“男→～性别+女→～性别#”的查询语句进行查询，在执行解析器中将该查询语句解析为“(((男→～性别)+(女→～性别))#)”NetQL查询指令进行执行，也即，将性别为男的实体集合和性别为女的实体集合取并集。
例如，查询操作为：通过成员ID(Identification，标识)查询成员名称，则最终执行解析器会解析得到“UserId→～UserId[username,％]→username#”NetQL查询指令进行执行。其中，第一个UserId是一个成员ID数值，比如UserId＝123，如果查询操作是查询成员ID为123的成员的成员昵称，此时，执行解析器解析出“123→～UserId[username,％]→username#”NetQL查询指令，“～UserId”代表获取到属性值“123”对属性名“成员ID”的反向关系，接着通过“[usern ame,％]”过滤出username属性，并获取到username属性的属性值。
图5是本公开实施例提供的一种基于内存计算的网络拓扑***的架构示意图，如图5所示，***接收到外部的检索需求之后，首先在NetQL层501通过解析引擎将检索需求需要处理的业务逻辑转换为NetQL查询指令，再通过执行引擎来对拓扑关系图的哈希表执行NetQL查询指令。可选地，该哈希表存储在数据持久层502的JVM(Java Virtual Machine，Java虚拟机)内存中，服务器通过ORM(Object Relational Mapping，对象关系映射)等数据抽取方式从底层的数据层503中抽取数据记录，并将数据记录映射为拓扑关系图，在JVM内存中缓存拓扑关系图对应的哈希表。可选地，底层的数据层503可基于多种存储引擎来保存数据记录，该存储引擎包括但不限于：MySQL、HBase、Hive、Redis、Kafka等开源数据库，本公开实施例不对存储引擎的类型进行具体限定。
在步骤304中，服务器基于该拓扑关系图，执行该至少一个查询指令，得到至少一个查询结果。
在一些实施例中，由于该拓扑关系图中的拓扑关系可以哈希表的形式存储，因此在执行该查询指令时，可直接对基于该至少一个查询指令，对该哈希表中的各个集合执行对应的处理操作，得到该至少一个查询结果。在上述过程中，通过对哈希表中的各个集合执行处理操作，避免对原始的数据记录进行复杂的级联查询，而是能够直接从构建的图数据库中执行计算量更小、查询速度更快的集合交并补操作，因此能够大大提升查询效率。
在一些实施例中，服务器对每个查询指令，确定该查询指令所携带的目标属性值；基于该哈希表中与该目标属性值对应的目标集合，获取该查询指令的查询结果，该目标集合用于表征具有该目标属性值的各个子对象。其中，该目标属性值是指该查询指令所欲操作的属性值，比如，想要查看性别为男的所有子对象，那么查询指令中携带的目标属性值就是“男”，又比如，想要查看籍贯为安徽省的所有子对象，那么查询指令中携带的目标属性值就是“安徽省”。服务器解析该查询指令，即可得到该目标属性值，接着，以该目标属性值为索引，在哈希表中查询具有该目标属性值的各个子对象即目标集合，即可得到该查询结果，例如，目标属性值为“男”时，在哈希表中查询具有“男”这一属性值的各个子对象，将具有“男”这一属性值的所有子对象构成的集合确定为目标集合，这一目标集合就是本次的查询结果。
在一种可能实施方式中，由于查询指令有可能会携带多个目标属性值，即查询指令所欲操作多个属性值，此时，服务器需要对多个该目标属性值对应的目标集合，执行与该查询指令的查询语义相匹配的处理操作，得到该查询指令的查询结果。比如查询指令指定查询性别为男和性别为女的所有子对象，那么查询指令携带了2个目标属性值“男”和“女”，此时解析该查询指令得到的查询语义为“求并集”，服务器需要先获取具有“男”这一属性值的所有子对象构成的一个目标集合，再获取具有“女”这一属性值的所有子对象构成的另一个目标集合，再对2个目标集合执行该查询语义“求并集”，即将上述2个目标集合的并集作为最终的查询结果。
在上述过程中，通过将查询指令所指定的查询操作，转化为对哈希表中目标集合执行与查询语义相匹配的处理操作，能够大大简化获取查询结果时的计算量，提高了获取查询结果的计算效率，节约了服务器的计算资源。
在一些实施例中，如果对业务规则信息解析得到的是NetQL查询指令，可直接对哈希表中的各个集合进行交并补操作，从而实现业务规则信息中所指示的查询操作，需要说明的是，本公开实施例仅以NetQL作为一种对哈希表中的集合进行操作的原语的示例性说明，本领域技术人员可根据业务需求构建其他能够对图数据进行操作的原语或指令，并配置对应的语法规则，本公开实施例对此不进行具体限定。
在步骤305中，服务器基于该至少一个查询结果，生成该权限的管控数据，该管控数据用于提供对该权限所关联的资源的访问控制策略。
在一些实施例中，该管控数据以位图形式存储，该位图中的每一个元素用于表征该元素所在行的索引是否对该元素所在列的索引具有该权限，可选地，该位图中的每个元素都是一个二值化数值，当元素取1时代表该元素所在行的索引对该元素所在列的索引具有对应的权限，当元素取0时代表该元素所在行的索引对该元素所在列的索引不具有对应的权限。
在上述过程中，通过将管控数据以位图形式存储，只需要为目标对象内的每个子对象都分配一个唯一的索引，就能够使得位图表征出每个子对象是否对其他子对象具有对应的权限，即实现子对象级别细粒度的权限管控，并且还能够表征出任意两个子对象之间的权限是单向还是双向，例如，子对象i对子对象j具有该权限，但子对象j对子对象i不具有该权限，代表子对象i对该子对象j具有的是单向权限，因此，在位图中表现出的是第i行第j列的元素取值为1，但第j行第i列的元素取值为0。
在一些实施例中，服务器对目标对象中的每个子对象分配对应的索引；基于该至少一个查询结果，确定每个子对象是否对其他子对象具有该权限，以生成该位图。可选地，服务器基于该至少一个查询结果，确定每个子对象是否对其他子对象具有该权限，接着，基于每个子对象是否对其他子对象具有该权限，对每个子对象关联的索引所在行和其他子对象关联的索引所在列所确定的元素进行赋值，最终对该位图中的每个元素都进行赋值后，可生成一张管控数据的位图。
在一些实施例中，在对目标对象中的每个子对象分配索引时，由于每个子对象各自本身具有子对象ID(例如为varchar32类型的字符串)，而有可能每个子对象在应用程序中注册账号之后还会被分配得到一个账号ID(例如为非自增的、随机的long类型数据)，而在构建管控数据的位图时需要对每个子对象分配一个Index索引(例如为int整型，取值范围为1～N，N＞1，N是指目标对象中子对象的总数量)，因此，可对每个子对象的数据记录中新增一个自增长的ID字段(即Index索引)，因此在保存原本子对象ID和账号ID的对应关系的基础上，还需要创建<子对象ID，账号ID，Index索引>三元组Mapping(映射)对象，该三元组用于记录每个子对象的各个ID之间的三元对应关系。
在一些实施例中，在进行位图中元素的赋值时，在该查询结果指示该子对象对任一其他子对象具有该权限时，在该位图中，将该子对象关联的索引所在行和该其他子对象关联的索引所在列所确定的元素赋值为1；在该查询结果指示该子对象对任一其他子对象不具有该权限时，在该位图中，将该子对象关联的索引所在行和该其他子对象关联的索引所在列所确定的元素赋值为0。
在一些实施例中，由于该目标对象的子对象包括下述至少一项：成员子对象、部门子对象或者与该目标对象关联的应用子对象，因此，基于上述介绍的方式所生成的位图包括下述至少一项：对应于该成员子对象的位图、对应于该成员子对象和该部门子对象的位图或者对应于该成员子对象和该应用子对象的位图。
可选地，在对子对象分配索引时，基于上述分配索引的方式，对该目标对象中的每个成员子对象、部门子对象和应用子对象均分配对应的索引。
可选地，在生成位图时，对每个成员子对象，基于该至少一个查询结果，对该成员子对象关联的索引所在行和其他子对象关联的索引所在列所确定的元素进行赋值，以生成该权限的第一位图、第二位图和第三位图，换言之，服务器对每个成员子对象都会生成3张位图，其中，该第一位图中的每一行和每一列均对应于一个成员子对象，即，第一位图是对应于该成员子对象的位图，用于表征成员-成员的权限管控数据，该第二位图中的每一行对应于一个成员子对象且每一列对应于一个部门子对象，即，第二位图是对应于该成员子对象和该部门子对象的位图，用于表征成员-部门的权限管控数据，该第三位图中每一行对应于一个成员子对象且每一列对应于一个应用子对象，即第三位图是对应于该成员子对象和该应用子对象的位图，用于表征成员-应用的权限管控数据。
在上述过程中，通过对每个成员子对象都生成3张位图，不同的位图用于描述成员子对象和不同类型子对象的权限管控数据，从而能够进一步对成员子对象的权限进行精细化管控。
在一些实施例中，将上述3张位图集成为1张位图，即，该位图中包含N行和M(M＝N+J+K)列，N行中每一行均对应于一个成员子对象，但M列中的前N列中每一列均对应于一个成员子对象，第N+1列到第N+J列中每一列均对应于一个部门子对象，第N+J+1列到第M列中每一列均对应于一个应用子对象，其中N、J、K均为大于或等于1的整数，M为大于N的整数，N是指目标对象所包含的成员子对象的数量，J是指目标对象所包含的部门子对象的数量，K是指目标对象所关联的应用子对象的数量。
在上述过程中，由于业务规则信息能够指示出在相关业务规则的约束下，哪些子对象对其他子对象具有相关的权限，因此很容易能够确定出哪些元素应该赋值为1，其余元素赋值为0即可，从而得到一张子对象级别的细粒度的位图，该位图也即是本权限的管控数据。
图6是本公开实施例提供的一种管控数据的位图的示意图，如图6所示，对目标对象内的每个子对象分配索引，得到[u1,u2,u3,u4,…,un]，从而构建出一张尺寸为n×n(n行n列，n为大于1的整数)的位图，位图中的每一个元素代表对应行索引的子对象是否对对应列索引的子对象具有该权限，例如，假设该位图是可见性权限的管控数据，那么[ui,uj]＝0代表子对象ui不能在通讯录中看到子对象uj(即不具有可见性权限)，[ui,uj]＝1代表子对象ui能够在通讯录中看到子对象uj(即具有可见性权限)。
上述以位图(即bit数组)方式存储的管控数据，由于每个元素要么是0要么是1，因此以目标对象内包含30000个子对象为例，经过笛卡尔积扩展后，位图所占用的空间为：
30000*30000bit/8/1024/1024＝107M
即，当目标对象内包含30000个子对象时，每种权限的管控数据都需要占用107M的存储空间，即使当规模扩展到10w(万)个子对象时，所需要的总存储开销也仅有1192M，单个子对象也只需要120K的存储空间，因此能够满足目标对象在短期内的业务扩张的增长速度，具有较低的存储开销。
在上述步骤303-305中，服务器基于与该权限关联的业务规则信息和该拓扑关系图，获取到了该权限的管控数据，其中，该管控数据用于提供对该权限所关联的资源的访问控制策略，本公开实施例仅以单个权限的管控数据的生成过程为例进行说明，当***内存在多种权限的精细化访问控制需求时，对每一种权限都执行上述步骤301-305的流程，就能够对每一组权限都生成各自对应的管控数据，可选地，由于在企业办公场景下，各种权限(如可见性权限、可搜性权限、可聊性权限等)相关联的数据记录是相同的，即都是目标对象内部门属性或者成员属性的数据记录，因此在对多种权限生成管控数据时，可仅对上述步骤301-302执行一次，后续过程中复用第一次得到的拓扑关系图即可，同理，也可以一次性输入所有权限的业务规则信息，从而只解析一次业务规则信息，在后续生成每种权限的位图的过程中，只需要筛选出与本权限相关联的业务规则信息解析得到的各个查询指令进行执行即可，本公开实施例对此不进行具体限定。
在一些实施例中，服务器对每种权限获取到管控数据之后，可在内存中缓存每种权限的管控数据(即缓存多张位图)，后续用户侧的请求如权限查询请求、资源访问请求等到达***时，可直接调用缓存的管控数据来响应用户侧的请求，从而达到权限计算与在线查询的解耦，避免了权限实时计算影响在线查询的响应速度。在下一实施例中，将对各种权限的管控数据的缓存方式进行详细说明，这里不做赘述。
本公开实施例提供的方法，通过将与权限关联的数据记录转储成对应的拓扑关系图，使得在生成该权限的管控数据时，将业务规则信息解析成查询操作之后，无需对数据记录执行复杂级联查询操作，而是能够直接对拓扑关系图即图数据执行相关的查询操作，从而大大提升了对管控数据的计算效率，打破了RBAC模型的局限性，能够适用于职务种类繁多、业务规则复杂的应用场景。
上述所有可选技术方案，可以采用任意结合形成本公开的可选实施例，在此不再一一赘述。
在上述实施例中，介绍了服务器如何生成每种权限各自的管控数据(以位图形式为例)，并且，为了使得权限计算和在线查询能够解耦，即完成对管控数据的读写分离效果，可将各种权限的各个管控数据存储在内存中，以支持***高QPS的读取操作，并尽可能保证对外提供权限查询服务的稳定性。可选地，将各种权限的各个管控数据存储在Redis(Remote Dictionary Server，远程字典服务)存储中间件中，通过Redis的高可用架构能够保证管控数据的高可用***，例如增加Sentinel主备架构组件、启用Proxy代理服务器或转为Cluster集群架构等，可根据具体业务性质来决定。
在一些实施例中，由于Redis是键值型存储的数据库架构，为了便于对外提供管控数据的查询服务，对每个子对象单独存储一个Key(键)，每个子对象的Key用于表征目标对象的名称、权限类型和子对象ID(或Index索引)，Key对应的Value则是当前子对象在该权限的位图中对应的Index索引所在行的一系列元素的取值集合，如图7所示，图7是本公开实施例提供的一种单个子对象的管控数据的存储格式的原理性示意图，在一个示例性中，Key为enterprise_name:contacts:visable:u1，代表子对象u1在其所属企业enterprise_name的通讯录下的可见性权限，Value为[1,0,0,0,…,1]是一个集合，集合中每个元素的取值代表子对象u1是否能够在通讯录中看到该元素位置的索引关联的另一子对象，例如，第1个元素取值为1，代表子对象u1能够在通讯录中看到子对象u1自身，第2个元素取值为0，代表子对象u1不能够在通讯录中看到子对象u2，以此类推，这里不做赘述。
在一些实施例中，如果将所有子对象对应的Key-Value形式的管控数据都集中到同一个计算设备(即计算节点)中计算，可能会导致在高峰期单个计算设备无法快速响应权限的计算服务，因此，可将生产者/消费者的设计模式迁移到本公开实施例中，用来加速权限计算。在生产者/消费者的设计模式下，按照子对象的Index索引对所有子对象进行分区，每个分区对应于一个消费者，每个消费者负责计算对应分区内子对象的权限的管控数据，如果消费者数量较多，每个分区所对应的索引范围可以设置得较小，比如[0,500]，[500,1000]，这样就可以利用足够的消费者数量增加并发处理能力。
从生产者角度来说，在接收到外部的权限计算请求时，对该权限计算请求解析得到一个全量计算任务，接着，将该全量计算任务分解为多个需要处理的计算子任务，每个计算子任务对应于一个分区，即，每个计算子任务用于指示本次计算需要处理单个分区内部哪些子对象的权限的管控数据。
从消费者角度来说，只需要负责处理生产者下发的计算子任务即可，在处理该计算子任务时，在对该计算子任务处理完毕后，可将计算得到的该分区内各个子对象的权限的管控数据更新到Redis存储中间件中，并且，通过消费者的横向扩容就能够进行无限扩展，即扩容时只需要增加分区，从而增加消费者即可，从而大大提升了***的对管控数据的计算效率。
示意性地，将生产者称为协调设备、消费者称为计算设备，在生产者/消费者架构下，协调设备负责将目标对象中的各个子对象划分为多个子对象集合，上述划分过程即是生产者的分区过程，可选地，由于每个子对象具有唯一性索引，可通过划分多个索引范围，从而将每个索引范围所对应的各个子对象确定为一个子对象集合(即一个分区)，此外，当接收到外部的权限计算请求时，协调设备还负责将该计算请求解析得到全局计算任务，再将该全局计算任务分解成多个计算子任务，每个计算子任务对应于一个分区即子对象集合。例如，假设目标对象内包括40000个子对象，协调设备按照Index索引将目标对象划分为如下的子对象集合：[0,1000]、[1000,2000]、…、[39000,40000]，接着，将权限计算请求解析得到的全局计算任务分解成40个子对象集合分别对应的40计算子任务，将这40个计算子任务发布写到Redis中，下游的40个计算设备监听到Redis发布的计算子任务后，以抢占的方式立即处理抢占到的计算子任务，例如，索引范围为[0,1000]的子对象集合的计算子任务，被计算设备1抢占到后，会由计算设备1来计算索引范围为[0,1000]的各个子对象的可见性权限、可搜性权限、可聊性权限等的管控数据(即位图)，以此类推，当***扩容时，增加了一个计算设备41，就能够进行扩展，减少权限计算请求的响应时间，例如，假设有40个分区，20个计算设备(消费者)，新增加一个计算设备之后，理论上能够将权限计算请求的响应时间从40/20缩短为40/21。
可选地，计算设备本地不负责存储对应子对象集合内所有子对象的各种权限的管控数据，而只是在接收到计算子任务后，从Redis存储中间件中拉取对应索引范围的图数据进行计算，本公开实施例对此不进行具体限定。
换言之，在将该目标对象的各个子对象划分为多个子对象集合之后，对该多个计算设备中的每个计算设备，从该多个子对象集合中确定未生成管控数据的任一子对象集合，比如，在监听到Redis中对每个子对象集合新发布的计算子任务后，每个计算设备以抢占的方式获取一个计算子任务，接着，在上述步骤304中基于拓扑关系图执行由业务规则信息解析得到的至少一个查询指令(NetQL原语)，得到了至少一个查询结果，每个计算设备在执行抢占到的计算子任务时，可基于该至少一个查询结果中与子对象集合对应的查询结果，生成该子对象集合对应的部分管控数据，其中，该子对象集合与计算设备抢占到的计算子任务相对应，该多个计算设备通过对多个计算子任务进行并行处理，能够并行生成多个部分管控数据，将该多个计算设备并行生成的各个部分管控数据合并得到最终的管控数据。
在一些实施例中，由于业务规则信息或者数据记录本身并非是一成不变的，而对目标对象内成员或部门的数据记录中任一字段的变更，或者对任一业务规则信息的变更，都会引起整体权限的管控数据的变更，因此当数据记录或业务规则信息发生变更之后，***需要重新全量一次各项权限的各个管控数据，也即按照最新的数据记录重新构建拓扑关系图，按照最新的业务规则信息解析出对应的各条查询指令，然后生成新的管控数据，与上述实施例中的各个步骤类似。由于在业务快速发展和迭代的场景下，***内的变更可能会较为频繁，如果每次变更都触发进行全量管控数据的计算，会使得***的资源利用率较低，计算开销较大，有鉴于此，可采用定时任务的轮询机制，即通过定时任务来周期性地拉取一定时间段内的所有变更，然后批量对管控数据进行全量计算，最终异步写到Redis存储中间件中进行管控数据的更新，从而在读写分离的基础上，进一步提高***的资源利用率，降低更新管控数据时的计算开销。
在一些实施例中，上述定时任务的轮询机制表示为：服务器每间隔目标时长，获取在该目标时长内接收到的与该权限关联的更新指令，该更新指令用于变更与该目标对象的权限关联的数据记录或业务规则信息中至少一项；基于该更新指令，更新该拓扑关系图；基于更新后的拓扑关系图，更新该权限的管控数据。其中，目标时长为任一大于0的数值。
可选地，服务器在接收到任一指令，解析出该指令为与该权限关联的更新指令之后，将该更新指令缓存到一个指令缓存区(例如等待队列)中，在定时任务触发轮询机制时，每间隔目标时长，都会从该指令缓存区中拉取从在该目标时长内缓存的所有更新指令，例如，每间隔目标时长从等待队列中拉取已缓存的所有更新指令，然后清空等待队列，接着基于该更新指令对数据记录或者业务规则信息中至少一项进行变更，基于与上述步骤301-302类似的方式重新构建出新的拓扑关系图；接着，在定时任务触发权限计算时，基于与上述步骤303-305类似的方式，解析最新变更得到的业务规则信息，得到各个查询指令，在新的拓扑关系图上执行各个查询指令，得到最终的各个查询结果，然后生成新的管控数据，并覆盖存储到Redis存储中间件中。
图8是本公开实施例提供的一种权限计算与存储的业务更新流程图，如图8所示，***管理员在配置权限规则时，通常会伴随写入对数据记录或业务规则信息(两者可统称为权限策略，例如为NetQL语句)的更新指令，在权限管理模块中，会将这些更新指令在MySQL数据库中进行持久化，相当于上述缓存到指令缓存区的过程。在定时任务Schedule模块中负责调度定时任务，定时任务可划分为两种类型，第一种定时任务用于周期性地从MySQL数据库中拉取更新指令并构建新的拓扑关系图，第二种定时任务用于周期性地根据最新的业务规则信息和最新的拓扑关系图，来计算新的管控数据，上述两种定时任务可设置不同的定时，例如，第一张定时任务的定时为10分钟，第二种定时任务的定时为20分钟，通过为两种定时任务设置不同的定时，能够将更新拓扑关系图和更新管控数据这两个步骤也进行解耦，转换为异步更新，能够进一步提升***的灵活性。
当定时任务Schedule模块触发第一种定时任务时，会从MySQL数据库中拉取从上一次拉取完毕后到本次拉取时刻这一时间段内缓存的各个更新指令，接着，针对涉及到变更数据记录的更新指令，对数据记录进行对应的变更，然后基于与上述步骤301-302类似的方式构建出新的拓扑关系图，当然也会相应的构建出新的哈希表中的各个集合(EntityNet)。
当定时任务Schedule模块触发第二种定时任务时，会从MySQL数据库中拉取从上一次拉取完毕后到本次拉取时刻这一时间段内缓存的各个更新指令，接着，针对涉及到变更业务规则信息的更新指令，对业务规则信息进行对应的变更，然后基于与上述步骤303-305类似的方式生成新的管控数据，接着在将新的管控数据更新到对应的Redis存储中间件中。
在上述基于Redis存储中间件提供在线查询服务的基础上，由于Redis存储中间件中会同步到最新的管控数据，并且Redis数据库本身具有高可用性，因此能够满足大部分情况下的在线查询需求，但为了进一步提升查询效率，可在Re dis基础上构建一个L2缓存区，将Redis层中最近的一段时间段(比如最近5分钟，或者最近10分钟)内访问过的Key-Value数据加载到L2缓存区中，并对L2缓存区中的Key-Value数据采取LRU(Least RecentlyUsed，最近最少使用)策略来进行内存管理，并限制L2缓存区中内存容量或Key的数量，从而提供一种Cache-Redis的二级缓存机制，以保证最快速度响应外部的在线查询需求。
在一些实施例中，用户侧的查询请求到达***之后，先从L2缓存区中查询是否命中Key-Value数据，如果命中则直接返回L2缓存区中缓存的Key-Value数据，如果未命中再继续到Redis存储中间件中进行查找，由于Redis存储中间件中缓存的全量的管控数据，因此通常情况下能够查找到对应的Key-Value数据。通常情况下L2缓存区的有效缓存时间较短，这是为了防止权限的管控数据变动之后，L2缓存区中陈旧的管控数据仍在提供服务这种情况的发生，因此，可将L2缓存区的有效缓存时间设置到小于管控数据的更新周期(即小于第二种定时任务的定时)，从而能够保证最终管控数据的数据一致性。
考虑到在小概率的情况下，Redis存储中间件可能会发生故障，因此，可提供一个L3层，L3层可提供一种所有子对象可见或者末级部门可见的兜底策略，按照子对象的属性值进行兜底，比如按照领导、人力资源管理者、一线员工、非一线员工等不同的属性值，提供不同的兜底策略，保证在Redis存储中间件宕机或故障时，能够通过L3层中的兜底策略来继续提供在线查询服务。即，此时提供一种Cache-Redis-L3的三级缓存机制。
在一些实施例中，可对所有的管控数据增加一个版本号的概念，换言之，服务器对初次获取的管控数据和每次更新所得的管控数据均分配版本号，其中，该版本号与该管控数据的生成时间戳呈单调递增，即，初次获取的管控数据的版本号最小，最新生成的管控数据的版本号最大，从而根据版本号的大小就能够直接判断出是否是最新版本的管控数据。在此基础上，如果用户侧的客户端(即应用程序)中保存了版本号，在下一次的权限查询请求中可添加客户端保存的版本号，这一服务器在接收到携带版本号的权限查询请求时，响应于任一权限查询请求或资源访问请求中携带版本号，可将权限查询请求或资源访问请求中携带的版本号与本地管控数据的最大版本号进行对比，在携带的版本号与该管控数据的最大版本号相同时，返回目标状态信息，该目标状态信息用于表征该管控数据无变化，例如，该目标状态信息是一个状态码，此时就无需进行管控数据的查询操作，能够大大节约服务器的计算资源，反之，在携带的版本号与该管控数据的最大版本号不同时，则需要查询上述涉及的Cache-Redis-L3的三级缓存机制，查找到最新的管控数据并返回给客户端。在上述过程中，相当于在Cache-Redis-L3的三级缓存机制上又增加了一级版本号的缓存机制，因此总体呈现出版本号-Cache-Redis-L3的四级缓存机制，能够大大提升服务器对权限查询请求的响应速度，并节约了客户端与服务器之间的网络带宽。
在一些实施例中，可在服务器中增加流控策略，来对接收权限查询请求的请求接口进行限流，防止由于流量突增导致在线查询的服务响应缓慢甚至不可用(即宕机)。
图9是本公开实施例提供的一种管控数据的在线服务架构示意图，如图9所示，假设***管控如下4类权限：成员可见性权限、成员可搜性权限、部门可见性权限和第三方应用的可见权限，在流量控制(限流)的机制下，服务器对外提供L3-Cache-Redis的多级缓存机制，并且以JSON(JavaScript Object Notation，JS对象简谱)树的格式存储企业内通讯录的组织架构，接着，缓存有全员可见和末级部门可见的两种兜底策略，可按照成员属性值的不同配置不同的兜底策略。此外，在Redis层中会实时更新各个Key-Value数据的版本号(即时间戳)，例如记录：u1-updatetime＝1，u2-updatetime＝2，代表子对象u1的最新版本号为1，子对象u2的最新版本号为2。此外，还可缓存有子对象ID和Index索引之间的映射关系，或者缓存子对象ID、账号ID和Index索引的三元映射关系，由于对成员和部门都需要分配Index索引，因此可分别记录成员的成员ID-成员索引的映射关系：如userid1-index1，userid2-index2等，以及部门的部门ID-部门索引的映射关系：如departmentid1-index1，departmentid2-index2等，以此类推。进一步的，对成员可见性权限、成员可搜性权限、部门可见性权限，分别记录3张位图即3种权限各自的管控数据。在最底层则是异步的离线权限计算任务，可参见图8中的异步计算管控数据并更新管控数据的描述，这里不做重复说明。
图10是本公开实施例提供的一种应用程序的交互界面示意图，如图10所示，在应用程序中展示该交互界面时，由于在该交互界面中涉及到显示通讯录信息，因此客户端需要通过可见性权限的管控数据，确定出当前可见的各个子对象(部门子对象或成员子对象)，只有满足可见性权限的部门子对象或成员子对象才能够被展示在交互界面中，从而保障了通讯录部门组织架构和成员联系人信息的数据安全性。
图11是本公开实施例提供的一种应用程序的交互界面示意图，如图11所示，当某一成员X在应用程序中发起对关键词“Y”的模糊搜索时，客户端需要通过可搜性权限的管控数据，确定出当前可搜的各个子对象(成员子对象或部门子对象)，只有满足可搜性权限且与关键词“Y”匹配的部门子对象或成员子对象才能够被展示在搜索结果页中，从而保障了通讯录部门组织架构和成员联系人信息的数据安全性。
在基于上述***框架，对***请求接口响应耗时进行测试的过程中，发现在高峰时期***的请求接口的响应耗时均处于180ms以下，说明当前对管控数据的在线查询服务能够支持足够的QPS，即说明当前***具有很高的查询请求和响应速度。
在上述各个实施例中所涉及的基于内存计算的通讯类应用的权限管理方案，能够应对需要对权限进行精细化控制的业务场景，达到子对象级别的细粒度管控，通过将数据记录格式转换为图数据格式，搭建出拓扑关系图，并提供一种用于操作拓扑关系图对应哈希表的集合的NetQL原语，能够适配于对拓扑关系图的各项查询操作，并且通过缓存生成的各种权限的管控数据，能够在线上对管控数据达到读写分离的效果，并且通过Redis存储中间件实现了高可用性，且基于生产者/消费者架构能够支持无限扩容，使得服务器对管控数据具有更高的计算效率，并且由于各种权限的管控数据都存储到Redis存储中间件中，通过多级缓存机制能够支撑对权限查询请求和资源访问请求更快的响应速度，此外，通过兜底策略进一步的提升了服务器的容错率，多级缓存机制能够节约通信开销和网络带宽，使得服务器具有更高的响应性能。
图12是根据一示例性实施例示出的一种权限信息的获取装置的逻辑结构框图。参照图12，该装置包括第一获取单元1201、构建单元1202以及第二获取单元1203。
第一获取单元1201，被配置为执行获取与目标对象的权限关联的至少一条数据记录；
构建单元1202，被配置为执行基于该至少一条数据记录，构建拓扑关系图，该拓扑关系图用于表征各条数据记录中属性名与属性值的关联关系；
第二获取单元1203，被配置为执行基于与该权限关联的业务规则信息和该拓扑关系图，获取该权限的管控数据，该管控数据用于提供对该权限所关联的资源的访问控制策略。
本公开实施例提供的装置，通过将与权限关联的数据记录转储成对应的拓扑关系图，使得在生成该权限的管控数据时，将业务规则信息解析成查询操作之后，无需对数据记录执行复杂级联查询操作，而是能够直接对拓扑关系图即图数据执行相关的查询操作，从而大大提升了对管控数据的计算效率，打破了RBAC模型的局限性，能够适用于职务种类繁多、业务规则复杂的应用场景。
在一种可能实施方式中，该至少一条数据记录中的每条数据记录对应于目标对象内的一个子对象，该子对象包括部门子对象或成员子对象中至少一项；
该拓扑关系图中包括多个节点，具有拓扑关系的不同节点之间通过有向边连接，其中，每个节点对应于一个子对象的一个属性值，每条有向边对应于所指向节点对应属性值的属性名。
在一种可能实施方式中，该构建单元1202被配置为执行：
基于每条数据记录中的各个属性值，构建该拓扑关系图中的各个节点；
基于每条数据记录中的各个属性名，构建该拓扑关系图中连接不同节点的各条有向边。
在一种可能实施方式中，基于图12的装置组成，该第二获取单元1203包括：
解析子单元，被配置为执行解析该业务规则信息，得到对该拓扑关系图的至少一个查询指令；
执行子单元，被配置为执行基于该拓扑关系图，执行该至少一个查询指令，得到至少一个查询结果；
生成子单元，被配置为执行基于该至少一个查询结果，生成该管控数据。
在一种可能实施方式中，该拓扑关系图以哈希表形式存储，其中，该哈希表中记录有多个集合，每个集合中存储有该拓扑关系图中的一个节点的属性值、接入该节点的有向边的属性名以及与该节点相连接的其他节点的属性值；
该执行子单元被配置为执行：
基于该至少一个查询指令，对该哈希表中的各个集合执行对应的处理操作，得到该至少一个查询结果。
在一种可能实施方式中，该执行子单元被配置为执行：
对每个查询指令，确定该查询指令所携带的目标属性值；
基于该哈希表中与该目标属性值对应的目标集合，获取该查询指令的查询结果，该目标集合用于表征具有该目标属性值的各个子对象。
在一种可能实施方式中，在该查询指令中携带多个该目标属性值的情况下，该执行子单元被配置为执行：
对多个该目标属性值对应的目标集合，执行与该查询指令的查询语义相匹配的处理操作，得到该查询指令的查询结果。
在一种可能实施方式中，该管控数据以位图形式存储，该位图中的每一个元素用于表征该元素所在行的索引是否对该元素所在列的索引具有该权限；
基于图12的装置组成，该生成子单元包括：
分配子子单元，被配置为执行对目标对象中的每个子对象分配对应的索引；
生成子子单元，被配置为执行基于该至少一个查询结果，对每个子对象关联的索引所在行和其他子对象关联的索引所在列所确定的元素进行赋值，以生成该位图。
在一种可能实施方式中，该目标对象的子对象包括下述至少一项：成员子对象、部门子对象或者与该目标对象关联的应用子对象；
该生成的位图包括下述至少一项：对应于该成员子对象的位图、对应于该成员子对象和该部门子对象的位图或者对应于该成员子对象和该应用子对象的位图。
在一种可能实施方式中，该分配子子单元被配置为执行：
对该目标对象中的每个成员子对象、部门子对象和与该目标对象关联的应用子对象均分配对应的索引；
该生成子子单元被配置为执行：
对每个成员子对象，基于该至少一个查询结果，对该成员子对象关联的索引所在行和其他子对象关联的索引所在列所确定的元素进行赋值，以生成该权限的第一位图、第二位图和第三位图；
其中，该第一位图中的每一行和每一列均对应于一个成员子对象，该第二位图中的每一行对应于一个成员子对象且每一列对应于一个部门子对象，该第三位图中每一行对应于一个成员子对象且每一列对应于一个应用子对象。
在一种可能实施方式中，该生成子子单元被配置为执行：
在该查询结果指示该子对象对任一其他子对象具有该权限时，在该位图中，将该元素赋值为1；
在该查询结果指示该子对象对任一其他子对象不具有该权限时，在该位图中，将该元素赋值为0。
在一种可能实施方式中，基于图12的装置组成，该装置还包括：
划分单元，被配置为执行将该目标对象中的各个子对象划分为多个子对象集合；
该生成子单元，被配置为执行：
对多个计算设备中的每个计算设备，从该多个子对象集合中确定未生成管控数据的任一子对象集合；
基于该至少一个查询结果中与该子对象集合对应的查询结果，生成该子对象集合对应的部分管控数据；
将该多个计算设备生成的各个部分管控数据合并得到该管控数据。
在一种可能实施方式中，基于图12的装置组成，该装置还包括：
第三获取单元，被配置为执行每间隔目标时长，获取在该目标时长内接收到的与该权限关联的更新指令，该更新指令用于变更与该目标对象的该权限关联的数据记录或业务规则信息中至少一项；
该构建单元1202，还被配置为执行基于该更新指令，更新该拓扑关系图；
该第二获取单元1203，还被配置为执行基于更新后的拓扑关系图，更新该权限的管控数据。
在一种可能实施方式中，基于图12的装置组成，该装置还包括：
分配单元，被配置为执行对初次获取的管控数据和每次更新所得的管控数据分配版本号，该版本号与该管控数据的生成时间戳呈单调递增；
返回单元，被配置为执行响应于任一权限查询请求中携带版本号，在携带的版本号与该管控数据的最大版本号相同时，返回目标状态信息，该目标状态信息用于表征该管控数据无变化。
上述所有可选技术方案，可以采用任意结合形成本公开的可选实施例，在此不再一一赘述。
关于上述实施例中的装置，其中各个单元执行操作的具体方式已经在有关该权限信息的获取方法的实施例中进行了详细描述，此处将不做详细阐述说明。
图13示出了本公开一个示例性实施例提供的一种计算机设备的结构框图，该计算机设备为终端或服务器，以计算机设备为终端1300为例进行说明。该终端1300可以是：智能手机、平板电脑、MP3播放器(Moving Picture Experts Group Audio Layer III，动态影像专家压缩标准音频层面3)、MP4(Moving Picture Experts Group Audio Layer IV，动态影像专家压缩标准音频层面4)播放器、笔记本电脑或台式电脑。终端1300还可能被称为用户设备、便携式终端、膝上型终端、台式终端等其他名称。
通常，终端1300包括有：处理器1301和存储器1302。
处理器1301可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器1301可以采用DSP(Digital Signal Processing，数字信号处理)、FPGA(Field－Programmable Gate Array，现场可编程门阵列)、PLA(Programmable Logic Array，可编程逻辑阵列)中的至少一种硬件形式来实现。处理器1301也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称CPU(Central ProcessingUnit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器1301可以在集成有GPU(Graphics Processing Unit，图像处理器)，GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器1301还可以包括AI(Artificial Intelligence，人工智能)处理器，该AI处理器用于处理有关机器学习的计算操作。
存储器1302可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器1302还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。在一些实施例中，存储器1302中的非暂态的计算机可读存储介质用于存储至少一个指令，该至少一个指令用于被处理器1301所执行以实现本公开中各个实施例提供的权限信息的获取方法。
在一些实施例中，终端1300还可选包括有：***设备接口1303和至少一个***设备。处理器1301、存储器1302和***设备接口1303之间可以通过总线或信号线相连。各个***设备可以通过总线、信号线或电路板与***设备接口1303相连。具体地，***设备包括：射频电路1304、触摸显示屏1305、摄像头组件1306、音频电路1307、定位组件1308和电源1309中的至少一种。
***设备接口1303可被用于将I/O(Input/Output，输入/输出)相关的至少一个***设备连接到处理器1301和存储器1302。在一些实施例中，处理器1301、存储器1302和***设备接口1303被集成在同一芯片或电路板上；在一些其他实施例中，处理器1301、存储器1302和***设备接口1303中的任意一个或两个可以在单独的芯片或电路板上实现，本实施例对此不加以限定。
射频电路1304用于接收和发射RF(Radio Frequency，射频)信号，也称电磁信号。射频电路1304通过电磁信号与通信网络以及其他通信设备进行通信。射频电路1304将电信号转换为电磁信号进行发送，或者，将接收到的电磁信号转换为电信号。可选地，射频电路1304包括：天线***、RF收发器、一个或多个放大器、调谐器、振荡器、数字信号处理器、编解码芯片组、用户身份模块卡等等。射频电路1304可以通过至少一种无线通信协议来与其它终端进行通信。该无线通信协议包括但不限于：城域网、各代移动通信网络(2G、3G、4G及5G)、无线局域网和/或WiFi(Wireless Fidelity，无线保真)网络。在一些实施例中，射频电路1304还可以包括NFC(Near Field Communication，近距离无线通信)有关的电路，本公开对此不加以限定。
显示屏1305用于显示UI(User Interface，用户界面)。该UI可以包括图形、文本、图标、视频及其它们的任意组合。当显示屏1305是触摸显示屏时，显示屏1305还具有采集在显示屏1305的表面或表面上方的触摸信号的能力。该触摸信号可以作为控制信号输入至处理器1301进行处理。此时，显示屏1305还可以用于提供虚拟按钮和/或虚拟键盘，也称软按钮和/或软键盘。在一些实施例中，显示屏1305可以为一个，设置终端1300的前面板；在另一些实施例中，显示屏1305可以为至少两个，分别设置在终端1300的不同表面或呈折叠设计；在再一些实施例中，显示屏1305可以是柔性显示屏，设置在终端1300的弯曲表面上或折叠面上。甚至，显示屏1305还可以设置成非矩形的不规则图形，也即异形屏。显示屏1305可以采用LCD(Liquid Crystal Display，液晶显示屏)、OLED(Organic Light-Emitting Diode,有机发光二极管)等材质制备。
摄像头组件1306用于采集图像或视频。可选地，摄像头组件1306包括前置摄像头和后置摄像头。通常，前置摄像头设置在终端的前面板，后置摄像头设置在终端的背面。在一些实施例中，后置摄像头为至少两个，分别为主摄像头、景深摄像头、广角摄像头、长焦摄像头中的任意一种，以实现主摄像头和景深摄像头融合实现背景虚化功能、主摄像头和广角摄像头融合实现全景拍摄以及VR(Virtual Reality，虚拟现实)拍摄功能或者其它融合拍摄功能。在一些实施例中，摄像头组件1306还可以包括闪光灯。闪光灯可以是单色温闪光灯，也可以是双色温闪光灯。双色温闪光灯是指暖光闪光灯和冷光闪光灯的组合，可以用于不同色温下的光线补偿。
音频电路1307可以包括麦克风和扬声器。麦克风用于采集用户及环境的声波，并将声波转换为电信号输入至处理器1301进行处理，或者输入至射频电路1304以实现语音通信。出于立体声采集或降噪的目的，麦克风可以为多个，分别设置在终端1300的不同部位。麦克风还可以是阵列麦克风或全向采集型麦克风。扬声器则用于将来自处理器1301或射频电路1304的电信号转换为声波。扬声器可以是传统的薄膜扬声器，也可以是压电陶瓷扬声器。当扬声器是压电陶瓷扬声器时，不仅可以将电信号转换为人类可听见的声波，也可以将电信号转换为人类听不见的声波以进行测距等用途。在一些实施例中，音频电路1307还可以包括耳机插孔。
定位组件1308用于定位终端1300的当前地理位置，以实现导航或LBS(LocationBased Service，基于位置的服务)。定位组件1308可以是基于美国的GPS(GlobalPositioning System，全球定位***)、中国的北斗***、俄罗斯的格雷纳斯***或欧盟的伽利略***的定位组件。
电源1309用于为终端1300中的各个组件进行供电。电源1309可以是交流电、直流电、一次性电池或可充电电池。当电源1309包括可充电电池时，该可充电电池可以支持有线充电或无线充电。该可充电电池还可以用于支持快充技术。
在一些实施例中，终端1300还包括有一个或多个传感器1310。该一个或多个传感器1310包括但不限于：加速度传感器1311、陀螺仪传感器1312、压力传感器1313、指纹传感器1314、光学传感器1315以及接近传感器1316。
加速度传感器1311可以检测以终端1300建立的坐标系的三个坐标轴上的加速度大小。比如，加速度传感器1311可以用于检测重力加速度在三个坐标轴上的分量。处理器1301可以根据加速度传感器1311采集的重力加速度信号，控制触摸显示屏1305以横向视图或纵向视图进行用户界面的显示。加速度传感器1311还可以用于游戏或者用户的运动数据的采集。
陀螺仪传感器1312可以检测终端1300的机体方向及转动角度，陀螺仪传感器1312可以与加速度传感器1311协同采集用户对终端1300的3D动作。处理器1301根据陀螺仪传感器1312采集的数据，可以实现如下功能：动作感应(比如根据用户的倾斜操作来改变UI)、拍摄时的图像稳定、游戏控制以及惯性导航。
压力传感器1313可以设置在终端1300的侧边框和/或触摸显示屏1305的下层。当压力传感器1313设置在终端1300的侧边框时，可以检测用户对终端1300的握持信号，由处理器1301根据压力传感器1313采集的握持信号进行左右手识别或快捷操作。当压力传感器1313设置在触摸显示屏1305的下层时，由处理器1301根据用户对触摸显示屏1305的压力操作，实现对UI界面上的可操作性控件进行控制。可操作性控件包括按钮控件、滚动条控件、图标控件、菜单控件中的至少一种。
指纹传感器1314用于采集用户的指纹，由处理器1301根据指纹传感器1314采集到的指纹识别用户的身份，或者，由指纹传感器1314根据采集到的指纹识别用户的身份。在识别出用户的身份为可信身份时，由处理器1301授权该用户执行相关的敏感操作，该敏感操作包括解锁屏幕、查看加密信息、下载软件、支付及更改设置等。指纹传感器1314可以被设置终端1300的正面、背面或侧面。当终端1300上设置有物理按键或厂商Logo时，指纹传感器1314可以与物理按键或厂商Logo集成在一起。
光学传感器1315用于采集环境光强度。在一个实施例中，处理器1301可以根据光学传感器1315采集的环境光强度，控制触摸显示屏1305的显示亮度。具体地，当环境光强度较高时，调高触摸显示屏1305的显示亮度；当环境光强度较低时，调低触摸显示屏1305的显示亮度。在另一个实施例中，处理器1301还可以根据光学传感器1315采集的环境光强度，动态调整摄像头组件1306的拍摄参数。
接近传感器1316，也称距离传感器，通常设置在终端1300的前面板。接近传感器1316用于采集用户与终端1300的正面之间的距离。在一个实施例中，当接近传感器1316检测到用户与终端1300的正面之间的距离逐渐变小时，由处理器1301控制触摸显示屏1305从亮屏状态切换为息屏状态；当接近传感器1316检测到用户与终端1300的正面之间的距离逐渐变大时，由处理器1301控制触摸显示屏1305从息屏状态切换为亮屏状态。
本领域技术人员可以理解，图13中示出的结构并不构成对终端1300的限定，可以包括比图示更多或更少的组件，或者组合某些组件，或者采用不同的组件布置。
图14是本公开实施例提供的一种计算机设备的结构示意图，该计算机设备1400可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器(CentralProcessing Units，CPU)1401和一个或一个以上的存储器1402，其中，该存储器1402中存储有至少一条程序代码，该至少一条程序代码由该处理器1401加载并执行以实现上述各个实施例提供的权限信息的获取方法。当然，该计算机设备1400还可以具有有线或无线网络接口、键盘以及输入输出接口等部件，以便进行输入输出，该计算机设备1400还可以包括其他用于实现设备功能的部件，在此不做赘述。
在示例性实施例中，还提供了一种包括至少一条指令的计算机可读存储介质，例如包括至少一条指令的存储器，上述至少一条指令可由计算机设备中的处理器执行以完成上述实施例中的权限信息的获取方法。可选地，上述计算机可读存储介质可以是非临时性计算机可读存储介质，例如，该非临时性计算机可读存储介质可以包括ROM(Read-OnlyMemory，只读存储器)、RAM(Random-Access Memory，随机存取存储器)、CD-ROM(CompactDisc Read-Only Memory，只读光盘)、磁带、软盘和光数据存储设备等。
在示例性实施例中，还提供了一种计算机程序产品，包括一条或多条指令，该一条或多条指令可以由计算机设备的处理器执行，以完成上述各个实施例提供的权限信息的获取方法。
本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。
应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (10)

1.一种权限信息的获取方法，其特征在于，包括：
获取与目标对象的权限关联的至少一条数据记录；
基于所述至少一条数据记录，构建拓扑关系图，所述拓扑关系图用于表征各条数据记录中属性名与属性值的关联关系；
基于与所述权限关联的业务规则信息和所述拓扑关系图，获取所述权限的管控数据，所述管控数据用于提供对所述权限所关联的资源的访问控制策略。
2.根据权利要求1所述的权限信息的获取方法，其特征在于，所述至少一条数据记录中的每条数据记录对应于目标对象内的一个子对象；
所述拓扑关系图中包括多个节点，具有拓扑关系的不同节点之间通过有向边连接，其中，每个节点对应于一个子对象的一个属性值，每条有向边对应于所指向节点对应属性值的属性名。
3.根据权利要求2所述的权限信息的获取方法，其特征在于，所述基于所述至少一条数据记录，构建拓扑关系图包括：
基于每条数据记录中的各个属性值，构建所述拓扑关系图中的各个节点；
基于每条数据记录中的各个属性名，构建所述拓扑关系图中连接不同节点的各条有向边。
4.根据权利要求1所述的权限信息的获取方法，其特征在于，所述基于与所述权限关联的业务规则信息和所述拓扑关系图，获取所述权限的管控数据包括：
解析所述业务规则信息，得到对所述拓扑关系图的至少一个查询指令；
基于所述拓扑关系图，执行所述至少一个查询指令，得到至少一个查询结果；
基于所述至少一个查询结果，生成所述管控数据。
5.根据权利要求4所述的权限信息的获取方法，其特征在于，所述拓扑关系图以哈希表形式存储，其中，所述哈希表中记录有多个集合，每个集合中存储有所述拓扑关系图中的一个节点的属性值、接入所述节点的有向边的属性名以及与所述节点相连接的其他节点的属性值；
所述基于所述拓扑关系图，执行所述至少一个查询指令，得到至少一个查询结果包括：
基于所述至少一个查询指令，对所述哈希表中的各个集合执行对应的处理操作，得到所述至少一个查询结果。
6.根据权利要求5所述的权限信息的获取方法，其特征在于，所述基于所述至少一个查询指令，对所述哈希表中的各个集合执行对应的处理操作，得到所述至少一个查询结果包括：
对每个查询指令，确定所述查询指令所携带的目标属性值；
基于所述哈希表中与所述目标属性值对应的目标集合，获取所述查询指令的查询结果，所述目标集合用于表征具有所述目标属性值的各个子对象。
7.一种权限信息的获取装置，其特征在于，包括：
第一获取单元，被配置为执行获取与目标对象的权限关联的至少一条数据记录；
构建单元，被配置为执行基于所述至少一条数据记录，构建拓扑关系图，所述拓扑关系图用于表征各条数据记录中属性名与属性值的关联关系；
第二获取单元，被配置为执行基于与所述权限关联的业务规则信息和所述拓扑关系图，获取所述权限的管控数据，所述管控数据用于提供对所述权限所关联的资源的访问控制策略。
8.一种计算机设备，其特征在于，包括：
一个或多个处理器；
用于存储所述一个或多个处理器可执行指令的一个或多个存储器；
其中，所述一个或多个处理器被配置为执行所述指令，以实现如权利要求1至权利要求6中任一项所述的权限信息的获取方法。
9.一种计算机可读存储介质，其特征在于，当所述计算机可读存储介质中的至少一条指令由计算机设备的一个或多个处理器执行时，使得所述计算机设备能够执行如权利要求1至权利要求6中任一项所述的权限信息的获取方法。
10.一种计算机程序产品，其特征在于，包括一条或多条指令，所述一条或多条指令由计算机设备的一个或多个处理器执行，使得所述计算机设备能够执行如权利要求1至权利要求6中任一项所述的权限信息的获取方法。
CN202111506120.5A 2021-12-10 2021-12-10 权限信息的获取方法、装置、计算机设备及存储介质 Active CN114244595B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111506120.5A CN114244595B (zh) 2021-12-10 2021-12-10 权限信息的获取方法、装置、计算机设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111506120.5A CN114244595B (zh) 2021-12-10 2021-12-10 权限信息的获取方法、装置、计算机设备及存储介质

Publications (2)

Publication Number Publication Date
CN114244595A true CN114244595A (zh) 2022-03-25
CN114244595B CN114244595B (zh) 2024-03-12

Family

ID=80754637

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111506120.5A Active CN114244595B (zh) 2021-12-10 2021-12-10 权限信息的获取方法、装置、计算机设备及存储介质

Country Status (1)

Country Link
CN (1) CN114244595B (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114416751A (zh) * 2022-03-29 2022-04-29 中建电子商务有限责任公司 一种基于倍增位图的rbac优化算法
CN115017875A (zh) * 2022-08-09 2022-09-06 建信金融科技有限责任公司 企业信息处理方法、装置、***、设备、介质和程序产品
CN115481158A (zh) * 2022-09-22 2022-12-16 北京泰策科技有限公司 一种数据分布式缓存自动加载与转换方法
CN115529157A (zh) * 2022-08-08 2022-12-27 北京雪诺科技有限公司 基于零信任的企业应用接入***、方法及访问***

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109087053A (zh) * 2018-06-01 2018-12-25 平安科技（深圳）有限公司 基于关联拓扑图的协同办公处理方法、装置、设备及介质
CN110168529A (zh) * 2017-08-03 2019-08-23 华为技术有限公司 数据存储方法、装置和存储介质
CN112100300A (zh) * 2020-08-22 2020-12-18 中国测绘科学研究院 矢量地表覆盖图斑空间拓扑关系快速构建方法及存储介质
CN112256698A (zh) * 2020-10-16 2021-01-22 美林数据技术股份有限公司 一种基于多哈希函数的表关系自动关联方法
CN112328712A (zh) * 2021-01-04 2021-02-05 清华四川能源互联网研究院 基于图数据库的权限管理方法、装置和电子设备
CN113127848A (zh) * 2019-12-31 2021-07-16 华为技术有限公司 一种权限***数据的存储方法及相关设备
CN113411253A (zh) * 2021-06-30 2021-09-17 平安普惠企业管理有限公司 基于邮件的关系拓扑分析方法、装置、终端设备及介质

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110168529A (zh) * 2017-08-03 2019-08-23 华为技术有限公司 数据存储方法、装置和存储介质
CN109087053A (zh) * 2018-06-01 2018-12-25 平安科技（深圳）有限公司 基于关联拓扑图的协同办公处理方法、装置、设备及介质
CN113127848A (zh) * 2019-12-31 2021-07-16 华为技术有限公司 一种权限***数据的存储方法及相关设备
CN112100300A (zh) * 2020-08-22 2020-12-18 中国测绘科学研究院 矢量地表覆盖图斑空间拓扑关系快速构建方法及存储介质
CN112256698A (zh) * 2020-10-16 2021-01-22 美林数据技术股份有限公司 一种基于多哈希函数的表关系自动关联方法
CN112328712A (zh) * 2021-01-04 2021-02-05 清华四川能源互联网研究院 基于图数据库的权限管理方法、装置和电子设备
CN113411253A (zh) * 2021-06-30 2021-09-17 平安普惠企业管理有限公司 基于邮件的关系拓扑分析方法、装置、终端设备及介质

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114416751A (zh) * 2022-03-29 2022-04-29 中建电子商务有限责任公司 一种基于倍增位图的rbac优化算法
CN115529157A (zh) * 2022-08-08 2022-12-27 北京雪诺科技有限公司 基于零信任的企业应用接入***、方法及访问***
CN115017875A (zh) * 2022-08-09 2022-09-06 建信金融科技有限责任公司 企业信息处理方法、装置、***、设备、介质和程序产品
CN115017875B (zh) * 2022-08-09 2022-11-25 建信金融科技有限责任公司 企业信息处理方法、装置、***、设备和介质
CN115481158A (zh) * 2022-09-22 2022-12-16 北京泰策科技有限公司 一种数据分布式缓存自动加载与转换方法

Also Published As

Publication number Publication date
CN114244595B (zh) 2024-03-12

Similar Documents

Publication Publication Date Title
CN114244595B (zh) 权限信息的获取方法、装置、计算机设备及存储介质
CN112463311B (zh) 事务处理方法、装置、计算机设备及存储介质
CN112035410B (zh) 日志存储方法、装置、节点设备及存储介质
CN107133309B (zh) 流程实例的存储、查询方法及装置、存储介质及电子设备
US11630851B2 (en) Systems and methods for providing predictions to applications executing on a computing device
CN115114344B (zh) 事务处理方法、装置、计算设备及存储介质
CN112162843A (zh) 工作流执行方法、装置、设备及存储介质
CN113742366B (zh) 数据处理方法、装置、计算机设备及存储介质
CN111897525A (zh) 大数据处理方法及***
WO2023124729A1 (zh) 查询数据的方法、装置、设备及存储介质
US11921726B2 (en) Logical partitions via header-based partition filtering
US11650830B2 (en) Techniques for modifying a compute instance
US20200042609A1 (en) Methods and systems for searching directory access groups
CN113704361B (zh) 事务执行方法、装置、计算设备及存储介质
CN116561137A (zh) 事务处理方法、装置、计算机设备及存储介质
CN117321581A (zh) 用于加速sql查询的确定性分布式高速缓存的技术
CN110995842A (zh) 业务数据下载方法、装置、设备及存储介质
CN115098537B (zh) 事务执行方法、装置、计算设备及存储介质
CN115113989B (zh) 事务执行方法、装置、计算设备及存储介质
US11687568B2 (en) Data catalog system for generating synthetic datasets
CN115495169A (zh) 数据获取、页面生成方法、装置、设备及可读存储介质
CN116244299A (zh) 业务数据路径的确定方法、装置、电子设备及介质
CN114385723A (zh) 数据读取方法、装置、电子设备及存储介质
CN113138771B (zh) 数据处理方法、装置、设备及存储介质
CN112783860B (zh) 构造镜像数据库的方法、装置、存储介质及计算机设备

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant