A method, device, storage medium and electronic device for service invocation

Abstract

In the business calling method provided in the specification, before the business is executed, the management and control platform can determine each second application that needs to call the first application, generate a business list containing the each second application; determine the authentication parameters required by each second application in the business list when calling the first application and the verification parameters required by the first application; through the pre-deployed aspect base, inject the second aspect program into the code corresponding to each second application, and configure the authentication parameters for the second aspect program, so that when the second application calls the first application, the authentication information is generated based on the second aspect program and the authentication parameters, and the calling request carrying the authentication information is sent to the first application; at the same time, the first aspect program is injected into the code corresponding to the first application, and the verification parameters are configured for the first aspect program, so that when the first application receives the calling request sent by the second application, the verification information is generated based on the first aspect program and the verification parameters, and the authentication information is verified according to the verification information.

Description

Technical Field

[0001] This specification relates to the field of Internet technology, and in particular to a method, apparatus, storage medium, and electronic device for business invocation. Background Technology

[0002] Today, the rapid development of the internet has brought users a massive amount of online services. As the number and content of these services continue to increase, they often interoperate to enable users to access them more conveniently and quickly. In other words, a service can call upon services provided by other services during its execution to help users complete their current tasks better and faster.

[0003] However, during business calls, there may be instances of user privacy data leakage. How to avoid security risks during business calls is an urgent problem to be solved. This manual provides a method for business calls. Summary of the Invention

[0004] This specification provides a service invocation method and a service invocation device to partially solve the aforementioned problems existing in the prior art.

[0005] The following technical solution is adopted in this specification:

[0006] This specification provides a business invocation method, which is applied to a management and control platform, and the method includes:

[0007] Identify the second applications that need to call the first application, and generate a list of services that includes each of the second applications;

[0008] Determine the authentication parameters required by each second application in the business list when calling the first application, and the verification parameters required by the first application;

[0009] By pre-deploying the facet base, the second facet program is injected into the code corresponding to each second application in the business list, and the authentication parameters are configured for the second facet program. When the second application calls the first application, authentication information is generated based on the second facet program and the authentication parameters, and a call request carrying the authentication information is sent to the first application.

[0010] By pre-deploying a facet base, the first facet program is injected into the code corresponding to the first application, and the verification parameters are configured for the first facet program. When the first application receives the call request sent by the second application, it generates verification information based on the first facet program and the verification parameters, and verifies the authentication information carried in the call request according to the verification information.

[0011] Optionally, the management platform stores a list of cutpoints that includes the cutpoints in each of the second applications and the first application;

[0012] The second aspect procedure is injected into the code corresponding to each second application in the business list, specifically including:

[0013] In the list of cut points, the cut points for each second application are determined;

[0014] The second aspect program is injected from the point of cut of each of the second applications into the code corresponding to each of the second applications;

[0015] Injecting the first aspect procedure into the code corresponding to the first application specifically includes:

[0016] In the list of cut points, determine the cut point for the first application;

[0017] The first aspect program is injected into the code corresponding to the first application from the point of view of the first application.

[0018] Optionally, the authentication parameters required by each second application in the service list of the first application when calling the first application, and the verification parameters required by the first application, are determined, specifically including:

[0019] Determine the second signature content and second signature method required by each second application in the business list of the first application when calling the first application, as well as the first signature content and first signature method required by the first application.

[0020] This specification provides a business invocation method, which is applied to a second application, and the method includes:

[0021] By using a pre-deployed facet base, the second facet program sent by the control platform is injected into the point of the second application, and the authentication parameters sent by the control platform are configured for the second facet program.

[0022] When a call request carrying business data is determined, the pre-injected second aspect program is executed to generate authentication information based on the pre-configured authentication parameters and the business data, wherein the call request is used to request the invocation of the first application;

[0023] The authentication information is carried in the call request and sent to the first application, so that the first application generates verification information through the first aspect program to verify the authentication information, and determines whether to respond to the call of the second application based on the verification result; wherein, the verification information is generated by the first application through the pre-injected first aspect program and the verification parameters pre-configured for the first aspect program, and the first aspect program is pre-injected into the first application through the aspect base.

[0024] Optionally, the authentication parameters include at least the second signature content and the second signature method;

[0025] Based on the pre-configured authentication parameters and the business data, authentication information is generated, specifically including:

[0026] Based on the second signature content, the business data is signed using the second signature method to obtain authentication information.

[0027] This specification provides a business invocation method, which is applied to a first application and includes the following:

[0028] The first aspect program sent by the management platform is injected into the point of the first application through the pre-deployed aspect base, and the verification parameters sent by the management platform are configured for the first aspect program.

[0029] The system receives a call request carrying authentication information sent by a second application. The authentication information is generated by the second application through a pre-injected second aspect program and authentication parameters pre-configured for the second aspect program. The call request is used to request to call the first application. The second aspect program is pre-injected into the second application through an aspect base.

[0030] Execute the pre-injected first aspect procedure to generate verification information based on the authentication information and the pre-configured verification parameters;

[0031] The authentication information is verified using the verification information, and the decision on whether to respond to the call from the second application is made based on the verification result.

[0032] Optionally, the verification parameters include at least the first signature content and the first signature method;

[0033] Execute the pre-injected first aspect procedure to generate verification information based on the authentication information and the pre-configured verification parameters, specifically including:

[0034] Determine the business data contained in the authentication information;

[0035] Based on the first signature content, the first signature method is used to sign the business data to obtain verification information.

[0036] Optionally, the authentication information is verified using the verification information, and a decision is made on whether to respond to the call from the second application based on the verification result, specifically including:

[0037] Determine whether the authentication information matches the verification information;

