API permission management method and apparatus for service system, and device and storage medium

Abstract

The embodiments of the present application relate to the technical field of computers. Provided are an API permission management method and apparatus for a service system, and a device and a storage medium. The method comprises: recording a first correspondence between an identifier of a first service API, which is associated with a first service page, and an identifier of a first item; acquiring a first calling request; and on the basis of the identifier of the first service API and the identifier of the first item that are carried in the first calling request, and the first correspondence, allowing the first calling request to access a service corresponding to the first service API. Compared with a method in which whether a user has the permission to an API is determined, the embodiments of the present application distinguish, by means of identifiers of items, an item to which the API belongs. Permission management over a service API is performed from two aspects, i.e., an item to which the service API belongs, and an identifier of the service API, thereby improving the reliability of API permission management. Therefore, a network security problem caused by unauthorized item permission is avoided.

Description

API permission management method, device, equipment and storage medium for business system

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on April 2, 2024, with application number 202410396506.2 and application name “API permission management method, device, equipment and storage medium for business system”, and claims priority to the Chinese patent application filed with the State Intellectual Property Office on January 11, 2024, with application number 202410043980.7 and application name “An interface management method, system, equipment and storage medium”, all contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of computer technology, and more specifically to a method, apparatus, device, and storage medium for managing API permissions in a business system. Background Art

[0003] With the development of Internet technology, more and more business processes have been digitized. For example, business systems based on cloud systems provide multiple services. Currently, different permissions can be set for different users to control different users' access to different services in the business system and ensure the data security of the business system. Typically, various services in a business system provide application programming interfaces (APIs), which can be accessed by calling the service API. By setting permissions for multiple APIs for users, users can access different services in the business system. However, the APIs between different services in the business system are nested. By verifying API permissions to control user access to different services in the business system, it is possible that users may access services that they do not have permission to access. This can result in unauthorized access to services and reduce the network security of the business system.

[0004] Summary of the Invention

[0005] The embodiments of the present application provide a method, apparatus, device, and storage medium for managing API permissions in a business system to improve network security issues caused by exceeding API permissions.

[0006] In the first aspect, an embodiment of the present application provides an API permission management method for a business system. The method publishes a first business page associated with a first matter, wherein the first business page is associated with a first service API. By recording a first correspondence between an identifier of the first service API and an identifier of the first matter. After obtaining a first call request for the first service API, when the first call request carries the identifier of the first service API and the identifier of the first matter, the first call request is allowed to access the service corresponding to the first service API based on the identifier of the first service API and the identifier of the first matter carried by the first call request, and the first correspondence.

[0007] Compared with the method of controlling access to the business system by judging whether the user has the permission of the API, the permission settings of the same API in different businesses are the same, and there is a risk of unauthorized access by the business. In the embodiment of the present application, the service API is associated with the matter to which it belongs by recording the correspondence between the identifier of the service API associated with the business page and the identifier of the matter. In this way, the matter to which the API belongs is distinguished by the identifier of the matter in the call request of the service API. Moreover, the embodiment of the present application manages the permissions of the service API from two aspects: the access rights of the matter to which the service API belongs and the identifier of the service API, by combining the identifier of the service API and the identifier of the matter. In this way, the reliability of API permission management is improved. Network security issues caused by unauthorized access to matters are avoided.

[0008] In one possible implementation, the first business page is associated with a second service API. A second correspondence between the identifier of the second service API and the identifier of the first matter is recorded. A second call request for the second service API is obtained. When the second call request carries the identifier of the second service API and the identifier of the first matter, the second call request is allowed to access the service corresponding to the second service API based on the identifier of the second service API and the identifier of the first matter carried in the second call request and the second correspondence.

[0009] Based on this possible implementation, when a business page is associated with multiple service APIs, the business system establishes a corresponding relationship between each service API associated with the business page and the identifier of the matter associated with the business page. Upon receiving a call request for a business page associated with multiple service APIs, if the call request carries the identifier of the matter associated with the business page, the call request is allowed to access the service corresponding to the service API. This enables refined management of API permissions.

[0010] In one possible implementation, the method specifically includes obtaining a third call request for a first service API. When the third call request carries the identifier of the first service API but does not carry the identifier of the first matter, denying the third call request access to the service corresponding to the first service API based on the identifier of the first service API carried in the third call request and the first correspondence.

[0011] In this way, the reliability of API permission management is ensured through the identification of the first matter, avoiding network security issues caused by exceeding the permission of the matter.

[0012] In one possible implementation, a second business page associated with a second matter is published. The second business page is associated with a first service API. A third correspondence between the identifier of the first service API and the identifier of the second matter is recorded. A fourth call request for the first service API is obtained. When the fourth call request carries the identifier of the first service API and the identifier of the second matter, the first call request is allowed to access the service corresponding to the first service API based on the identifier of the first service API and the identifier of the second matter carried in the fourth call request, as well as the third correspondence.

[0013] Because service APIs for different items overlap, the same service API may be associated with multiple item-related business pages. Based on this possible implementation, for each item, a correspondence is established between the item's identifier and the service API associated with that item's business page. This allows the business system to distinguish the items to which service APIs belong based on these correspondences, avoiding the risk of unauthorized access to items through the construction of service APIs when service APIs for different items overlap.

[0014] In one possible implementation, the method specifically includes obtaining a fourth call request for the first service API. When the fourth call request carries the identifier of the first service API but does not carry the identifier of the second matter, denying the fourth call request access to the service corresponding to the first service API based on the identifier of the first service API carried in the fourth call request and the third correspondence relationship and the first correspondence relationship.

[0015] Based on this possible implementation, when the fourth call request carries the identifier of the first service API but does not carry the identifier of the second matter, the business system denies the fourth call request access to the service corresponding to the first service API based on the identifier of the first service API carried in the fourth call request, as well as the third correspondence and the first correspondence. In this way, the matters to which the service APIs belong are distinguished based on the correspondences under different matters, avoiding the risk of unauthorized access to matters by constructing service APIs when there are overlapping service APIs for different matters.

[0016] In a possible implementation, the specific implementation is: the first service API and / or the second service API are set in the first business page, or are set in a page with the first business page as the parent page.

[0017] In this way, a correspondence is established between each service API associated with the business page and the identifier of the matter associated with the business page, thereby achieving refined management of API permissions.

[0018] In one possible implementation, recording a first correspondence between an identifier of a first service API and an identifier of a first matter is specifically implemented as follows: creating a first business session for the first matter; generating an identifier of the first matter in the first business session, associating the identifier of the first service API with the identifier of the first matter, and establishing a first correspondence.

[0019] In this way, the service API's item identifier is dynamically generated when the user accesses the first item's business session. Compared to static API permissions, this allows for a more refined distinction between the item to which the API belongs and the item's business session, preventing item permissions from being exceeded when there is overlap between the APIs associated with the item.

[0020] In one possible implementation, the first call request carries a user role. When the first correspondence includes the identifier of the first service API and the identifier of the first matter, the identifier of the first matter is included in the first business session of the first matter, and the first service API is in the set of API permissions allowed by the user role, the first call request is allowed to access the service corresponding to the first service API.

[0021] Since the business session created by the business system when the user accesses the first matter is temporary and time-limited, and it takes time for an attacker to intercept the first corresponding relationship in the business system and construct the first call request message of the first service API based on the first corresponding relationship. The attacker may send the first call request of the first service API to the business system after the business system closes the business session of the first matter. Therefore, in this possible implementation method, a judgment is added on whether the first business session of the first matter contains the identifier of the first matter. By taking advantage of the temporary and time-limited characteristics of the business session and identifying whether the API indicated by the first session identifier matches the API associated with the target business, the reliability of the API permission verification is improved, thereby ensuring the network security of the business system.

[0022] In one possible implementation, the specific implementation is as follows: the first business page is associated with the second service API. After allowing the first call request to access the service corresponding to the first service API based on the identifier of the first service API and the identifier of the first matter carried in the first call request, and the first correspondence, the mapping value of the keyword of the first matter is published, and the mapping value of the keyword is sent to the client corresponding to the first call request. A second call request for the second service API is obtained. The second call request carries the identifier of the second service API, the identifier of the first matter, and the first mapping value. The second call request is allowed to access the service corresponding to the second service API based on the identifier of the second service API, the first mapping value, the identifier of the first matter carried in the second call request, and the second correspondence. The second correspondence is used to indicate the correspondence between the identifier of the second service API and the identifier of the first matter.

[0023] When the attacker constructs a message that includes the first service API permission verification, if the attacker directly responds to the first call request of the first service API, there may be a risk of unauthorized access to the matter. Therefore, in this possible implementation method, the business system publishes the mapping value of the keyword of the first matter after allowing the first call request to access the service corresponding to the first service API. When the API call request is obtained, the call request is managed for permissions based on the identifier of the matter carried in the call request, the identifier of the service API, and the mapping value. In this way, the reliability of the API permission management of the business system is further improved by increasing the mapping value. This improves the network security of the business system.

[0024] In one possible implementation, the specific implementation is: before publishing the first business page associated with the first matter, set the access rights of multiple roles to multiple matters provided by the business system; based on the access rights of multiple roles to multiple matters, set the access rights of at least one API associated with the multiple matters, and obtain the API call permission set corresponding to the role.

[0025] Because in the related art, by allocating permissions to each API in the business system, according to the business that each role needs to access and the API associated with the business, the API permissions of each role are allocated, and the roles and API permissions are associated to form an API call permission set for each role. There are problems with the difficulty of allocating API permissions and the large amount of data. In this possible implementation method, based on the various matters provided by the business system and the API associated with each matter, by allocating access permissions to each matter and setting the access permissions of the API associated with each matter, an API call permission set is obtained. In this way, APIs are grouped based on matters, and API access permissions are set based on the access permissions of matters. Compared with directly allocating permissions to APIs, the amount of data can be reduced. And based on matters, the difficulty of maintaining and allocating permissions is reduced.