[0038] If so, then respond to the call from the second application;

[0039] If not, a verification failure message is sent to the second application.

[0040] Optionally, the verification parameters are the same as the authentication parameters;

[0041] Determining whether the authentication information matches the verification information specifically includes:

[0042] Determine whether the authentication information is the same as the verification information;

[0043] If they are the same, then the authentication information matches the verification information;

[0044] Otherwise, the authentication information does not match the verification information.

[0045] This specification provides a service invocation device, including:

[0046] The business list generation module determines each second application that needs to call the first application and generates a business list containing each second application.

[0047] The parameter determination module determines the authentication parameters required by each second application in the business list when calling the first application, as well as the verification parameters required by the first application.

[0048] The second injection module injects the second aspect program into the code corresponding to each second application in the business list through a pre-deployed aspect base, and configures the authentication parameters for the second aspect program, so that when the second application calls the first application, it generates authentication information based on the second aspect program and the authentication parameters, and sends a call request carrying the authentication information to the first application.

[0049] The first injection module injects a first aspect program into the code corresponding to the first application through a pre-deployed aspect base, and configures the verification parameters for the first aspect program. When the first application receives the call request sent by the second application, it generates verification information based on the first aspect program and the verification parameters, and verifies the authentication information carried in the call request according to the verification information.

[0050] This specification provides a service invocation device, including:

[0051] The authentication configuration module injects the second aspect program sent by the management platform into the pointcut of the second application through a pre-deployed aspect base, and configures the authentication parameters sent by the management platform for the second aspect program;

[0052] The authentication information generation module, when it determines a call request carrying business data, executes the pre-injected second aspect program and generates authentication information based on the pre-configured authentication parameters and the business data, wherein the call request is used to request the call of the first application;

[0053] The call request sending module carries the authentication information in the call request and sends it to the first application, so that the first application generates verification information through the first aspect program to verify the authentication information, and determines whether to respond to the call of the second application based on the verification result; wherein, the verification information is generated by the first application through the pre-injected first aspect program and the verification parameters pre-configured for the first aspect program, and the first aspect program is pre-injected into the first application through the aspect base.

[0054] This specification provides a service invocation device, including:

[0055] The verification configuration module injects the first aspect program sent by the management platform into the pointcut of the first application through the pre-deployed aspect base, and configures the verification parameters sent by the management platform for the first aspect program;

[0056] The call request receiving module receives a call request carrying authentication information sent by the second application. The authentication information is generated by the second application through a pre-injected second aspect program and authentication parameters pre-configured for the second aspect program. The call request is used to request to call the first application. The second aspect program is pre-injected into the second application through the aspect base.

[0057] The verification information generation module executes the pre-injected first aspect program to generate verification information based on the authentication information and the pre-configured verification parameters;

[0058] The verification module verifies the authentication information using the verification information and determines whether to respond to the call from the second application based on the verification result.

[0059] This specification provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described business invocation method.

[0060] This specification provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the above-described service invocation method.

[0061] The above-mentioned technical solutions adopted in this specification can achieve the following beneficial effects:

[0062] In the business invocation method provided in this specification, before business execution, the management platform can determine each second application that needs to invoke the first application and generate a business list containing each second application; determine the authentication parameters required by each second application in the business list when invoking the first application and the verification parameters required by the first application; inject the second aspect program into the code corresponding to each second application through a pre-deployed aspect base, and configure the authentication parameters for the second aspect program, so that when the second application invokes the first application, it generates authentication information based on the second aspect program and the authentication parameters, and sends an invocation request carrying the authentication information to the first application; at the same time, inject the first aspect program into the code corresponding to the first application, and configure the verification parameters for the first aspect program, so that when the first application receives the invocation request sent by the second application, it generates verification information based on the first aspect program and the verification parameters, and verifies the authentication information according to the verification information. Attached Figure Description

[0063] The accompanying drawings, which are included to provide a further understanding of this specification and form part of this specification, illustrate exemplary embodiments and are used to explain this specification, but do not constitute an undue limitation thereof. In the drawings:

[0064] Figure 1 This is a schematic diagram of a process applied to a management and control platform, as provided in this specification.

[0065] Figure 2 This document provides a schematic diagram illustrating the specific process of implementing the business invocation method provided in this document.

[0066] Figure 3 This is a flowchart illustrating a business invocation method for a second application provided in this specification.

[0067] Figure 4 This is a flowchart illustrating a business invocation method applied to the first application provided in this specification;

[0068] Figure 5 This is a schematic diagram of a service invocation device provided in this specification;

[0069] Figure 6 This is a schematic diagram of a service invocation device provided in this specification;

[0070] Figure 7 This is a schematic diagram of a service invocation device provided in this specification;

[0071] Figure 8 This specification provides a corresponding Figure 1 , Figure 3 , Figure 4 A schematic diagram of an electronic device. Detailed Implementation

[0072] Currently, users utilize various online services daily, each offering different functionalities. Often, combining these functionalities in combination can enhance the user experience. Consequently, users frequently encounter inter-service calls between different services. However, not all calls are beneficial. In practice, malicious services aiming to steal data or disrupt other services often exploit these calls to attack legitimate user operations.

[0073] The traditional calling model allows business functions to directly call each other without any obstacles. For example, when business A needs to call a function in business B, business A simply sends a request to business B, and business B will directly agree to the call upon receiving the request. This method, which lacks any authentication during the calling process and accepts the call regardless of who the other party is, inevitably attracts many malicious attacks.

[0074] To address the aforementioned issues, this specification provides a business invocation method based on security aspects that enables authentication during invocation.

[0075] The security aspect mentioned above refers to a method that uses aspect-oriented programming (AOP) to dynamically add or modify aspects that implement security-related business logic within the runtime logic of the business application without modifying the application itself. This decouples the implementation of security-related business logic from the business application, thus avoiding development iteration problems caused by high coupling.

[0076] The aspect program mentioned here refers to an enhancement program that implements security aspect functionality based on business logic. By using aspect-oriented programming, aspect programs can be injected into corresponding pointcuts in the business application. These aspect programs are triggered and executed during the execution of the business application to achieve the required security aspect functionality.

[0077] When a business application executes its business logic, it typically does so through method calls. Therefore, any method within the business application can be used as a pointcut for an aspect, as mentioned above, and the aspect can be injected into the corresponding pointcut. This ensures that when the business application reaches a pointcut—that is, when it calls a method of the business application corresponding to that pointcut—the injected aspect is executed.

[0078] Typically, the code responsible for injecting aspects into pointcuts has high reusability. Therefore, the program implementing this process is usually abstracted into a service module, namely the aspect base. The aspect base can obtain the aspects to be deployed and the pointcuts in the business application from a third party that provides secure aspect services. After the application container starts, it is configured by the environment and the corresponding aspects are injected at the pointcuts in the business application.

[0079] A business application can be a business application that provides business services on the servers of a business platform. These business services can be services provided by the business platform's servers to users, such as query services and payment services. Business services can also be services provided by one server of the business platform to other servers, such as settlement services.

[0080] Of course, as described above, to decouple the security aspect service program from the business application, this specification employs aspect-oriented programming (AOP) to allow the security aspect service program and the business application to intertwine during business execution, while remaining parallel and independently maintainable. Therefore, unlike the business application provider, the third party providing the security aspect service can manage the content related to the security aspect service through a management platform, such as configuring security aspect service management policies, iterating aspect program versions, configuring aspect program deployment rules, etc. Of course, the provider of the security aspect service can be either a third party or a business application provider.

[0081] When managing the content related to security aspect services, the management platform can record various configuration information through configuration files, such as the configuration of various policies and the deployment rules for aspect programs. This allows the aspect base to deploy aspect programs based on the configuration files, or the management platform to implement security aspect services based on the configuration files.

[0082] In practical applications, service providers typically set up data centers containing several physical machines or servers, providing the physical resources required by business applications. Of course, a business application may not require all the physical resources of a single physical machine; therefore, virtualization technology is often used to run multiple virtual hosts on a single physical machine. Each virtual host is independent, sharing a portion of the physical resources of the physical machine. Application containers can then be deployed within these virtual hosts, and business applications can run through these containers. Application containers typically contain the physical resources allocated to them, such as CPU and memory, as well as the runtime environment provided to them, such as the operating system (OS) or other runtime environment data (e.g., container serial number, assigned IP address, application name, tenant, environment variables, etc.). Business applications can be deployed within these application containers to execute business logic.

[0083] In scenarios where secure aspect-based business execution is used, the server of the business provider or a third party providing secure aspect services can provide a management platform. The management platform can manage the content involved in the secure aspect services and deploy the aspect base in the application container. The aspect program is injected into the business application in the business application container through the aspect base, so as to provide secure aspect service support for the application container of the business provider.

[0084] Therefore, the aspect-oriented framework can be pre-deployed in the application container of the service provider. Typically, when the application container starts, the operating system provided to the application container is invoked, and the pre-deployed aspect-oriented framework runs. The aspect-oriented framework obtains the aspect programs and pointcuts of the business application from the management platform and injects the aspect programs into the pointcuts of the business application within the application container. Furthermore, the aspect-oriented framework can also obtain the aspect programs and pointcuts of the business application from the management platform during the execution of the business application and inject the aspect programs into the pointcuts of the business application within the application container.

[0085] Of course, how the segmentation base obtains the information needed to deploy the segmentation program from the management platform can be configured as needed. For example, it can actively pull the required information from the management platform according to the configuration file, or the management platform can actively send the required information to the segmentation base.

[0086] After injecting an aspect into a pointcut of a business application, the business application can trigger the aspect during execution to achieve the corresponding security aspect business function.

[0087] To make the objectives, technical solutions, and advantages of this specification clearer, the technical solutions of this specification will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of them. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this specification.

[0088] In this specification, "service" can refer to a service provided by a platform or system, or an application on a terminal. Mutual invocation between two services can be between services provided by the same platform or system but located on two different terminals, or between different services or applications on the same terminal. In fact, whether it's mutual invocation between two services within the same terminal or between two services on different terminals, the core methods and logic are similar; only the execution entity differs. For ease of explanation, this specification uses mutual invocation between services in the form of applications as an example to illustrate the service invocation methods provided in this specification. It is conceivable that, based on the methods in this specification, mutual invocation between services located on two different terminals can also be implemented accordingly.

[0089] In this specification, the executing entity for the business invocation method can refer to an application on a device such as a terminal or server. For ease of description, this specification will use the second application sending the invocation request, the first application being invoked, and the management platform for configuration management as examples to illustrate the business invocation method provided in this specification. In the embodiments provided in this specification, the management platform, the second application, and the first application are on the same terminal. It is conceivable that when the management platform, the second application, and the first application are located on different terminals, the business invocation can still be implemented using the method provided in this specification.

[0090] It is worth mentioning that the three business invocation methods provided below are actually the execution flow of the same method under three different execution entities. The description of any one of the business invocation methods in this manual is also applicable to the other two business invocation methods.

[0091] The technical solutions provided in the various embodiments of this specification are described in detail below with reference to the accompanying drawings.

[0092] Figure 1 This document provides a flowchart illustrating a business invocation method applied to a management and control platform, comprising the following steps:

[0093] S100: Determine each of the second applications that need to call the first application, and generate a service list containing each of the second applications.

[0094] The specific process of the business invocation method provided in this manual is as follows: Figure 2 As shown, Figure 2 It demonstrates the interaction process between the second application, the first application, and the management platform.

[0095] In the business invocation methods provided in this manual, the first application is the invoked business, and the second application is the business that invokes the first application. The management platform is an independent non-business application within the terminal providing the business, used to help businesses that originally lacked authentication functionality to implement authentication during invocation. It is worth noting that all operations performed by the management platform in the business invocation methods provided in this manual are implemented during the management phase, that is, before the business application runs. Typically, the management platform may include aspect programs, a list of businesses, a list of pointcuts, and management configurations.

[0096] An aspect program can be a program used to implement authentication functionality. Typically, authentication is achieved by signing the transmitted data. Therefore, an aspect program can essentially be a piece of code used to implement signing functionality; it can also be called enhancement code. During the preparation phase, when the business application is not running, the management platform can pre-inject the aspect program into the business logic—that is, insert the enhancement code into the original business code—thereby enabling authentication functionality in applications that did not originally possess it.

[0097] In the business invocation method provided in this manual, a business list is pre-generated for each potentially invoked first application. This list stores all trustworthy businesses for that first application. During the preparation phase, the management platform only injects aspects into the businesses in the business list. When any business in the list invokes the first application, the corresponding aspect is triggered for authentication. However, if an untrusted business outside the business list wishes to invoke the first application, authentication cannot be achieved because the untrusted business does not contain aspects. In other words, only businesses within the business list can invoke the first application. The businesses in the business list can be freely changed by the user, meaning the user can choose which businesses to trust.

[0098] For ease of explanation, unless otherwise specified, the second application mentioned in the business invocation methods provided in this specification refers to a business within the business list of the first application.

[0099] During the management phase, the control platform can identify each second application that has a calling relationship with the first application, that is, the second application that may call the first application, and include the identified second applications that have a calling relationship with the first application in the business list of the first application.

[0100] S102: Determine the authentication parameters required by each second application in the service list when calling the first application, and the verification parameters required by the first application.

[0101] The management platform's configuration stores all the parameters required for executing aspects. Specifically, the aspects injected into the business by the management platform include both the signature functionality required when calling other businesses and the signature functionality required when being called by other businesses. However, in reality, the aspects only contain the logic that implements these functions—the code framework. The specific data used for signing, the signing method, and whether the signature is for the caller or the called party are not included in the aspects; these parameters are stored in the management configuration. While injecting aspects into each business, the management platform determines the appropriate signature content and authentication method when calling the first application, and configures these parameters accordingly for both businesses.

[0102] Specifically, when determining authentication and verification parameters, the management platform can determine the second signature content and method required by each second application in the first application's business list when calling the first application, as well as the first signature content and method required by the first application. Determining parameters based on the first application means judging the appropriate authentication method based on the likelihood of security issues arising when the first application is called. If the likelihood of security issues arising when the first application is called is low, a simpler signature content and method can be used for authentication; conversely, if the likelihood of security issues arising when the first application is called is high, a more complex but more secure signature content and method can be used for authentication.

[0103] Similar to signing in real-world scenarios, signing specified data involves adding extra data before or after the specified data. This extra data identifies the originating entity as the data to other entities. This extra data is the signature content mentioned in this specification. Signature methods can include at least symmetric and asymmetric methods, which are common techniques in the field and will not be elaborated upon here.

[0104] In addition to signature content and signature method, authentication and verification parameters may include other parameters such as logic switches and branch switching variables. The logic switch controls whether authentication is required. When the management platform determines that the first application calling the target function requested by the second application is relatively safe or simple, with very low risk, the authentication step can be skipped through the logic switch parameter, i.e., the entire aspect procedure can be skipped to speed up business calls. Specifically, when the logic switch parameter value is "1", the aspect procedure is executed; when the logic switch parameter value is "0", the aspect procedure is skipped.

[0105] The branch switching variable controls which branch of the aspect should be executed by the second application. As mentioned in step S102, the aspect includes both authentication functions to be executed when calling other services and authentication functions to be executed when called by other services. In other words, without any parameters, the second aspect and the first aspect can be completely identical. However, in a single service call, a service can only play one role: either calling or being called. The branch switching variable controls whether the service execution and the branch in the aspect that calls other services or is called by other services can be controlled. Specifically, when the parameter value of the branch switching variable is "1", the branch that calls other services is executed; when the parameter value of the branch switching variable is "0", the branch that is called by other services is executed. In the embodiments provided in this specification, the parameter value of the branch switching variable in the authentication parameters of the second application initiating the call should be "1", and the parameter value of the branch switching variable in the verification parameters of the first application should be "0".

[0106] Before any service begins operation, that is, during the preparation and management phase, the control platform can predetermine the authentication parameters required by the second application and the verification parameters required by the first application. Of course, in the embodiments of this specification, the second application is always a service within the service list of the first application.

[0107] S104: By pre-deploying the aspect base, the second aspect program is injected into the code corresponding to each second application in the business list, and the authentication parameters are configured for the second aspect program, so that when the second application calls the first application, authentication information is generated based on the second aspect program and the authentication parameters, and a call request carrying the authentication information is sent to the first application.

[0108] After determining the authentication and verification parameters, the management platform can inject aspects into the code of the second and first applications and configure the corresponding parameters. When injecting aspects into the second and first applications, care must be taken not to disrupt their original functionality. In essence, an aspect is a piece of enhancement code, and injecting an aspect is essentially inserting that enhancement code into the original business logic code. To avoid affecting the functionality implemented by the original business logic code and to ensure that the inserted enhancement code can perform authentication, a suitable location needs to be found in the business logic code as a pointcut, and the aspect is injected into the business logic from the pointcut. Configuring parameters for the aspect is essentially filling the aspect with those parameters, enabling the aspect to perform the corresponding function based on the parameters.