[0026] In one possible implementation, access permissions for at least one API associated with multiple matters are set based on the access permissions of multiple roles to multiple matters. Specifically, the implementation is as follows: based on multiple matters provided by the business system, the trigger component of each matter, and the association between the trigger component and the business page, the association relationship between each matter and the business page is obtained; based on the API associated with each business page and the association between each matter and the business page, at least one API associated with each matter is obtained; based on the role's access permissions to multiple matters and at least one API associated with each matter, the access permissions for at least one API associated with each matter are set.

[0027] Based on this possible implementation, APIs can be grouped by project, and access permissions can be set based on the business's access rights. This can reduce the amount of data required compared to directly assigning permissions to APIs. Furthermore, using business as the unit reduces the difficulty of maintaining and assigning permissions.

[0028] In the second aspect, an embodiment of the present application provides an API permission management device for a business system. The API permission management device for the business system can be a computing device cluster that executes the API permission management method for the business system, or a chip or system on chip in the computing device cluster. The API permission management device for the business system can implement the functional modules of the method in the above-mentioned first aspect or any possible implementation of the first aspect. The API permission management device for the business system can implement the functions performed by the computing device in the above-mentioned first aspect or any possible implementation of the first aspect, and the functional modules can be implemented by hardware executing the corresponding software. The hardware or software includes one or more modules corresponding to the above-mentioned functions, such as a business module, a configuration module, an acquisition module and a permission module.

[0029] The business module is configured to publish a first business page associated with the first matter, wherein the first business page is associated with a first service API.

[0030] The configuration module is used to record a first correspondence between the identifier of the first service API and the identifier of the first matter.

[0031] The acquisition module is configured to acquire a first call request for a first service API, wherein the first call request carries an identifier of the first service API and an identifier of the first matter.

[0032] The permission module is used to allow the first calling request to access the service corresponding to the first service API according to the identifier of the first service API and the identifier of the first matter carried by the first calling request, and the first corresponding relationship.

[0033] In a possible implementation, the first business page is associated with a second service API, and the configuration module is further configured to record a second correspondence between an identifier of the second service API and an identifier of the first matter.

[0034] The acquisition module is further configured to acquire a second call request for the second service API, wherein the second call request carries an identifier of the second service API and an identifier of the first matter.

[0035] The permission module is further configured to allow the second calling request to access the service corresponding to the second service API according to the identifier of the second service API and the identifier of the first matter carried in the second calling request, and the second corresponding relationship.

[0036] In a possible implementation, the acquisition module is further configured to acquire a third call request for the first service API, wherein the third call request carries the identifier of the first service API and does not carry the identifier of the first matter.

[0037] The permission module is further configured to deny the third calling request from accessing the service corresponding to the first service API according to the identifier of the first service API carried in the third calling request and the first corresponding relationship.

[0038] In a possible implementation, the specific implementation is: the business module is further used to publish a second business page associated with the second matter, and the second business page is associated with the first service API.

[0039] The configuration module is further configured to record a third correspondence between the identifier of the first service API and the identifier of the second item.

[0040] The acquisition module is further configured to acquire a fourth call request for the first service API, wherein the fourth call request carries an identifier of the first service API and an identifier of the second matter.

[0041] The permission module is further used to allow the first calling request to access the service corresponding to the first service API based on the identifier of the first service API and the identifier of the second matter carried by the fourth calling request, and the third corresponding relationship.

[0042] In a possible implementation, the specific implementation is as follows: the acquisition module is further configured to acquire a fourth call request for the first service API, wherein the fourth call request carries the identifier of the first service API and does not carry the identifier of the second matter.

[0043] The permission module is further configured to deny the fourth calling request from accessing the service corresponding to the first service API according to the identifier of the first service API carried in the fourth calling request, the third corresponding relationship, and the first corresponding relationship.

[0044] In one possible implementation, the first service API and the second service API associated with the first business page published by the business module are specifically implemented as follows: the first service API and / or the second service API are set in the first business page, or in a page with the first business page as the parent page.

[0045] In a possible implementation, the configuration module is configured to create a first business session for the first matter, generate an identifier of the first matter in the first business session, and associate the identifier of the first service API with the identifier of the first matter to establish a first corresponding relationship.

[0046] In one possible implementation, the first call request acquired by the acquisition module carries the user role. The acquisition module is further configured to allow the first call request to access the service corresponding to the first service API when the first correspondence includes the identifier of the first service API and the identifier of the first matter, the identifier of the first matter is included in the first business session of the first matter, and the first service API is in a set of API permissions allowed to be accessed by the user role.

[0047] In one possible implementation, the first business page published by the business module is associated with the second service API. The business module is further configured to publish a mapping value of a keyword of the first matter and send the mapping value of the keyword to the client corresponding to the first call request.

[0048] The acquisition module is further used to obtain a second call request for the second service API, wherein the second call request carries the identifier of the second service API, the identifier of the first matter and the first mapping value.

[0049] The permission module is further configured to allow the second call request to access the service corresponding to the second service API based on the identifier of the second service API carried in the second call request, the first mapping value, the identifier of the first matter, and the second corresponding relationship, wherein the second corresponding relationship is used to indicate the corresponding relationship between the identifier of the second service API and the identifier of the first matter.

[0050] In one possible implementation, the configuration module is further configured to set access permissions for multiple roles to multiple items provided by the business system. Based on the access permissions for the multiple roles to the multiple items, access permissions for at least one API associated with the multiple items are set to obtain a set of API call permissions corresponding to the roles.

[0051] In one possible implementation, when the configuration module sets access permissions for at least one API associated with multiple matters based on the access permissions of multiple roles to multiple matters, the configuration module is specifically implemented as follows: the configuration module is further used to obtain the association relationship between each matter and the business page based on the multiple matters provided by the business system, the trigger component of each matter, and the association relationship between the trigger component and the business page. Based on the APIs associated with each business page and the association relationship between each matter and the business page, at least one API associated with each matter is obtained. Based on the access permissions of the roles to the multiple matters and the at least one API associated with each matter, the access permissions for the at least one API associated with each matter are set.

[0052] In a third aspect, embodiments of the present application provide a computing device cluster, comprising at least one computing device. Each computing device includes a processor and a memory. The processor of at least one computing device is configured to execute instructions stored in the memory of at least one computing device, causing the computing device cluster to perform the method described in the first aspect or any possible implementation of the first aspect.

[0053] In a fourth aspect, embodiments of the present application provide a computer-readable storage medium that summarizes computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster executes the computer program instructions stored in the computer-readable storage medium to perform the method of the first aspect or any possible implementation of the first aspect.

[0054] In a fifth aspect, embodiments of the present application provide a computer program product that, when executed by a computing device or a computing device cluster, causes the computing device cluster to execute the method in the first aspect or any possible implementation of the first aspect.

[0055] The technical effects brought about by any implementation method from the second aspect to the fifth aspect can be referred to the technical effects brought about from the first aspect to the first aspect or different implementation methods, and will not be repeated here.

[0056] Based on the implementation methods provided in the above aspects, this application can be further combined to provide more implementation methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0057] Figure 1 is a schematic diagram of a business system providing different services to different personnel;

[0058] FIG2 is a schematic diagram of API permission configuration in related art;

[0059] FIG3 is a schematic diagram of API permission verification in related art;

[0060] FIG4 is a schematic diagram of an application scenario of the API permission management method for a business system provided in an embodiment of the present application;

[0061] FIG5 is a schematic diagram of a business system flow according to an embodiment of the present application;

[0062] FIG6 is a schematic diagram of the process of API permission management of the business system provided in an embodiment of the present application;

[0063] FIG7 is a schematic diagram of a process for allocating API call permissions according to an embodiment of the present application;

[0064] FIG8 is a schematic diagram of a process for configuring API call permissions according to an embodiment of the present application;

[0065] FIG9 is a schematic diagram of the association relationship between the trigger control and the business page provided in an embodiment of the present application;

[0066] FIG10 is a schematic diagram of keyword mapping provided in an embodiment of the present application;

[0067] FIG11 is a schematic diagram of an event query operation interface provided in an embodiment of the present application;

[0068] FIG12 is a schematic diagram of an event submission operation interface provided in an embodiment of the present application;

[0069] FIG13 is a schematic diagram of the structure of a business system provided in an embodiment of the present application;

[0070] FIG14 is a schematic diagram of the structure of an API authority management device of a business system provided in an embodiment of the present application;

[0071] FIG15 is a schematic diagram of the structure of an API rights management system of a business system provided in an embodiment of the present application;

[0072] FIG16 is a schematic diagram of the structure of a computing device provided in an embodiment of the present application;

[0073] FIG17 is a schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application;

[0074] FIG18 is a schematic diagram of network connections between computing devices in a computing device cluster provided in an embodiment of the present application. DETAILED DESCRIPTION

[0075] Business systems have multiple types of personnel accessing them. Each type of personnel has access to different businesses, and accordingly, each person has different access rights to the business system. As shown in Figure 1, business system A provides services S1, S2, S3, and S4. The personnel accessing business system A include the first, second, third, and fourth categories of personnel. Specifically, the first category of personnel can access services S1 and S4. The second category of personnel can access service S2. The third category of personnel can access service S3. The fourth category of personnel can access services S1, S2, S3, and S4. Accordingly, the access rights of the first category of personnel, the second category of personnel, the third category of personnel, and the fourth category of personnel to business system A are (S1, S4), (S2), (S3), and (S1, S2, S3, S4), respectively.

[0076] Business systems primarily implement different business functions by calling different APIs. Because each person has access to different businesses, their permissions to call the service APIs within the business system also vary. To manage user access rights to the system, you need to assign roles to each person and set corresponding API call permissions for each role.