[0109] The control platform pre-stores all the cutoff points for the second and first applications in its cutoff point list. The cutoff point for each service can be manually pre-set or determined by a model; this specification does not impose specific restrictions on this.

[0110] Therefore, the management platform can also store a pointcut list containing the pointcuts in each of the second applications and the first application; when injecting the second aspect program into the second application, the pointcut of each second application can be determined from the pointcut list; and the second aspect program is injected from the pointcut of each second application into the code corresponding to each second application.

[0111] After injecting the second aspect into the second application and configuring the corresponding authentication parameters, when the second application calls the first application, it can generate authentication information based on the second aspect and authentication parameters, and send the authentication information to the first application in the call request.

[0112] S106: By pre-deploying the aspect base, the first aspect program is injected into the code corresponding to the first application, and the verification parameters are configured for the first aspect program, so that when the first application receives the call request sent by the second application, verification information is generated based on the first aspect program and the verification parameters, and the authentication information carried by the call request is verified according to the verification information.

[0113] Similarly, when injecting the first aspect into the first application, the pointcut of the first application can be determined from the pointcut list; the first aspect is then injected into the code corresponding to the first application from the pointcut of the first application.

[0114] After injecting the first aspect into the first application and configuring the verification parameters into the first aspect, when the first application receives a call request sent by the second application, it can generate verification information based on the first aspect and the verification parameters, and use the verification information to verify the authentication information.

[0115] When using the business invocation methods provided in this manual, authentication can be implemented during the business invocation process through aspect injection, effectively preventing the possibility of malicious business attacks. Furthermore, adding authentication functionality to each business will not affect the original functionality of each business, nor will it affect the normal online use of the business, achieving transparent authentication for each business and further ensuring a better user experience.

[0116] Even better, in the business invocation method provided in this specification, in addition to the aforementioned second application, first application, and management platform, an additional data acquisition module can be included. This module collects various data generated by the second and first applications during the business invocation process, such as timestamps, context parameters, and debugging data. Simply put, it monitors in real time what each service does, when, and what data it generates. When problems arise during authentication, the data collected by the data acquisition terminal can be used to analyze and resolve the issues. Even if no problems occur, the authentication performance can be evaluated offline based on the data collected by the data acquisition terminal, facilitating subsequent optimization and adjustments.

[0117] Figure 3 This document provides a flowchart illustrating a business invocation method applied to a second application, comprising the following steps:

[0118] S200: Inject the second aspect program sent by the management platform into the point of the second application through the pre-deployed aspect base, and configure the authentication parameters sent by the management platform for the second aspect program.

[0119] In this specification, the management and control platform is a separate application, distinct from the business applications. The structure of the management and control platform can be as follows: Figure 2 As shown in the diagram, the management platform includes aspect programs, business lists, pointcut lists, and management configurations. The methods for applying the management platform described in this manual have already provided detailed explanations of the functions and roles of each structure within the management platform, and will not be repeated here.

[0120] During the management phase, before each business is operational, the second aspect program sent by the management platform can be injected into the second application from the point of entry of the second application through the pre-deployed aspect base, and the authentication parameters sent by the management platform can be configured into the second aspect program in the second application.

[0121] S202: When a call request carrying business data is determined, the pre-injected second aspect program is executed to generate authentication information based on the pre-configured authentication parameters and the business data, wherein the call request is used to request the invocation of the first application.

[0122] In this step, when the second application needs to call functions from other business processes, it first generates a call request carrying business data. The generated call request is used to request a call to the first application, and the business data in the call request is used to enable the first application to execute the corresponding function based on the business data when responding to the call.

[0123] After the call request is determined, a pre-injected second aspect can be executed to implement the authentication function. When generating authentication information, the second aspect can be executed based on the authentication parameters and business data in the pre-injected second aspect. Specifically, the authentication parameters include at least a second signature content and a second signature method; based on the second signature content and using the second signature method, the business data is signed to obtain the authentication information.

[0124] Similar to signing in real-world scenarios, signing specified data involves adding extra data before or after the specified data. This extra data represents the identity of the business that generated the specified data to other businesses. This extra data is the signature content mentioned in this specification. Signature methods can include at least symmetric and asymmetric methods, which are common techniques in the field and will not be elaborated upon here.

[0125] As mentioned in step S102, the parameters may include signature content, signature method, and other parameters. Therefore, in step S200, the authentication parameters injected into the second application may at least include the second signature content and the second signature method. At this time, the second application can sign the business data according to the second signature content and the second signature method to obtain authentication information.

[0126] S204: The authentication information is sent to the first application along with the call request, so that the first application generates verification information through the first aspect program to verify the authentication information, and determines whether to respond to the call of the second application based on the verification result; wherein, the verification information is generated by the first application through the pre-injected first aspect program and the verification parameters pre-configured for the first aspect program, and the first aspect program is pre-injected into the first application through the aspect base.

[0127] In actual operation, regardless of whether authentication is required, the second application generates a call request carrying business data. This business data is used to request the first application to provide services to the second application. Without authentication, the second application would directly send the call request containing the business data to the first application according to the original call flow. However, in the business call method provided in this specification, the second application signs the business data through a second aspect program to obtain authentication information, and then sends the signed business data as authentication information in the call request to the first application.

[0128] Similarly, the first application also contains a pre-injected first aspect and verification parameters. When the first application receives a call request from the second application, it can execute the first aspect, generate verification information based on the verification parameters, use the verification information to verify the authentication information contained in the received call request, and decide whether to respond to the call from the second application based on the verification result.

[0129] Figure 4 This document provides a flowchart illustrating a business invocation method applied to a first application, comprising the following steps:

[0130] S300: By using a pre-deployed segmentation base, the first segmentation program sent by the management platform is injected into the segmentation point of the first application, and the verification parameters sent by the management platform are configured for the first segmentation program.

[0131] In the business invocation methods provided in this specification, the first application is the business being invoked. Similarly, during the management phase, before each business starts running, the first aspect program sent by the management platform can be injected into the first application from the pointcut of the first application through the pre-deployed aspect base, and the verification parameters sent by the management platform can be configured into the first aspect program.

[0132] S302: Receive a call request carrying authentication information sent by the second application. The authentication information is generated by the second application through a pre-injected second aspect program and authentication parameters pre-configured for the second aspect program. The call request is used to request to call the first application. The second aspect program is pre-injected into the second application through an aspect base.

[0133] For the first application, during the business call process, it will receive a call request carrying authentication information from the second application. The authentication information generated in the second application is also generated by the second aspect program that is pre-injected into the second application, which has been described in detail in step S202 and will not be repeated here.

[0134] S304: Execute the pre-injected first aspect procedure to generate verification information based on the authentication information and the pre-configured verification parameters.

[0135] Upon receiving a call request, the first application can execute a pre-injected first aspect program to generate verification information based on the authentication information carried in the call request and the verification parameters pre-configured for the first aspect program.

[0136] Similar to how the second application generates authentication information, the first application also generates authentication information by executing a first aspect procedure based on verification parameters. Specifically, the verification parameters include at least a first signature content and a first signature method. However, unlike the second application, the first application also relies on the second application's authentication information when generating authentication information. Specifically, the business data contained in the authentication information can be determined; based on the first signature content and using the first signature method, the business data is signed to obtain the authentication information.

[0137] As mentioned in step S106, regardless of whether authentication is required, the second application always generates business data to request the first application to perform functions during the execution of a business call. When authentication is required, the second application signs the business data and sends it as authentication information in the call request to the first application. At this time, the first application can extract the business data from the authentication information and re-sign the business data according to the first signature content and the first signature method to obtain the verification information.

[0138] S306: Verify the authentication information using the verification information, and determine whether to respond to the call of the second application based on the verification result.

[0139] After generating the verification information, the authentication information can be verified using the verification information, and the decision on whether to respond to the call from the second application can be made based on the verification result.

[0140] Specifically, the first application can determine whether the authentication information sent by the second application matches the verification information generated by the first application; if yes, it responds to the call from the second application; if no, it sends a verification failure message to the second application. Responding to the call from the second application can involve the first application executing a corresponding function based on business data and returning the result to the second application. Typically, the first application will use different logic for its judgment depending on the signature method in the authentication configuration.

[0141] Specifically, when the second application and the first application use asymmetric signatures for authentication, the authentication information generated in the second application is different from the verification information generated in the first application, but they are related and match each other. In this case, the authentication parameters and verification parameters generated by the management platform are also different, but they match each other.

[0142] In another scenario, when the second application and the first application use symmetric signatures for authentication, the authentication information generated in the second application can be the same as the verification information generated in the first application. In this case, the verification parameters are the same as the authentication parameters. When the first application determines whether the authentication information and the verification information match, it can directly determine whether the authentication information and the verification information are the same; if they are the same, then the authentication information and the verification information match; otherwise, the authentication information and the verification information do not match.

[0143] The management platform's configuration stores all parameters that might be used in the aspect-oriented programming (AOP), including but not limited to signature content, signature method, logical switches, and branch switching variables. The function of each parameter has been explained in detail in the business invocation methods applied to the management platform provided in this manual, and will not be repeated here. In practice, authentication and verification parameters are determined by the likelihood of the first application being invoked posing a security risk. In real-world applications, each business function is different. Some functions are very simple and do not touch core data; even if these functions are freely invoked, they will not have a significant impact on the business or the system. Therefore, for these types of first applications, simpler signature content and signature methods can be used for authentication. Conversely, some functions are more complex and involve more core data; it is generally undesirable for other businesses to invoke these functions. Therefore, for these types of first applications, more complex signature content and signature methods can be used for authentication.

[0144] During authentication, simpler authentication methods generally offer lower security and reliability compared to more complex methods, but they are faster and place less pressure on individual business processes. For example, asymmetric authentication offers higher security but is slower than symmetric authentication. Therefore, in practice, a single authentication method is rarely used exclusively; instead, the appropriate method is chosen based on the business being invoked. The user or system administrator can define which services require simpler authentication and which require more complex methods.

[0145] Furthermore, when there are no security risks at all during the invocation process in the first application, the authentication process can be skipped by setting a logic switch, as given in step S102.

[0146] The above describes one or more methods for implementing business invocation in this specification. Based on the same approach, this specification also provides corresponding business invocation devices, such as... Figure 5 , Figure 6 , Figure 7 As shown.

[0147] Figure 5 A schematic diagram of a service invocation device provided in this specification includes:

[0148] The business list generation module 400 determines each second application that needs to call the first application and generates a business list containing each second application.

[0149] The parameter determination module 402 determines the authentication parameters required by each second application in the service list when calling the first application, as well as the verification parameters required by the first application.

[0150] The second injection module 404 injects the second aspect program into the code corresponding to each second application in the business list through a pre-deployed aspect base, and configures the authentication parameters for the second aspect program, so that when the second application calls the first application, it generates authentication information based on the second aspect program and the authentication parameters, and sends a call request carrying the authentication information to the first application.