[0077] Currently, related technologies primarily assign permissions to each API in a business system. Based on the business each role needs to access and the APIs associated with those businesses, the permissions for each role are assigned, and the roles and API permissions are associated to form an API call permission set for each role. For example, taking business S1 in a business system as an example, which includes n service APIs, as shown in Figure 2, when the permissions for the n service APIs are set to Permission-1, Permission-2, ..., Permission-n, respectively, if the permissions for the service APIs for role 1 are Permission-1, Permission-2, ..., Permission-n, then the user for role J01 has access to service API-1, service API-2, ..., service API-n.

[0078] When a user accesses a business system, the business system determines which service APIs the user has access to based on the API call permission set for the user's role. If the service API the user requests to call is one to which the user has access, the business system allows access. If the service API the user requests to call is not one to which the user has access, the business system denies access. As shown in Figure 3, if the API call permission set for the user's role includes permission-k for service API-SK but not permission-n for service API-n, the user is allowed access to service API-SK but denied access to service API-n.

[0079] As described in the background technology, current business systems mainly control whether users can access the API by determining whether they have API permissions, thereby achieving controlled access to the business system. Because the API permission setting is globally unique, that is, the same API has the same permissions in different businesses. Moreover, when verifying API permissions, it only verifies whether the user has API permissions. When there is overlap in the APIs associated with the business, an attacker can directly construct an API message and overlay the API to which a user has access rights, thereby accessing the business that the user does not have access rights. It can be seen that the relevant technology has the hidden danger of unauthorized access to the business. This will reduce the network security of the business system.

[0080] For example, as shown in Table 1, Service 1 is associated with API-1 and API-2. Service 2 is associated with API-1 and API-3. Service 3 is associated with API-1, API-2, and API-3. If a user is allowed access to Services 1 and 2 but is prohibited from accessing Service 3, the user has permissions for API-1, API-2, and API-3. By constructing messages for API-1, API-2, and API-3, the user can access Service 3, resulting in unauthorized access to Service 3.

[0081] Table 1 Business-related API examples

[0082] Based on this, to address the issue of unauthorized business access and improve the network security of business systems, an embodiment of the present application provides a method for managing API permissions in a business system. In this method, after publishing a business page associated with an issue provided by the business system, the corresponding relationship between the identifier of the service API associated with the business page and the identifier of the issue is recorded. Upon receiving a service API call request, if the service API call request carries both the service API identifier and the issue identifier, the service API call request is allowed to access the service corresponding to the service API based on the service API identifier and the issue identifier carried in the service API call request, as well as the corresponding relationship. Compared to methods that control access to business systems by determining whether a user has API permissions, permissions for the same API may be the same for different businesses, posing the risk of unauthorized business access. In this embodiment, a service API is associated with the issue to which it belongs by recording the corresponding relationship between the identifier of the service API associated with the business page and the identifier of the issue. Thus, the issue to which the API belongs is distinguished by the issue identifier in the service API call request. Furthermore, this embodiment combines the service API identifier and the issue identifier to manage service API permissions from two perspectives: access rights to the issue to which the service API belongs, and the service API identifier. This improves the reliability of API permission management and avoids network security issues caused by exceeding authority.

[0083] It should be noted that the API permission management method for the business system provided in the embodiments of this application can be applied to business scenarios based on cloud computing. For example, it can be applied to cloud computing-based retrieval business scenarios, financial business scenarios, medical business scenarios, educational business scenarios, audio business scenarios, and software development business scenarios. This embodiment of the application is not limited to this. The API permission management method for the business system provided in the embodiments of this application can also be applied to other business scenarios other than cloud computing.

[0084] When the API permission management method for a business system provided in an embodiment of the present application is applied to a cloud computing-based business scenario, the business system is deployed in the cloud. Clients access the business system via the network. The business system provides business functions to the client. When the business system is deployed in the cloud, the business system can be referred to as a cloud system.

[0085] When the API permission management method for the business system provided in the embodiment of the present application is applied to other business scenarios other than cloud computing, the business system is deployed in a local computing device, and the user interacts with the business system through the interface of the local computing device.

[0086] Exemplarily, taking the cloud computing-based retrieval business scenario as an example, the application scenario of the API permission management method of the business system provided by the embodiment of the present application is introduced. As shown in Figure 4, Figure 4 is an application scenario of the API permission management method of the business system provided by the embodiment of the present application. The application scenario shown includes a client 20, a business system 10 and a network 30. The client 20 interacts with the business system 10 through the network 30. For example, the client 20 logs in to the business system 10. For another example, the client 20 requests the business system 10 to call an API.

[0087] Among them, the business system 10 provides a variety of services to the client 20. For example, the business system 10 provides retrieval services, query services, output services, input services, etc. The embodiment of the present application is not limited to this. Each business is used for different matters. The business page associated with each matter is associated with at least one API. The business system 10 implements the business functions of the business by calling at least one API associated with the business page. For example, when business A is a query business, the business page associated with the matter of business A is associated with a query API, a read API, and an output API. The business system 10 implements the business query matter by calling the query API, the read API, and the output API.

[0088] In an embodiment of the present application, the client 20 sends a service API call request to the business system 10, the business system 10 receives the service API call request sent by the client 20, executes the API permission management method of the business system provided in the embodiment of the present application, and determines whether the service API call request is allowed to access the service corresponding to the service API.

[0089] In a first possible implementation, as shown in FIG4 , the service system 10 includes an access layer 101 , a processing layer 102 , and a resource layer 103 .

[0090] The access layer 101 receives service API call requests from clients. The processing layer 102 provides the services corresponding to the service APIs. The resource layer 103 provides the computing, storage, and network resources required by the business system. For example, it stores search terms, search results, and databases in search business scenarios.

[0091] The processing layer 102 includes a processing module 1021 .

[0092] Among them, an access gateway 1011 is deployed in the access layer 101.

[0093] In one example, the access gateway 1011 is used to receive a service API call request sent by a client, run the API permission management method of the business system provided by the embodiment of the present application, and forward the service API call request to the processing layer 102 when allowing the service API call request to access the service corresponding to the service API.

[0094] In another example, access gateway 1011 is configured to receive a service API call request from a client and pass the API request to processing layer 102. Processing module 1021 in processing layer 102 executes the API permission management method for the business system provided in an embodiment of the present application. When the service API call request is allowed to access the service corresponding to the service API, processing module 1021 in processing layer 102 provides the service corresponding to the service API.

[0095] It should be noted that Figure 4 is only an illustrative figure and does not constitute a limitation on the API permission management method for the business system provided in the embodiment of the present application. In actual application scenarios, the API permission management method for the business system can be applied to other business scenarios, such as financial business scenarios, medical business scenarios, educational business scenarios, audio business scenarios, and software development business scenarios. In addition, the naming and grouping of the business system in Figure 4 are schematic, which is only a logical function grouping. There may be other grouping methods in actual implementation. For example, the business system can also be divided into a permission control module and an API processing module. Specifically, another division example can refer to the example corresponding to Figure 13 below. In addition, the business system can also be named as the API permission management device of the business system. The API permission management device of the business system may include modules different from those shown in the cloud server in Figure 4. The API permission management device of the business system can refer to the embodiment corresponding to Figure 14 below, and the embodiment of the present application will not be elaborated here.

[0096] Based on the application scenario provided in Figure 4, the embodiment of the present application provides an API permission management method for a business system. The following describes the API permission management method for a business system in the embodiment of the present application in conjunction with specific embodiments.

[0097] In an embodiment of the present application, as shown in FIG5 , the business system provides a variety of matters to the client. The client sends a matter access request for a first matter to the business system (S51). The business system publishes a first business page associated with the first matter (S52). The business system records a first correspondence between the identifier of the first service API associated with the first business page and the identifier of the first matter. The client sends a call request carrying the identifier of the first service API and the identifier of the first matter to the business system (S53). The business system performs permission verification on the first service API requested to be called by the client based on the identifier of the first service API and the identifier of the matter carried in the call request and the first correspondence (S54).

[0098] As shown in FIG6 , FIG6 is a flow chart of the API permission management method for a business system provided in an embodiment of the present application. The API permission management method for a business system shown includes steps S610 to S650 .

[0099] S610: Obtain a matter access request for the first matter.

[0100] The service access request includes a matter identifier, wherein the matter identifier is used to indicate any one of multiple matters provided by the service system.

[0101] In a first possible implementation manner, the business system obtains a matter access request for a first matter input by a user through an interface of the business system.

[0102] In a second possible implementation manner, the business system obtains a matter access request for the first matter sent by the client.

[0103] In one example, the client may send an event access request to the business system by clicking a trigger component of an event in a business system interface displayed on the client.

[0104] In another example, the client may directly send a matter access request to the business system by constructing a message.

[0105] S620: The business system publishes a first business page associated with the first matter.

[0106] The first business page is associated with a first service API.

[0107] In a first possible implementation manner, the business system displays a first business page associated with the first matter in an interface.

[0108] In a second possible implementation, the business system sends a first business page associated with the first matter to the client, and the client displays the first business page associated with the first matter in an interface.

[0109] In an embodiment of the present application, the item access request includes a first item identifier. Based on the first item identifier included in the item access request, the business system determines that the user has access rights to the first item and publishes a first business page associated with the first item. Based on the first item identifier included in the item access request, the business system determines that the user does not have access rights to the first item and refuses to publish the first business page associated with the first item.

[0110] In one example, a business system stores system permission sets for different roles, including a correspondence between roles and item access permissions. Based on the role to which a user belongs, the business system queries the correspondence between roles and item access permissions and obtains item identifiers for which the user's role has item access permissions. If a first item identifier is included in the item identifiers for which the user's role has item access permissions, the user is determined to have access permissions for the first item. If the first item identifier is not included in the item identifiers for which the user's role has item access permissions, the user is determined to not have access permissions for the first item.