[0151] The first injection module 406 injects a first aspect program into the code corresponding to the first application through a pre-deployed aspect base, and configures the verification parameters for the first aspect program, so that when the first application receives the call request sent by the second application, it generates verification information based on the first aspect program and the verification parameters, and verifies the authentication information carried in the call request according to the verification information.

[0152] Optionally, the management platform stores a list of cutpoints that includes the cutpoints in each of the second applications and the first application;

[0153] The second injection module 404 is specifically used to determine the pointcut of each second application in the pointcut list; and to inject the second aspect program from the pointcut of each second application into the code corresponding to each second application.

[0154] The first injection module 406 is specifically used to determine the pointcut of the first application in the pointcut list; and to inject the first aspect program from the pointcut of the first application into the code corresponding to the first application.

[0155] Optionally, the parameter determination module 402 is specifically used to determine the second signature content and second signature method required by each second application in the business list of the first application when calling the first application, as well as the first signature content and first signature method required by the first application.

[0156] Figure 6 A schematic diagram of a service invocation device provided in this specification includes:

[0157] The authentication configuration module 500 injects the second aspect program sent by the management platform into the point of the second application through the pre-deployed aspect base, and configures the authentication parameters sent by the management platform for the second aspect program;

[0158] The authentication information generation module 502, when determining a call request carrying business data, executes the pre-injected second aspect program and generates authentication information according to the pre-configured authentication parameters and the business data, wherein the call request is used to request to call the first application;

[0159] The call request sending module 504 sends the authentication information along with the call request to the first application, so that the first application can verify the authentication information by generating verification information through the first aspect program, and determine whether to respond to the call of the second application based on the verification result; wherein, the verification information is generated by the first application through the pre-injected first aspect program and the verification parameters pre-configured for the first aspect program, and the first aspect program is pre-injected into the first application through the aspect base.

[0160] Optionally, the authentication parameters include at least the second signature content and the second signature method;

[0161] The authentication information generation module 502 is specifically used to sign the business data according to the second signature content and the second signature method to obtain authentication information.

[0162] Figure 7 A schematic diagram of a service invocation device provided in this specification includes:

[0163] The verification configuration module 600 injects the first aspect program sent by the management platform into the pointcut of the first application through the pre-deployed aspect base, and configures the verification parameters sent by the management platform for the first aspect program;

[0164] Call request receiving module 602 receives a call request carrying authentication information sent by the second application. The authentication information is generated by the second application through a pre-injected second aspect program and authentication parameters pre-configured for the second aspect program. The call request is used to request to call the first application. The second aspect program is pre-injected into the second application through the aspect base.

[0165] The verification information generation module 604 executes the pre-injected first aspect program to generate verification information based on the authentication information and the pre-configured verification parameters;

[0166] The verification module 606 verifies the authentication information using the verification information and determines whether to respond to the call of the second application based on the verification result.

[0167] Optionally, the verification parameters include at least the first signature content and the first signature method;

[0168] The verification information generation module 604 is specifically used to determine the business data contained in the authentication information; and to sign the business data according to the first signature content and the first signature method to obtain the verification information.

[0169] Optionally, the verification module 606 is specifically used to determine whether the authentication information matches the verification information; if yes, it responds to the call from the second application; if no, it sends a verification failure message to the second application.

[0170] Optionally, the verification parameters are the same as the authentication parameters;

[0171] The verification module 606 is specifically used to determine whether the authentication information and the verification information are the same; if they are the same, the authentication information and the verification information match; otherwise, the authentication information and the verification information do not match.

[0172] This specification also provides a computer-readable storage medium storing a computer program that can be used to execute the above-described... Figure 1 This provides a business invocation method.

[0173] This instruction manual also provides Figure 8 One of the corresponding Figure 1 A schematic diagram of the structure of an electronic device. (e.g.) Figure 8 At the hardware level, the electronic device includes a processor, internal bus, network interface, memory, and non-volatile memory, and may also include other hardware required for the business operations. The processor reads the corresponding computer program from the non-volatile memory into memory and then runs it to achieve the above-mentioned functions. Figure 1The described business invocation method. Of course, in addition to software implementation, this specification does not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. In other words, the execution subject of the following processing flow is not limited to individual logic units, but can also be hardware or logic devices.

[0174] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0175] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0176] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0177] For ease of description, the above devices are described in terms of function, divided into various units. Of course, in implementing this specification, the functions of each unit can be implemented in one or more software and / or hardware components.

[0178] Those skilled in the art will understand that embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this specification may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0179] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0180] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0181] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0182] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0183] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0184] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0185] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0186] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this specification may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0187] This specification can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This specification can also be practiced in distributed computing environments, where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0188] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0189] The above description is merely an embodiment of this specification and is not intended to limit this specification. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this specification.

Claims

1. A business invocation method, the method being applied to a management and control platform, the method comprising: Identify the second applications that need to call the first application, and generate a list of services that includes each of the second applications; Determine the authentication parameters required by each second application in the business list when calling the first application, and the verification parameters required by the first application; By pre-deploying the facet base, the second facet program is injected into the code corresponding to each second application in the business list, and the authentication parameters are configured for the second facet program. When the second application calls the first application, authentication information is generated based on the second facet program and the authentication parameters, and a call request carrying the authentication information is sent to the first application. By pre-deploying a facet base, the first facet program is injected into the code corresponding to the first application, and the verification parameters are configured for the first facet program. When the first application receives the call request sent by the second application, it generates verification information based on the first facet program and the verification parameters, and verifies the authentication information carried in the call request according to the verification information.