[0111] The correspondence between roles and business access rights is used to indicate the correspondence between different roles and business identifiers that the roles have business access rights for.

[0112] Among them, the system permission set is created by the business system setting multiple roles to access the multiple businesses provided by the business system. For example, refer to the implementation provided in Figure 7 below to establish the system permission set. This embodiment of the application is not described in detail here.

[0113] S630: The business system records a first correspondence between the identifier of the first service API and the identifier of the first matter.

[0114] The identifier of the first service API is used to indicate the first service API in the business system. In one example, the identifier of the service API in the business system is unique, that is, different service APIs have different identifiers.

[0115] The identifier of the first matter is used to indicate the matter to which the first service API belongs. The same service API has different matter identifiers under different matters.

[0116] The first corresponding relationship is used to indicate the corresponding relationship between the identifier of the first service API and the identifier of the corresponding first matter.

[0117] In an embodiment of the present application, the first business page associated with the first matter is associated with at least one service API. The first service API is included in the at least one service API associated with the first business page. Each service API corresponds to an identifier of the first matter.

[0118] In the first example, the identifier of the first matter corresponding to each service API is the same, that is, the business system assigns the same first matter identifier to the service API associated with the first business page associated with the first matter.

[0119] In the second example, the identifier of the first matter corresponding to each service API is different, that is, the business system assigns a different first matter identifier to each service API associated with the first business page associated with the first matter.

[0120] In a possible implementation, the business system obtains the identifier of the stored first item, or the business system dynamically generates the identifier of the first item.

[0121] In a first possible implementation, taking the example of dynamically generating the identifier of the first item, upon receiving the item access request, the business system creates a business session, generates the identifier of the first item in the business session, and associates the identifier of the first service API with the identifier of the first item to establish a first correspondence.

[0122] In one example, the business system may perform encoding processing based on the item identifier of the first item, the identifier of the first service API, and the timestamp information of creating the business session to generate the identifier of the first item, wherein the encoding processing includes hash encoding.

[0123] In another example, the business system generates an identifier of the first item by using a random number generation method in a business session when the user accesses the first item.

[0124] It should be noted that when session identifiers are dynamically generated, different business sessions for the first matter will have different matter identifiers for the first service API. This allows the matter identifier for the service API to be dynamically generated based on the business session when the user accesses the first matter. Compared to static API permissions, this allows for more precise distinction between the matter and the business session associated with the matter, preventing unauthorized use of the matter when there is overlap between the APIs associated with the matter.

[0125] In a second possible implementation, taking the example of obtaining the stored identifier of the first item, the business system can pre-set the item identifier for each service API when it belongs to a different item. Based on the item identifier of the item, the identifier of the service API, and the item identifier for each service API when it belongs to a different item, a correspondence between the item and the identifier is obtained. In the business session for the first item, the business system queries the correspondence between the item and the session identifier based on the item identifier of the first item to obtain the identifier of the first item corresponding to the first service API.

[0126] It should be noted that when obtaining the stored identifier of the first item, the identifier is pre-created. Therefore, the same service API has the same item identifier in different business sessions for the same item. By creating a globally unique item identifier, the item identifier is made unique. This allows the business system to distinguish the items to which the service API belongs based on the item identifier. In the event of overlapping service APIs associated with items, this can prevent unauthorized item permissions from being violated while simplifying API permission verification.

[0127] S640: The business system obtains a first call request for the first service API.

[0128] The first call request carries the identifier of the first service API and the identifier of the first matter.

[0129] In a first possible implementation manner, the business system obtains a first call request for a first service API input by a user based on a first business page.

[0130] In a second possible implementation manner, the business system obtains a first call request for a first service API sent by a client.

[0131] For example, the business system sends a first correspondence to the client. After receiving the first correspondence, the client displays a first business page interface for the first matter. In response to a trigger operation input by the user based on the first business page interface, the client sends a first service API call request to the business system. The trigger operation may be clicking a page control displayed on the first business page interface.

[0132] In a third possible implementation, the business system receives a request message indicating a first call request for a first service API.

[0133] S650: The business system allows the first calling request to access the service corresponding to the first service API according to the identifier of the first service API and the identifier of the first matter carried in the first calling request, as well as the first corresponding relationship.

[0134] In one possible implementation, when the call request for the first service API is normal, that is, when there is no unauthorized access to the first service API, the identifier of the first service API and the identifier of the first matter carried in the call request for the first service API are included in the first correspondence. However, when the call request for the first service API is abnormal, that is, when there is unauthorized access to the first service API, the identifier of the first service API and the identifier of the first matter carried in the call request for the first service API are not included in the first correspondence.

[0135] Therefore, the business system can query the first corresponding relationship. When the identifier of the matter corresponding to the identifier of the first service API is consistent with the identifier of the first matter carried by the first call request, and the identifier of the service API corresponding to the identifier of the first matter is consistent with the identifier of the first service API carried by the first call request, the first call request is allowed to access the service corresponding to the first service API. When the identifier of the matter corresponding to the identifier of the first service API is inconsistent with the identifier of the first matter carried by the first call request, and / or the identifier of the service API corresponding to the identifier of the first matter is inconsistent with the identifier of the first service API carried by the first call request, the business system rejects the first call request from accessing the service corresponding to the first service API.

[0136] In an embodiment of the present application, when the business system allows the first call request to access the service corresponding to the first service API, the first service API is called to perform data operations and output the data operation results.

[0137] For example, the business system sends the data operation result to the client. The client receives the data operation result sent by the business system and displays the data operation result. For another example, the data operation result is displayed on the first business page of the business system.

[0138] The data operations include but are not limited to query operations, input operations, data submission operations, calculation operations, etc. The services corresponding to the corresponding first service API include but are not limited to query services, input services, data submission services, data calculation services, etc.

[0139] Exemplarily, taking a query operation as an example, the business system calls the first service API to perform the query operation and generate a query result.

[0140] In an embodiment of the present application, when the call request of the service API does not carry the identifier of the matter, the business system does not allow the call request to access the service corresponding to the service API.

[0141] For example, the business system obtains a third call request for the first service API, where the third call request carries the identifier of the first service API and does not carry the identifier of the first matter. Based on the identifier of the first service API carried in the third call request and the first correspondence, the third call request is denied access to the service corresponding to the first service API. In this way, the reliability of API permission management is ensured through the identifier of the first matter, avoiding network security issues caused by exceeding the authority of the matter.

[0142] The fact that the third call request does not carry the identifier of the first matter may mean that the identifier of the matter carried in the third call request is inconsistent with the identifier of the first matter. Alternatively, the third call request may not carry the identifier of the matter.

[0143] In an embodiment of the present application, when a call request to access the service corresponding to the service API is not allowed, the business system refuses to respond to the call request and outputs a prompt message indicating that the user does not have the call permission for the requested service API. For example, the business system sends a prompt message to the client.

[0144] Based on the embodiment shown in FIG6 , after publishing a business page associated with a matter provided by the business system, the correspondence between the identifier of the service API associated with the business page and the identifier of the matter is recorded. When a service API call request is received, if the service API call request carries both the service API identifier and the matter identifier, the service API call request is allowed to access the service corresponding to the service API based on the service API identifier and the matter identifier carried in the service API call request, as well as the correspondence. Compared to the approach of controlling access to the business system by determining whether a user has API permissions, the permissions set for the same API in different businesses are the same, which poses the risk of unauthorized access by businesses. In this embodiment, the service API is associated with the matter to which it belongs by recording the correspondence between the identifier of the service API associated with the business page and the identifier of the matter. Thus, the matter to which the API belongs is distinguished by the identifier of the matter in the service API call request. Furthermore, this embodiment combines the service API identifier and the matter identifier to manage service API permissions from two perspectives: the access rights to the matter to which the service API belongs, and the service API identifier. This improves the reliability of API permission management and avoids network security issues caused by unauthorized matter permissions.

[0145] In an embodiment of the present application, when a business page is associated with multiple service APIs, the business system establishes a corresponding relationship between each service API associated with the business page and the identifier of the matter associated with the business page. When a call request is received for a business page associated with multiple service APIs, if the call request carries the identifier of the matter associated with the business page, the call request is allowed to access the service corresponding to the service API. If the call request does not carry the identifier of the matter associated with the business page, the call request is not allowed to access the service corresponding to the service API.

[0146] Taking the embodiment provided in FIG. 6 as an example, when the first business page is further associated with a second service API, the business system records a second correspondence between the identifier of the second service API and the identifier of the first matter.

[0147] The business system obtains a second call request for a second service API. The second call request carries an identifier of the second service API and an identifier of the first matter. Based on the identifier of the second service API and the identifier of the first matter carried in the second call request, and the second correspondence, the business system allows the second call request to access the service corresponding to the second service API.

[0148] The second service API may be a service API set in the first business page, or a service API set in a page with the first business page as a parent page.

[0149] In the embodiments of the present application, due to the overlap of service APIs for different matters, the same service API may be associated with multiple business pages associated with the matters. For different matters, the business system sets a correspondence between the identifier of the matter and the service API associated with the business page associated with the matter. In this way, the business system distinguishes the matters to which the service APIs belong based on the correspondence under different matters, avoiding the risk of unauthorized access to matters by constructing service APIs when the service APIs of different matters overlap.

[0150] For example, a business system provides a second item. The second item implements a different function than the first item. The second business page associated with the second item is associated with the first service API.

[0151] When the business system obtains the matter access request for the second matter, the business system publishes the second business page associated with the second matter. The business system records the third correspondence between the identifier of the first service API and the identifier of the second matter. The business system obtains a fourth call request for the first service API. When the fourth call request carries the identifier of the first service API and the identifier of the second matter, the business system allows the first call request to access the service corresponding to the first service API based on the identifier of the first service API and the identifier of the second matter carried by the fourth call request, as well as the third correspondence. When the fourth call request carries the identifier of the first service API and does not carry the identifier of the second matter, the business system rejects the fourth call request from accessing the service corresponding to the first service API based on the identifier of the first service API carried by the fourth call request, the third correspondence, and the first correspondence.

[0152] The fourth call request not carrying the identifier of the second matter may be the fourth call request carrying the identifier of the first matter, or the fourth call request not carrying the identifier of the matter.

[0153] In an embodiment of the present application, in order to improve the reliability of the API permission management of the business system, when the business system obtains a call request, the business system can verify the access rights of the service API based on the identifier of the service API and the set of API permissions allowed to be accessed. The access rights of the matter are verified based on the identifier of the first service API and the identifier of the first matter carried in the first call request, as well as the first corresponding relationship. When the user has access rights to the service API and has access rights to the matter, the call request is allowed to access the service corresponding to the service API. In this way, by combining the access rights to the service API and the access rights to the matter, the permissions of the service API are managed from two aspects: the permissions of the API and the permissions of the matter. Avoid network security issues caused by exceeding the authority of the matter.

[0154] The API permission set includes the identifiers of the service APIs that users are allowed to call in the business system.

[0155] In one possible implementation, the business system can determine the API call permission set that the user is allowed to access based on the role of the user corresponding to the service API call request, and from the API call permission sets corresponding to multiple roles stored in the business system, the API call permission set corresponding to the target role that matches the role of the user.

[0156] The above S650 is described below by taking the first call request of the first API as an example.

[0157] First, let's introduce the API permission set.

[0158] Because in the related art, by allocating permissions to each API in the business system, according to the business that each role needs to access and the API associated with the business, the API permissions of each role are allocated, and the roles and API permissions are associated to form an API call permission set for each role. There are problems such as the difficulty of API permission allocation and the large amount of data. Based on this, in order to reduce the difficulty of API permission allocation and reduce the amount of data, in an embodiment of the present application, based on the various matters provided by the business system and the API associated with each matter, by allocating access rights to each matter, the access rights of the API associated with each matter are set to obtain an API call permission set. In this way, APIs are grouped based on matters, and API access rights are set based on the access rights of matters. Compared with directly allocating permissions to APIs, the amount of data can be reduced. And based on matters, the difficulty of maintaining permissions and the difficulty of allocating permissions are reduced.

[0159] As shown in FIG. 7 , FIG. 7 is a flow chart of API call permission allocation provided in an embodiment of the present application, and the API call permission allocation shown includes S710 to S720 .

[0160] S710, setting access rights of multiple roles to multiple matters provided by the business system to obtain a permission system set.

[0161] Roles are used to indicate the types of users accessing a business system. For example, in a video playback business system, the roles include viewers and audio administrators. Viewers watch videos provided by the business system, while audio administrators manage video data within the business system, such as adding and deleting videos. Accordingly, the video playback business system provides services such as video viewing, video downloading, video collection, and video management. Accordingly, viewers have access rights to video viewing, video downloading, and video collection, while audio administrators have access rights to video management.

[0162] In a first possible implementation, based on the business authority configuration information input by the system operation and maintenance personnel of the business system, access rights of multiple roles to multiple matters provided by the business system are set.

[0163] The business authority configuration information includes the user roles for accessing the business system, the matters provided by the business system, and the matters in which each role participates.

[0164] For example, the user roles accessing a business system include Role A, Role B, and Role C. The business system provides business items S1, S2, S3, S4, and S7. If Role A participates in business items S2 and S3, Role B participates in business items S4 and S7, and Role C participates in business item S1, then Role A has access to business items S2 and S3. Role B has access to business items S4 and S7, and Role C has access to business item S1.

[0165] In a second possible implementation, the business system can analyze the business system's code files to determine the user roles that access the business system, the matters provided by the business system, and the matters each role participates in. Based on the matters provided by the business system and the matters each role participates in, each role is assigned access rights to the matters.

[0166] S720: According to the permission system set, set the calling permission of at least one API associated with the multiple matters, and obtain the API calling permission set corresponding to the role.

[0167] In one possible implementation, the business system's code files can be analyzed to obtain the APIs associated with each item. Based on the APIs associated with each item in the business system and the access permissions for each item, the API call permissions for each item can be set. For each role, the corresponding API call permission set is obtained based on the items that role is allowed to access and the API call permissions associated with the items.

[0168] As shown in FIG8 , FIG8 is a schematic diagram of a process for setting API call permissions provided in an embodiment of the present application. The process for setting API call permissions shown includes S721 to S724:

[0169] S721, analyzing the code files of the business system to obtain various items provided in the business system, trigger components of each item, and the association relationship between the trigger components and the business view.

[0170] The code file may be a front-end code file of a business system.

[0171] The trigger component of the event is used to indicate the trigger entry of the event in the business system. In one example, the trigger component of the event includes but is not limited to a trigger button, a menu, and the like.

[0172] The association between the trigger component and the business view indicates the correspondence between the trigger component and the business page associated with the trigger component, as well as the associated API in the business page. That is, after the business system responds to the trigger operation of the trigger component, it displays the business page associated with the trigger component.

[0173] The association relationship between the trigger component and the business page may be a tree relationship or a forest relationship between the trigger component and the business page.

[0174] In one example, the APIs associated in the business page include the APIs set in the business page, the APIs called by the page controls displayed in the business page, the APIs set in the page with the business page as the parent page, and / or the APIs associated in the business page associated with the trigger controls of other businesses set in the business page.

[0175] In an embodiment of the present application, an association relationship between the trigger component and the business page can be formed based on the business page displayed after the trigger component is triggered, the API set in the business page, the displayed page controls, the API set in the page with the business page as the parent page, and / or the trigger components of other businesses displayed.

[0176] For example, as shown in Figure 9, Figure 9 is a schematic diagram of the association relationship between the trigger control and the business page provided in an embodiment of the present application. The business pages associated with the trigger component of business A include page M and page N. Among them, page control K1 is displayed on page M, and page M is associated with API-1 and API-n. Page N is set with the trigger component of business B, the trigger component of business C, and page N is associated with API-2 and API-k.

[0177] S722, related matters and business pages.

[0178] In the embodiment of the present application, based on the association relationship between the trigger component and the business page, and the trigger component of each business, the business and the business page can be associated to obtain at least one business page associated with the business. For example, taking Figure 9 as an example, business A is associated with page M and page N.

[0179] S723, API for associating related matters with business pages.

[0180] In a possible implementation, at least one API associated with the multiple matters is obtained based on at least one business page associated with the multiple matters and at least one API associated with the business page.

[0181] For example, in Figure 9, business A is associated with page M and page N. Page M is associated with API-1 and API-n, and page N is associated with API-2 and API-k. The APIs associated with business A include API-1, API-n, API-2, and API-k.

[0182] S724, set the calling authority of the API associated with the matter.

[0183] In a possible implementation, the calling permission of at least one API associated with the multiple matters is set according to the access permission of the role to the multiple matters.

[0184] For example, for each item, the calling permission of at least one API associated with the item is set according to the role allowed to access the item and at least one API associated with the item.

[0185] Based on the embodiment shown in Figure 8, APIs are grouped by business, and API access permissions are set based on the business's access rights. This reduces the amount of data required compared to directly assigning permissions to APIs. Furthermore, using business as the unit reduces the difficulty of maintaining and assigning permissions.

[0186] Next, taking the first call request of the first service API as an example, the permission verification of the call request of the service API is described.

[0187] In a first possible implementation, the first correspondence can be queried based on the identifier of the first matter and the identifier of the first service API, and the set of API permissions allowed for access can be queried based on the identifier of the first service API. When the first correspondence includes the identifier of the first service API and the identifier of the first matter, and the first service API is in the set of API permissions allowed for access by the user role, the first call request is allowed to access the service corresponding to the first service API.

[0188] In one example, when the identifier of the matter corresponding to the identifier of the first service API is consistent with the identifier of the first matter carried by the first call request, and the identifier of the service API corresponding to the identifier of the first matter is consistent with the identifier of the first service API carried by the first call request, it is determined that the first corresponding relationship includes the identifier of the first service API and the identifier of the first matter.

[0189] When the identifier of the matter corresponding to the identifier of the first service API is inconsistent with the identifier of the first matter carried by the first call request, and / or the identifier of the service API corresponding to the identifier of the first matter is inconsistent with the identifier of the first service API carried by the first call request, it is determined that the first correspondence does not include the identifier of the first service API and the identifier of the first matter.

[0190] In one example, when the set of API permissions allowed to be accessed includes the identifier of the first service API, it is determined that the first service API is in the set of API permissions allowed to be accessed by the user role.

[0191] When the set of API permissions allowed to be accessed does not include the identifier of the first service API, it is determined that the first service API is not in the set of API permissions allowed to be accessed by the user role.

[0192] In one example, when the first correspondence does not include the identifier of the first service API and the identifier of the first matter, and / or the first service API is not in the API permission set allowed to be accessed by the user role, the first call request to access the service corresponding to the first service API is denied.

[0193] When the first business session of the first matter includes the identifier of the first matter and the first service API is in the API permission set allowed to be accessed by the user role, the first call request is allowed to access the service corresponding to the first service API.

[0194] In the second possible implementation, the business session created by the business system when a user accesses the first item is temporary and time-sensitive. It takes time for an attacker to intercept the first correspondence in the business system and construct the first call request message for the first service API based on the first correspondence. The attacker may send the first call request for the first service API to the business system after the business system closes the business session for the first item.