2. The method as described in claim 1, wherein the management platform stores a list of cutpoints including the cutpoints in each of the second applications and the first application; The second aspect procedure is injected into the code corresponding to each second application in the business list, specifically including: In the list of cut points, the cut points for each second application are determined; The second aspect program is injected from the point of cut of each of the second applications into the code corresponding to each of the second applications; Injecting the first aspect procedure into the code corresponding to the first application specifically includes: In the list of cut points, determine the cut point for the first application; The first aspect program is injected into the code corresponding to the first application from the point of view of the first application.

3. The method as described in claim 1, wherein determining the authentication parameters required by each second application in the service list of the first application when calling the first application, and the verification parameters required by the first application, specifically includes: Determine the second signature content and second signature method required by each second application in the business list of the first application when calling the first application, as well as the first signature content and first signature method required by the first application.

4. A business invocation method, the method being applied to a second application, the method comprising: By using a pre-deployed facet base, the second facet program sent by the control platform is injected into the point of the second application, and the authentication parameters sent by the control platform are configured for the second facet program. When a call request carrying business data is determined, the pre-injected second aspect program is executed to generate authentication information based on the pre-configured authentication parameters and the business data, wherein the call request is used to request the invocation of the first application; The authentication information is carried in the call request and sent to the first application, so that the first application generates verification information through the first aspect program to verify the authentication information, and determines whether to respond to the call of the second application based on the verification result; wherein, the verification information is generated by the first application through the pre-injected first aspect program and the verification parameters pre-configured for the first aspect program, and the first aspect program is pre-injected into the first application through the aspect base.

5. The method as described in claim 4, wherein the authentication parameters include at least the second signature content and the second signature method; Based on the pre-configured authentication parameters and the business data, authentication information is generated, specifically including: Based on the second signature content, the business data is signed using the second signature method to obtain authentication information.

6. A business invocation method, the method being applied to a first application, the method comprising: The first aspect program sent by the management platform is injected into the point of the first application through the pre-deployed aspect base, and the verification parameters sent by the management platform are configured for the first aspect program. The system receives a call request carrying authentication information sent by a second application. The authentication information is generated by the second application through a pre-injected second aspect program and authentication parameters pre-configured for the second aspect program. The call request is used to request to call the first application. The second aspect program is pre-injected into the second application through an aspect base. Execute the pre-injected first aspect procedure to generate verification information based on the authentication information and the pre-configured verification parameters; The authentication information is verified using the verification information, and the decision on whether to respond to the call from the second application is made based on the verification result.

7. The method as described in claim 6, wherein the verification parameters include at least the first signature content and the first signature method; Execute the pre-injected first aspect procedure to generate verification information based on the authentication information and the pre-configured verification parameters, specifically including: Determine the business data contained in the authentication information; Based on the first signature content, the first signature method is used to sign the business data to obtain verification information.

8. The method as described in claim 6, wherein the authentication information is verified using the verification information, and a determination is made based on the verification result as to whether to respond to the call from the second application, specifically includes: Determine whether the authentication information matches the verification information; If so, then respond to the call from the second application; If not, a verification failure message is sent to the second application.

9. The method as described in claim 8, wherein the verification parameters are the same as the authentication parameters; Determining whether the authentication information matches the verification information specifically includes: Determine whether the authentication information is the same as the verification information; If they are the same, then the authentication information matches the verification information; Otherwise, the authentication information does not match the verification information.

10. A service invocation device, comprising: The business list generation module determines each second application that needs to call the first application and generates a business list containing each second application. The parameter determination module determines the authentication parameters required by each second application in the business list when calling the first application, as well as the verification parameters required by the first application. The second injection module injects the second aspect program into the code corresponding to each second application in the business list through a pre-deployed aspect base, and configures the authentication parameters for the second aspect program, so that when the second application calls the first application, it generates authentication information based on the second aspect program and the authentication parameters, and sends a call request carrying the authentication information to the first application. The first injection module injects a first aspect program into the code corresponding to the first application through a pre-deployed aspect base, and configures the verification parameters for the first aspect program. When the first application receives the call request sent by the second application, it generates verification information based on the first aspect program and the verification parameters, and verifies the authentication information carried in the call request according to the verification information.

11. A service invocation device, comprising: The authentication configuration module injects the second aspect program sent by the management platform into the pointcut of the second application through the pre-deployed aspect base, and configures the authentication parameters sent by the management platform for the second aspect program; The authentication information generation module, when it determines a call request carrying business data, executes the pre-injected second aspect program and generates authentication information based on the pre-configured authentication parameters and the business data, wherein the call request is used to request the call of the first application; The call request sending module carries the authentication information in the call request and sends it to the first application, so that the first application generates verification information through the first aspect program to verify the authentication information, and determines whether to respond to the call of the second application based on the verification result; wherein, the verification information is generated by the first application through the pre-injected first aspect program and the verification parameters pre-configured for the first aspect program, and the first aspect program is pre-injected into the first application through the aspect base.

12. A service invocation device, comprising: The verification configuration module injects the first aspect program sent by the management platform into the pointcut of the first application through the pre-deployed aspect base, and configures the verification parameters sent by the management platform for the first aspect program; The call request receiving module receives a call request carrying authentication information sent by the second application. The authentication information is generated by the second application through a pre-injected second aspect program and authentication parameters pre-configured for the second aspect program. The call request is used to request to call the first application. The second aspect program is pre-injected into the second application through the aspect base. The verification information generation module executes the pre-injected first aspect program to generate verification information based on the authentication information and the pre-configured verification parameters; The verification module verifies the authentication information using the verification information and determines whether to respond to the call from the second application based on the verification result.

13. A computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in any one of claims 1 to 9.

14. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in any one of claims 1 to 9.

Images