[0195] Therefore, in order to identify the API request message constructed based on the first correspondence and improve the network security of the business system, on the basis of the first possible implementation method of the permission verification of the call request of the above-mentioned service API, a judgment is added as to whether the identifier of the first matter is contained in the first business session of the first matter. When the first correspondence contains the identifier of the first service API and the identifier of the first matter, the identifier of the first matter is contained in the first business session of the first matter, and the first service API is in the API permission set allowed to be accessed by the user role, the first call request is allowed to access the service corresponding to the first service API. When the first correspondence does not contain the identifier of the first service API and the identifier of the first matter, the identifier of the first matter is not contained in the first business session of the first matter, and / or the first service API is not in the API permission set allowed to be accessed by the user role, the first call request is denied to access the service corresponding to the first service API.

[0196] In this way, by taking advantage of the temporary and time-sensitive nature of business sessions and identifying whether the API indicated by the first session identifier matches the API associated with the target business, the reliability of API permission verification is improved, thereby ensuring the network security of the business system.

[0197] In an embodiment of the present application, after determining that the first API permission verification is passed, the call request of the first service API can be responded to according to the above S650.

[0198] In one possible implementation, when the attacker constructs a message that includes the first service API permission verification, if the attacker directly responds to the first call request of the first service API, there may be a risk of unauthorized access to the matter. Therefore, in order to further reduce the risk of unauthorized access, the business system publishes the mapping value of the keyword of the first matter after allowing the first call request to access the service corresponding to the first service API. When the API call request is obtained, the call request is managed for permissions based on the identifier of the matter carried in the call request, the identifier of the service API, and the mapping value. In this way, the reliability of the API permission management of the business system is further improved by increasing the mapping value. This improves the network security of the business system.

[0199] The keyword is used to indicate the business object in the first item. For example, if the first item is a query business, the business object is the query item.

[0200] In one example, keywords can be pre-set for each item in the business system. After the business system first calls a request to access the service corresponding to the first service API, it obtains the keyword for the first item and maps the keyword to obtain a keyword-mapped message. The keyword-mapped message is then sent to the client. For example, when the business system returns data for the service corresponding to the first service API to the client, it sends the mapped value of the query item to the client.

[0201] In another example, the business system may identify a message sent to the client, obtain keywords in the message, map the keywords to obtain a keyword-mapped message, and send the keyword-mapped message to the client.

[0202] For example, a message sent to a client may be identified by a semantic parsing method to obtain keywords in the message. Another example is that a message sent to a client may be identified by a field matching method to obtain keywords in the message.

[0203] For example, taking the second service API associated with the first business page as an example, the business system obtains a second call request for the second service API. When the second call request carries the identifier of the second service API, the identifier of the first matter, and the first mapping value, the business system allows the second call request to access the service corresponding to the second service API based on the identifier of the second service API, the first mapping value, the identifier of the first matter, and the second corresponding relationship carried in the second call request.

[0204] For example, when the first mapping value verification is passed, the second correspondence contains the identifier of the second service API and the identifier of the first matter, and the second service API is in the API permission set allowed to be accessed by the user role, the second call request is allowed to access the service corresponding to the second service API.

[0205] In the first example, the business system may compare the first mapping value carried in the second call request with the mapping values ​​of multiple keywords of the first item in the business session. If the mapping values ​​of the multiple keywords of the first item include the first mapping value, the first mapping value verification is determined to have passed. If the mapping values ​​of the multiple keywords of the first item do not include the first mapping value, the first mapping value verification is determined to have failed.

[0206] In a second example, the business system obtains a second keyword mapped to the first mapping value, verifies the second keyword based on the keyword corresponding to the first mapping value among the mapping values ​​of the multiple keywords, and determines that the first mapping value has passed verification when the second keyword verification passes.

[0207] The second keyword is a keyword obtained by restoring the first mapping value.

[0208] As shown in Figure 10, Figure 10 is a schematic diagram of the keyword mapping provided by an embodiment of the present application. The business system maps multiple keywords of the first matter in the business session to obtain mapping values ​​of multiple keywords. The mapping values ​​of multiple keywords are sent to the client. The service API call request sent by the client to the business system carries the mapping values ​​of the keywords. The business system verifies the first mapping value carried in the service API call request according to the mapping values ​​of the multiple keywords of the first matter in the business session. When the verification is passed, the business system restores the first mapping value carried in the service API call request to a keyword to obtain a business object.

[0209] In order to better illustrate the API permission management method of the business system provided in the embodiment of the present application, taking the first matter as the matter query business as an example, an application scenario of the API permission management method of the business system in the matter query business is provided.

[0210] As shown in Figure 11 (a), a quick entry box and an information display box are displayed in the client's business system interface. Among them, the information display box displays the "News Updates", "Notifications" and "Other" trigger components. The quick entry box displays the trigger components of the weather query business, the event query business, the date query business and the record query business. The user triggers the event access request of the event query business by clicking on the trigger component of the event query business in the interface. The business system obtains the event access request. A business session for the event query business is created, and the event input page associated with the event query business as shown in Figure 11 (b) is published. The event input interface is provided with an event input box and an event query control. The event input box is associated with the event submission API, and the event query control is associated with the event query API. That is, the APIs associated with the event input interface include the event submission API and the event query API.

[0211] The item query API is used to return item query results, which indicate the item to which the query term entered by the user belongs. For example, if the user enters the query term "cherries", the corresponding item is "fruit query".

[0212] The event submission API is used to submit the query terms entered by the user to the processing module of the business system.

[0213] In this business session, the event submission API and the event query API generate their respective event identifiers, and establish a correspondence between the event submission API and the event query API's respective identifiers and their respective event identifiers, as shown in Table 2.

[0214] Table 2. Session identifiers of event submission API and matter query API

[0215] It should be noted that the correspondence shown in Table 2 is only an example and does not constitute a limitation on the API permission management method of the business system provided in the embodiment of the present application.

[0216] As shown in Figure 11 (c), the user enters the query word "cherries" and clicks the "matter query" control in the event input interface, triggering the first call request of the first service API.

[0217] The business system obtains the first call request of the first service API. The first call request carries the identifier of the matter and the identifier of the first service API. When the first call request carries the identifier of the matter as "23434302" and the identifier of the first service API carried is "matters query API", the business system allows the first call request to access the service of the matter query API. The business system establishes a mapping relationship between the keyword "fruit query" and the mapping value "1352101354" of "fruit query" in the business session of the matter query business. And returns the query result and the mapping value "1352101354" of "fruit query". As shown in Figure 11 (d), the matter to which "cherries" displayed on the page belongs is "fruit query".

[0218] When the user clicks the "Submit" control in FIG. 12 (a), a second call request of the second service API is triggered.

[0219] The business system receives a second call request for the second service API. The second call request carries the identifier of the event, the identifier of the second service API, and the first mapping value. When the identifier of the event is "64565604," the identifier of the second service API is "Event Submission API," and the first mapping value is "1352101354," the business system allows the second call request to access the Event Submission API service. As shown in Figure 12 (b), the view displays information about "cherries," including classification, origin, variety, and cultivation techniques.

[0220] The above mainly introduces the solution provided by the embodiment of the present application from the perspective of the interaction between the business system and the user. It can be understood that in order to realize the functions performed by the above business system, the above business system includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should easily realize that, in combination with the units and algorithm operations of each example described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in a hardware or computer software driven hardware manner depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0221] The embodiment of the present application can divide the above-mentioned business system into functional modules according to the above-mentioned method example. Each functional module can be divided according to each function, or two or more functions can be integrated into one processing module. The above-mentioned integrated module can be implemented in the form of hardware or in the form of software functional modules. It is understood that the naming and grouping of the devices and modules in the embodiment of the present application are schematic and are only a logical functional grouping. In actual implementation, other grouping methods may be used.

[0222] For example, as shown in FIG13 , the business system may include an authority control module 131 and an API processing module 132 .

[0223] The permission control module 131 is configured to publish a first business page associated with the first matter, record a first correspondence between the identifier of the first service API and the identifier of the first matter, obtain a first call request for the first service API, and allow the first call request to access the service corresponding to the first service API based on the identifier of the first service API and the identifier of the first matter carried in the first call request, as well as the first correspondence. For example, the permission control module 131 executes steps S620 to S650 in FIG. 6 .

[0224] The API processing module 132 is configured to provide a first call request to access a service corresponding to the first service API.

[0225] As shown in FIG. 13 , the authority control module 131 includes an authority configuration unit 1311 , an authority control unit 1312 , a page parsing unit 1313 , an access adaptation unit 1314 , and a routing adaptation unit 1315 .

[0226] The permission configuration unit 1311 is configured to record a first correspondence between the identifier of the first service API and the identifier of the first matter, set access permissions for multiple roles to multiple matters provided by the business system, and, based on the roles' access permissions to the multiple matters, set access permissions for at least one API associated with the multiple matters to obtain a set of API call permissions corresponding to the roles.

[0227] The permission control unit 1312 is configured to allow the first calling request to access the service corresponding to the first service API according to the identifier of the first service API and the identifier of the first matter carried in the first calling request, and the first corresponding relationship.

[0228] Page parsing unit 1313 is configured to publish a first business page associated with a first item. The unit also analyzes the code files of the business system to obtain multiple items provided in the business system, the trigger components for each item, and the associations between the trigger components and the business pages. Based on the multiple items provided by the business system, the trigger components for each item, and the associations between the trigger components and the business pages, the unit obtains the association between each item and the business page. Based on the APIs associated with each business page and the association between each item and the business page, the unit obtains at least one API associated with each item.

[0229] The access adaptation unit 1314 is configured to maintain the service session, save the first correspondence between the identifier of the first service API and the identifier of the first item, and the mapping relationship between the keyword and the mapping value of the keyword.

[0230] The routing matching unit is used to obtain the matter access request and the first call request of the first service API.

[0231] Among them, the permission control module 131 and the API processing module 132 can be hardware modules, or they can also be software modules, which is not limited in the embodiment of the present application.

[0232] It should be noted that the naming and grouping of modules in the business system in FIG13 is schematic and is merely a logical functional grouping. There may be other grouping methods in actual implementation.

[0233] For example, the business system can be named as the API authority management device of the business system. As shown in Figure 14, Figure 14 is a structural diagram of the API authority management device of the business system provided by the embodiment of the present application. The API authority management device 14 of the business system shown includes:

[0234] The business module 141 is configured to publish a first business page associated with the first matter, wherein the first business page is associated with a first service API. For example, the business module 141 executes S620 in FIG. 6 .

[0235] The configuration module 142 is configured to record a first correspondence between the identifier of the first service API and the identifier of the first event. For example, the configuration module 142 executes S630 in FIG6 .

[0236] The acquisition module 143 is configured to acquire a first call request for the first service API, wherein the first call request carries an identifier of the first service API and an identifier of the first matter. For example, the acquisition module 143 executes S640 in FIG. 6 .

[0237] The permission module 144 is configured to allow the first call request to access the service corresponding to the first service API based on the identifier of the first service API and the identifier of the first matter carried in the first call request, and the first correspondence. For example, the permission module executes S650 in FIG6 .

[0238] Among them, the business module 141, the configuration module 142, the acquisition module 143, and the permission module 144 can all be implemented by software or by hardware. For example, the implementation of the business module 141 is described below using the business module 141 as an example. Similarly, the implementation of the configuration module 142, the acquisition module 143, and the permission module can refer to the implementation of the business module 141.

[0239] As an example of a software functional unit, the business module 141 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Furthermore, the computing instance may be one or more. For example, the business module 141 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed in the same region or in different regions. Furthermore, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, and each AZ includes one data center or multiple geographically close data centers. Generally, a region may include multiple AZs.

[0240] Similarly, multiple hosts / virtual machines / containers running the code can be distributed within the same virtual private cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Cross-region communication between two VPCs within the same region, or between VPCs in different regions, requires a communication gateway within each VPC to interconnect the VPCs.

[0241] As an example of a hardware functional unit, the service module 141 may include at least one computing device, such as a server. Alternatively, the service module 141 may be implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0242] The multiple computing devices included in business module 141 can be distributed in the same region or in different regions. The multiple computing devices included in business module 141 can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in business module 141 can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of servers, ASICs, PLDs, CPLDs, FPGAs, GALs, and other computing devices.

[0243] It should be noted that, in other embodiments, the business module 141 can be used to execute any step in the API permission management method of the business system, the permission module 144 can be used to execute any step in the API permission management method of the business system, and the acquisition module 143 can be used to execute any step in the API permission management method of the business system. The configuration module 142 can be used to execute any step in the API permission management method of the business system. The steps that the business module 141, the configuration module 142, the acquisition module 143 and the permission module 144 are responsible for implementing can be specified as needed, and the full functions of the API permission management device 14 of the business system are realized by respectively implementing different steps in the API permission management method of the business system through the business module 141, the configuration module 142, the acquisition module 143 and the permission module 144.

[0244] The present application also provides an API permission management system 15 for a business system provided with the API permission management device 14 for the business system provided in FIG14. As shown in FIG15, FIG15 is a schematic diagram of the structure of the API permission management system for the business system provided in the present application embodiment, and the API permission management system 15 for the business system shown includes the API permission management device 14 for the business system and a client 20.

[0245] The client 20 is used to send a call request for the first service API to the API authority management device 14 of the business system.

[0246] The API permission management device 14 of the business system is used to obtain a matter access request for a first matter and publish a first business page associated with the first matter. Record a first correspondence between the identifier of the first service API and the identifier of the first matter. Obtain a first call request for the first service API. And based on the identifier of the first service API and the identifier of the first matter carried in the first call request, and the first correspondence, allow the first call request to access the service corresponding to the first service API. For example, the API permission management device 14 of the business system executes S610 to S650 in Figure 6 above.

[0247] The API rights management device 14 and client 20 of the business system can be implemented by software or hardware. For example, the implementation of the API rights management device 14 of the business system is described below. Similarly, the implementation of the client 20 can refer to the implementation of the API rights management device 14 of the business system.

[0248] Taking a module as an example of a software functional unit, the API permission management device 14 of the business system may include code running on a computing instance. The computing instance may be at least one of computing devices such as a physical host (computing device), a virtual machine, and a container. Furthermore, the above-mentioned computing device may be one or more. For example, the API permission management device 14 of the business system may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the application may be distributed in the same region or in different regions. The multiple hosts / virtual machines / containers used to run the code may be distributed in the same AZ or in different AZs, and each AZ includes one data center or multiple data centers with close geographical locations. Generally, a region may include multiple AZs.

[0249] Similarly, the multiple hosts / virtual machines / containers running the code can be distributed within the same VPC or across multiple VPCs. Typically, a VPC is located within a region. Cross-region communication between two VPCs within the same region, or between VPCs in different regions, requires a communication gateway within each VPC to interconnect the VPCs.

[0250] As an example of a hardware functional unit, the API rights management device 14 of the business system may include at least one computing device, such as a server. Alternatively, the API rights management device 14 of the business system may be implemented using an ASIC or a PLD. The PLD may be implemented using a CPLD, FPGA, GAL, or any combination thereof.

[0251] The multiple computing devices included in the API permission management device 14 of the business system can be distributed in the same region or in different regions. The multiple computing devices included in the API permission management device 14 of the business system can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in the API permission management device 14 of the business system can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0252] An embodiment of the present application also provides a computing device for executing the API permission management method of the above-mentioned business system.

[0253] In one example, the computing device may include a business system as shown in FIG13 . The business system includes a permission control module 131 and an API processing module 132 .

[0254] In another example, the computing device may include an API authority management device 14 of a business system as shown in FIG14 . The API authority management device 14 of the business system includes a business module 141 , a configuration module 142 , an acquisition module 143 and a authority module 144 .

[0255] In another embodiment, as shown in FIG16 , computing device 16 includes bus 162, processor 164, memory 166, and communication interface 168. Processor 164, memory 166, and communication interface 168 communicate with each other via bus 162. Computing device 16 can be a server or a terminal device. It should be understood that this application does not limit the number of processors 164 and memory 166 in computing device 16.

[0256] Bus 162 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, among others. Buses may be classified as address buses, data buses, control buses, and the like. For ease of illustration, FIG16 illustrates a single bus line, but this does not imply a single bus or type of bus. Bus 162 may include a path for transmitting information between various components of computing device 16 (e.g., memory 166, processor 164, and communication interface 168).

[0257] The processor 164 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0258] In the present application, the processor 164 can execute the API permission management method of the business system provided in FIG6 above. For example, obtain a matter access request for a first matter and publish a first business page associated with the first matter. Record a first correspondence between the identifier of the first service API and the identifier of the first matter. Obtain a first call request for the first service API. And based on the identifier of the first service API and the identifier of the first matter carried in the first call request, and the first correspondence, allow the first call request to access the service corresponding to the first service API.

[0259] The memory 166 may include volatile memory, such as random access memory (RAM). The processor 164 may also include non-volatile memory, such as read-only memory (ROM), flash memory, a hard disk drive (HDD), or a solid state drive (SSD).

[0260] Memory 166 stores executable program code, and processor 164 executes the executable program code to implement the functions of the aforementioned business module 141, permission module 144, and response module 143, thereby implementing the API permission management method of the business system. In other words, memory 166 stores instructions for executing the API permission management method of the business system.

[0261] The communication interface 168 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 16 and other devices or a communication network.

[0262] The API permission management method for the business system disclosed in the above method embodiment can be applied to the processor 164 or implemented by the processor 164. The processor 164 can be an integrated circuit chip with signal processing capabilities.

[0263] During implementation, each step of the above-described method can be completed by hardware integrated logic circuits or software instructions in processor 164. The above-described processor 164 can be a general-purpose processor, including a CPU, a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete vacuum tube or transistor logic devices, or discrete hardware components. It can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly implemented and executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium well-known in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. The storage medium is located in memory 166, and processor 164 reads the information in memory 166 and, in conjunction with its hardware, completes the steps of the above-described method.

[0264] In one possible implementation, the processor 164 may also be used to execute the API permission management method of the business system. For specific implementation, reference may be made to the embodiment provided by the API permission management method of the above-mentioned business system, and the embodiments of this application will not be repeated here.

[0265] In the embodiment of the present application, the chip system can be composed of chips, or can include chips and other discrete devices.

[0266] The embodiment of the present application also provides a computing device cluster 17 for executing the API permission management method of the above-mentioned business system.

[0267] In one example, the computing device cluster 17 may include a business system as shown in FIG13 . The business system includes a permission control module 131 and an API processing module 132 .

[0268] In another example, the computing device cluster 17 may include the API authority management device 14 of the business system as shown in FIG14 . The API authority management device 14 of the business system includes a business module 141 , a configuration module 142 , an acquisition module 143 and a authority module 144 .

[0269] In another example, the computing device cluster 17 may include an API authority management system 15 of a business system as shown in FIG15 . The API authority management system 15 of the business system includes an API authority management apparatus 14 of the business system and a client 20 .

[0270] In another example, as shown in FIG17 , computing device cluster 17 includes at least one computing device 16 as shown in FIG16 . Computing device 16 includes a bus 162, a processor 164, a memory 166, and a communication interface 168. Processor 164, memory 166, and communication interface 168 communicate with each other via bus 162. Computing device 16 can be a server or a terminal device.

[0271] In one possible implementation, one or more computing devices in the computing device cluster 17 can be connected via a network. The network can be a wide area network or a local area network, etc. Figure 18 shows a possible implementation. As shown in Figure 18, two computing devices 16A and 16B are connected via a network. Specifically, the connection to the network is made through the communication interface in each computing device. In this type of possible implementation, the memory 166 in the computing device 16A stores instructions for executing the functions of the configuration module 142 and the permission module 144. At the same time, the memory 166 in the computing device 16B stores instructions for executing the functions of the business module 141 and the acquisition module 143.

[0272] The connection method between the computing device cluster 17 shown in Figure 18 can be that considering the API permission management method of the business system provided in this application, it is necessary to publish the first business page associated with the first matter. And after publishing the first business page associated with the first matter, the first correspondence between the identifier of the first service API and the identifier of the first matter is recorded, and the first correspondence needs to be stored. That is, the functions performed by the business module 141 and the acquisition module 143 involve data interaction, while the functions performed by the configuration module 142 involve a large amount of data. Therefore, it is considered that the functions implemented by the configuration module 142 and the permission module 144 are executed by the computing device 16A. The functions performed by the business module 141 and the acquisition module 143 are executed by the computing device 16B.

[0273] It should be understood that the functionality of computing device 16A shown in FIG18 may also be performed by multiple computing devices 16. Similarly, the functionality of computing device 16B may also be performed by multiple computing devices 16.

[0274] The present application also provides a computer program product containing instructions. The computer program product may be software or a program product containing instructions that can be run on a computing device or stored in any available medium. When the computer program product is run on at least one computing device, it causes the at least one computing device to execute the aforementioned API permission management method for the business system.

[0275] For example, when the computer program product is run on at least one computing device, the at least one computing device is enabled to execute the API permission management method of the business system shown in FIG6 .

[0276] The embodiments of the present application also provide a computer-readable storage medium. All or part of the processes in the above-mentioned method embodiments can be completed by a computer program to instruct the relevant hardware, and the program can be stored in the above-mentioned computer-readable storage medium. When the program is executed, it can include the processes of the above-mentioned method embodiments. The computer-readable storage medium can be a terminal in any of the above-mentioned embodiments, such as: an internal storage unit including a data transmission end and / or a data receiving end, such as a hard disk or memory of the terminal. The above-mentioned computer-readable storage medium can also be an external storage device of the above-mentioned terminal, such as a plug-in hard disk equipped on the above-mentioned terminal, a smart memory card (smart media card, SMC), a secure digital (secure digital, SD) card, a flash card (flash card), etc. Further, the above-mentioned computer-readable storage medium can also include both the internal storage unit of the above-mentioned terminal and an external storage device. The above-mentioned computer-readable storage medium is used to store the above-mentioned computer program and other programs and data required by the above-mentioned terminal. The above-mentioned computer-readable storage medium can also be used to temporarily store data that has been output or is to be output.

[0277] It should be understood that the collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution of this application complies with relevant laws and regulations and does not violate public order and good morals. For example, in the technical solution of this application, the processing of user personal information is carried out with the user's authorization, and the same description is not repeated here.

[0278] It should be noted that the terms "first" and "second" in the specification, claims, and drawings of this application are used to distinguish different objects, rather than to describe a specific order. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units that are not listed, or may optionally include other steps or units that are inherent to these processes, methods, products, or devices.

[0279] It should be understood that in the present application, "at least one (item)" refers to one or more, "more than one" refers to two or more, "at least two (items)" refers to two or three and more than three, and "and / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following items" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0280] It should be understood that in the embodiments of the present application, "B corresponding to A" means that B is associated with A. For example, B can be determined based on A. It should also be understood that determining B based on A does not mean determining B based solely on A; B can also be determined based on A and / or other information. In addition, the "connection" in the embodiments of the present application refers to various connection methods, such as direct connection and indirect connection, to achieve communication between devices, and the embodiments of the present application do not impose any limitations on this.

[0281] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the grouping of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be grouped into different functional modules to complete all or part of the functions described above.

[0282] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the grouping of modules or units is only a logical function grouping. In actual implementation, there may be other grouping methods, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0283] Units described as separate components may or may not be physically separate, and components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple places. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0284] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0285] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling a device, such as a single-chip microcomputer, a chip, etc., or a processor to execute all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes various media for storing program codes, such as a USB flash drive, a mobile hard disk, a ROM, a RAM, a magnetic disk, or an optical disk.

[0286] The above are only specific embodiments of the present application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A method for managing API permissions of a service application program in a service system, characterized in that, Including: Publish a first business page associated with a first matter, where the first business page is associated with a first service API; Record a first correspondence relationship between the identifier of the first service API and the identifier of the first matter; Obtain a first call request for the first service API, where the first call request carries the identifier of the first service API and the identifier of the first matter; According to the identifier of the first service API and the identifier of the first matter carried in the first call request, and the first correspondence relationship, allow the first call request to access the service corresponding to the first service API.

2. The method according to claim 1, wherein The first business page is associated with a second service API, and the method further includes: Record a second correspondence relationship between the identifier of the second service API and the identifier of the first matter; Obtain a second call request for the second service API, where the second call request carries the identifier of the second service API and the identifier of the first matter; According to the identifier of the second service API and the identifier of the first matter carried in the second call request, and the second correspondence relationship, allow the second call request to access the service corresponding to the second service API.

3. The method according to claim 1 or 2, characterized in that, The method further includes: Obtain a third call request for the first service API, where the third call request carries the identifier of the first service API and does not carry the identifier of the first matter; According to the identifier of the first service API carried in the third call request, and the first correspondence relationship, reject the third call request from accessing the service corresponding to the first service API.

4. The method according to any one of claims 1 to 3, characterized in that, The method further includes: Publish a second business page associated with a second matter, where the second business page is associated with the first service API; Record a third correspondence relationship between the identifier of the first service API and the identifier of the second matter; Obtain a fourth call request for the first service API, where the fourth call request carries the identifier of the first service API and the identifier of the second matter; According to the identifier of the first service API and the identifier of the second matter carried in the fourth call request, and the third correspondence relationship, allow the first call request to access the service corresponding to the first service API.

5. The method according to claim 4, characterized in that The method further includes: Obtain a fourth call request for the first service API, where the fourth call request carries the identifier of the first service API and does not carry the identifier of the second matter; According to the identifier of the first service API carried in the fourth call request, and the third correspondence relationship and the first correspondence relationship, reject the fourth call request from accessing the service corresponding to the first service API.

6. The method according to any one of claims 2 to 5, characterized in that The first service API and / or the second service API is set in the first business page or in a page with the first business page as the parent page.

7. The method according to any one of claims 1 to 6, characterized in that, The recording of the first correspondence relationship between the identifier of the first service API and the identifier of the first matter includes: Create a first business session for the first matter; Generate an identifier for the first matter in the first service session, associate the identifier of the first service API with the identifier of the first matter, and establish the first corresponding relationship.

8. The method according to any one of claims 1 to 7, characterized in that, The first call request carries a user role. The step of allowing the first call request to access the service corresponding to the first service API according to the identifier of the first service API and the identifier of the first matter carried in the first call request, and the first corresponding relationship includes: When the first corresponding relationship includes the identifier of the first service API and the identifier of the first matter, the identifier of the first matter is included in the first service session of the first matter, and the first service API is in the set of API permissions allowed to be accessed by the user role, allow the first call request to access the service corresponding to the first service API.

9. The method according to any one of claims 1 to 8, characterized in that, The first service page is associated with a second service API; after allowing the first call request to access the service corresponding to the first service API according to the identifier of the first service API and the identifier of the first matter carried in the first call request, and the first corresponding relationship, the method further includes: Publish the mapped value of the keyword of the first matter, and send the mapped value of the keyword to the client corresponding to the first call request. Obtain a second call request for the second service API, where the second call request carries the identifier of the second service API, the identifier of the first matter, and a first mapped value. Allow the second call request to access the service corresponding to the second service API according to the identifier of the second service API, the first mapped value, and the identifier of the first matter carried in the second call request, and a second corresponding relationship; the second corresponding relationship is used to indicate the corresponding relationship between the identifier of the second service API and the identifier of the first matter.

10. The method according to any one of claims 1 to 9, characterized in that, Before publishing the first service page associated with the first matter, the method further includes: Set the access permissions of multiple roles for multiple matters provided by the service system. According to the access permissions of the multiple roles for the multiple matters, set the access permissions of at least one API associated with the multiple matters to obtain the set of API call permissions corresponding to the roles.

11. The method according to claim 10, characterized in that, The step of setting the access permissions of at least one API associated with the multiple matters according to the access permissions of the multiple roles for the multiple matters includes: According to the multiple matters provided by the service system, as well as the trigger component of each matter and the association relationship between the trigger component and the service page, obtain the association relationship between each matter and the service page. According to the API associated with each service page and the association relationship between each matter and the service page, obtain at least one API associated with each matter. According to the access permissions of the role for the multiple matters and at least one API associated with each matter, set the access permissions of at least one API associated with each matter.

12. An API permission management device for a service system, characterized in that, The device includes: A service module for publishing a first service page associated with a first matter, where the first service page is associated with a first service API; A configuration module for recording a first correspondence between the identifier of the first service API and the identifier of the first matter; An acquisition module for acquiring a first call request for the first service API, where the first call request carries the identifier of the first service API and the identifier of the first matter; An authorization module for allowing the first call request to access the service corresponding to the first service API according to the identifier of the first service API and the identifier of the first matter carried in the first call request, and the first correspondence; 13. A cluster of computing devices, characterized in that, Comprising at least one computing device, each computing device comprising a processor and a memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the method according to any one of claims 1 to 11; 14. A computer program product comprising instructions, characterized in that, When the instructions are run by the computing device cluster, the computing device cluster executes the method according to any one of claims 1 to 11; 15. A computer-readable storage medium, characterized in that, Comprising computer program instructions, when the computer program instructions are executed by the computing device cluster, the computing device cluster executes the method according to any one of claims 1 to 11.

Images