WO2020248768A1

WO2020248768A1 - Method and apparatus for managing application program service

Info

Publication number: WO2020248768A1
Application number: PCT/CN2020/090687
Authority: WO
Inventors: 陈晔; 杜泽炜; 卢道和; 罗锶
Original assignee: 深圳前海微众银行股份有限公司
Priority date: 2019-06-11
Filing date: 2020-05-15
Publication date: 2020-12-17
Also published as: CN110289965A; CN110289965B

Abstract

Disclosed are a method and apparatus for managing an application program service. The method comprises: receiving a first message from a first sub-application program of an application program, the first message being used for requesting for obtaining a service from the application program; determining, according to the service indicated by the first message, a first sub-permission required for calling the service indicated by the first message; if the first sub-application program satisfies a preset condition, obtaining a first token according to the first sub-permission, the first sub-permission uniquely corresponding to the first token; and calling the service indicated by the first message by means of the application program according to the first token within the first sub-permission, and setting the first token to be in a locked state. When the method is applied to Fintech, the security of the application program in service is greatly improved, and conflicts are avoided.

Description

Method and device for managing application program service

Cross references to related applications

This application claims the priority of a Chinese patent application filed with the Chinese Patent Office, the application number is 201910499812.8, and the application name is "A management method and device for application services" on June 11, 2019, the entire content of which is incorporated by reference In this application.

Technical field

The present invention relates to the field of process control of financial technology (Fintech), in particular to a method and device for managing application program services.

Background technique

With the development of computer technology, more and more technologies (big data, distributed, Blockchain, artificial intelligence, etc.) are applied in the financial field, and the traditional financial industry is gradually transforming to Fintech. At present, in the field of financial technology, applications can provide a large number of services to users. In the prior art, some applications process a huge amount of data due to a large number of users, etc., so it often requires the cooperation of multiple departments to jointly manage this application. An application can contain multiple sub-applications. When a sub-application realizes a certain function or performs a certain service, it generally cannot be separated from the application itself. The sub-application also needs to use the application to realize the required services together.

But for applications, each sub-application is equal, and each sub-application can request services from the application, which may cause some sub-applications to cross their own business scope, and the request does not belong to the sub-application service department Services, which in turn affect other sub-applications. For example, sub-application A belongs to department A, and sub-application A needs to modify a certain value, but the modification of the value belongs to another department B, which needs to notify department B to provide services, but department A, for convenience, You can directly control the sub-application A to request the application to modify the value, and if department B needs to modify the value at the same time, it will easily cause conflicts. In the above manner, there are great security risks when the application performs services, and conflicts are difficult to avoid.

Summary of the invention

The embodiments of the present application provide a method and device for managing application services, which are used to solve the problem of great security risks and conflicts that are difficult to avoid when applications perform services in the prior art.

In a first aspect, an embodiment of the present application provides an application service management method, including: receiving a first message from a first sub-application of an application, the first message being used to request to obtain a service from the application Determining the first sub-permission required to invoke the service indicated by the first message according to the service indicated by the first message; the first sub-permission is a preset sub-permission in the service permission for invoking the application; If the first sub-application meets a preset condition, a first token is obtained according to the first sub-authority; the first token is a command to invoke the service authority within the first sub-authority The first sub-authority uniquely corresponds to the first token; according to the first token, within the first sub-authority, the service indicated by the first message is invoked by the application, And set the first token to a locked state.

In the above method, the first message is used to request to obtain the service from the application, and according to the service indicated by the first message, the first sub-authority required to invoke the service indicated by the first message is determined, and the first sub-right The permission is a sub-permission preset in the service permission for calling the application. If the first sub-application satisfies a preset condition, a first token is obtained according to the first sub-permission. The token is a token for invoking the service authority within the first sub-authority. Therefore, according to the first token, only within the first sub-authority, the first message indication can be performed through the application The service of the application program cannot be invoked through the first token outside the first sub-authority; in addition, because the first sub-authority uniquely corresponds to the first token, and the second When the service indicated by a message, the first token has been set to the locked state, then when the service indicated by the first message is performed, other sub-applications of the application cannot simultaneously obtain the first order by sending the message Therefore, the above method greatly improves the security of the application when performing services and avoids conflicts.

In an optional implementation manner, the preset condition is that the first sub-application is a sub-application in the white list of the application, and the white list of the application is used to indicate that it is authorized to be able to call all The sub-application of the service of the application.

In the above manner, the preset white list indicates the sub-applications authorized to call the service of the application, and the first sub-application is the sub-application in the white list of the application. Under preset conditions, the first token can be obtained, thereby improving the security of application services.

In an optional implementation manner, the first token is valid for a first preset time period after acquisition, if the first token is used during the process of invoking the service indicated by the first message through the application If a token fails, the service indicated by the first message is interrupted; the first token is updated, and the updated token of the first token is used as the second token; according to the second token , Re-invoke the service indicated by the first message through the application.

In the above manner, the first token is valid for a preset period of time after acquisition, and if the first token becomes invalid during the process of invoking the service indicated by the first message through the application, then The service indicated by the first message is interrupted, the first sub-authority is controlled by means of preset duration and timely interruption, and the first token is updated, and the updated token of the first token is used as the first token. The second token, according to the second token, re-invoke the service indicated by the first message through the application, and update the token in time, thereby improving the security of the application service.

In an optional implementation manner, if the first sub-application does not meet the preset condition, the first message is discarded, and alarm information is sent.

In the above manner, the verification is performed through the preset condition, and if the first sub-application does not meet the preset condition, that is, the verification fails, the first message is discarded, and warning information feedback is sent in time, Thereby improving the security of application services.

In an optional implementation manner, the method further includes: if it is determined that the application program has completed invoking the service indicated by the first message, unlocking the first token through the application program status.

In the above manner, if it is determined that the application program has completed the invocation of the service indicated by the first message, the application program is used to unlock the first token, so that other sub-applications can also obtain The first token, thereby enhancing the flexibility of application services.

In a second aspect, an embodiment of the present application provides an application service management apparatus, including: a receiving module, configured to receive a first message from a first sub-application of the application, and the first message is used to request a slave The application program obtains a service; a processing module, configured to determine, according to the service indicated by the first message, a first sub-authority required to call the service indicated by the first message; the first sub-authority is to call the application If the first sub-application meets a preset condition, obtain a first token according to the first sub-authority; the first token is in the first The token that calls the service permission within the sub-authority; the first sub-authority uniquely corresponds to the first token; according to the first token, within the first sub-authority, through the application Invoke the service indicated by the first message, and set the first token to a locked state.

In an optional implementation manner, the first token is valid for a preset period of time after acquisition, and the processing module is further configured to: if the service indicated by the first message is invoked through the application If the first token becomes invalid during the process, the service indicated by the first message is interrupted; the first token is updated, and the updated token of the first token is used as the second token; The second token re-invokes the service indicated by the first message through the application.

In an optional implementation manner, the processing module is further configured to: if the first sub-application does not meet the preset condition, discard the first message and send alarm information.

In an optional implementation manner, the processing module is further configured to: if it is determined that the application program has completed invoking the service indicated by the first message, release the first token through the application program The locked state.

For the beneficial effects of the above-mentioned second aspect and the embodiments of the second aspect, reference may be made to the beneficial effects of the above-mentioned first aspect and the embodiments of the first aspect, which will not be repeated here.

In a third aspect, an embodiment of the present application provides a computer device including a program or instruction, and when the program or instruction is executed, it is used to execute the methods of the first aspect and the embodiments of the first aspect.

In a fourth aspect, an embodiment of the present application provides a storage medium including a program or instruction, and when the program or instruction is executed, it is used to execute the methods of the first aspect and the embodiments of the first aspect.

Description of the drawings

FIG. 1 is a schematic diagram of a system architecture applicable to an application service management method in an embodiment of this application;

FIG. 2 is a schematic diagram of the process flow of an application service management method in an embodiment of this application;

3 is a schematic diagram of the architecture of token management in an application service management method in an embodiment of the application;

FIG. 4 is a schematic diagram of a process flow diagram of authorizing sub-applications in an application service management method in an embodiment of the application;

FIG. 5 is a schematic diagram of an authorization page in an application service management method in an embodiment of the application;

Fig. 6 is a schematic structural diagram of an application service management apparatus in an embodiment of the application.

Detailed ways

In order to better understand the above technical solutions, the above technical solutions will be described in detail below with reference to the drawings and specific implementations of the specification. It should be understood that the embodiments of the application and the specific features in the embodiments are detailed to the technical solutions of the application. Note, rather than limiting the technical solution of the present application, the embodiments of the present application and the technical features in the embodiments can be combined with each other if there is no conflict.

In the following description, the abbreviations involved are as follows: appId: the identity (Identification, ID) of the sub-application in the application; token: the token is the credential for invoking the application program interface, and an application interface must be obtained first AppKey: also called the secret key, the credential that the application provides to the sub-application to obtain the token.

In order to solve the problem of great security risks and conflicts when using programs for services in the prior art, as shown in FIG. 1, an embodiment of the present application provides a system architecture for the management of application services. The application service management method provided by the embodiment of this application is applied.

The system architecture shown in Figure 1 includes the following parts:

User layer: The user layer includes the sub-application system and the business system of the application. The sub-application system includes multiple sub-applications. Each sub-application can request services by sending messages to the application, and communicate with the application through the proxy layer, so as to perform the required services through the application, and the business system of the application is required The system implemented in service.

Proxy layer: The proxy layer is responsible for forwarding communication messages between the user layer and the service layer. The specific forwarding tool is not limited. For example, proxy servers such as nginx and squid are used to implement forwarding.

Service layer: The service layer includes sub-application program interface, service access layer, message forwarding module, interface agent, configuration management module, permission management module, token management module, service application layer, logging module, and permission control module. Among them, the sub-application program interface, the service access layer, the message forwarding module, and the interface agent are used to transmit the messages sent by the sub-application program to the application program. The message of the sub-application is first forwarded to the service access layer through the sub-application interface, and then sent to the message forwarding module through the service access layer, and then communicates with the application in the service application layer. The interface proxy is used to send messages that the application needs to send to the corresponding sub-application interface. The basic configuration information of each sub-application is stored in the configuration management, for example, the ID of the sub-application. Each sub-permission is separated from the service permissions of the application encapsulated in the permission management module. The token management module encapsulates the tokens corresponding to each sub-authority in the authorization management module. The authority control module is used to control authority and allow or prohibit corresponding execution actions. The logging module is used to record the processing of messages.

In the service layer, each application does not need additional configuration, and the configuration in the configuration management module in the service layer is directly used as the configuration of each application.

In the service layer, the service access layer is responsible for receiving messages and events, forwarding the messages and events to the service application layer for processing, and passing the message that needs to be returned or forwarded after the service application layer processing is completed through the interface proxy, after passing through the proxy layer Forward to sub-application or business system. The addition of the service access layer allows multiple message events to be processed indiscriminately by the business logic of the service application layer after processing, and the service application layer classifies and processes the forwarded messages and events. The service access layer can support simultaneous access of multiple sub-applications and smooth switching between sub-applications.

Database: Store information records of services performed by applications. The specific types of databases are not limited. For example, the databases are redis and kafka.

Operating environment: used to provide the operating foundation for the user layer, agent layer, service layer and database. For example, the operating environment is composed of the following components: Linux, springboot1.4 and tomcat8.

In the above system architecture, each application can be independent into a separate system or service, and at the same time, the token management module and configuration management of the service layer can be separated, and the modules communicate through the message bus. This architecture can also apply the application service management method proposed in the embodiments of the present application, so that each application program is relatively independent and does not affect each other, and the overall modularity of the small system coupled between modules is higher. After realizing the functions of fast access and permission separation, this service architecture can conveniently provide the relevant service capabilities of existing sub-applications to external business operators outside of the application through application access. When external business operators need to host their own sub-applications to the services of atomic applications, they can select the service permissions that need to be managed on the authorization page to complete the authorization operation and use the related services.

In the following, in conjunction with FIG. 2, a schematic flow diagram of the steps of an application service management method in an embodiment of the present application will be described in detail.

Step 201: Receive a first message from a first sub-application of the application.

The first message is a communication message for the first sub-application to request service from the application.

Step 202: According to the service indicated by the first message, determine the first sub-right required to invoke the service indicated by the first message.

The first sub-permission is a sub-permission preset in the service permission for calling the application program.

Step 203: If the first sub-application meets a preset condition, obtain a first token according to the first sub-authority; the first token is to call the service within the first sub-authority The permission token.

The first sub-authority uniquely corresponds to the first token.

Step 204: According to the first token, within the first sub-authority, call the service indicated by the first message through the application program, and set the first token to a locked state.

In step 202, for example, the message management is authorized to the sub-application A, and the user information query management is authorized to the sub-application B. The business system that obtains the token of the sub-application A only allows the message management operation, and Cannot query user information.

In addition, in addition to the above steps 201 to 204, there is an alternative implementation manner as follows:

The first token is stored in a first storage space of the processing device, the first storage space also stores a third token, and the third token is pre-converted in the same storage format as the first token Token, the third token is uniquely mapped to the second sub-authority preset in the service authority; the calling method of the token stored in the first storage space is the same.

It should be noted that the processing device here can be any device that can run an application program, for example, a computer device, a terminal device, etc., without limitation. The first storage space is also not limited, such as the memory in a computer device. When there are many separated sub-permissions, if the tokens corresponding to the sub-permissions are not stored uniformly but stored separately, it is easy to cause space redundancy for multiple storage tokens, and frequent switching of access to each storage space is required. Therefore, storing the pre-converted third token and the first token in the same storage format as the first token in the first storage space can improve the management efficiency of application services and make full use of scheduling resources.

Fig. 3 is a schematic diagram of the architecture of token management in an application service management method in an embodiment of the application. In the architecture shown in FIG. 3, multiple sub-applications are managed through the token management service at the same time, and the token management service can also include update services, query services, and monitoring services.

The application service management method may also include:

The first token is valid for a first preset time period after being acquired, and if the first token becomes invalid during the process of invoking the service indicated by the first message through the application program, all services are interrupted. The service indicated by the first message; update the first token, and use the updated token of the first token as the second token; according to the second token, recall through the application The service indicated by the first message.

The following is a specific example to illustrate the above method: each token corresponds to a validity period, for example, 2 hours; and after acquiring a new token, the old token will expire within a certain period of time, such as 10 minutes. The update service uses the program interface provided by the application to the sub-application to obtain the token. After the update service obtains the token, the token is stored locally and a valid time of no more than 2 hours is set. When the local token fails, the token is updated immediately To keep the local token always valid. The query service provides an interface for real-time querying of the latest tokens. At any time, the tokens queried through the token management service are always the same and valid. The monitoring service regularly checks whether the token is valid by actively calling the WeChat API, and immediately updates the token when it is found to be invalid, so as to avoid the token failure due to short-term WeChat failure or network reasons. The token hybrid management also converts the token obtained from the second sub-application into a token in the same format as the first token and saves it in the token management service, and uses the same update, query and detection strategy for it. The type field information is added while recording the token, and the token type is returned when querying the token. When multiple sub-applications access the application at the same time, the token management service is allowed to save and maintain multiple tokens at the same time, which can be obtained on demand during query.

In the above steps 201 to 203, another optional implementation manner is:

The preset condition is that the first sub-application is a sub-application in the white list of the application, and the white list of the application is used to indicate the sub-applications that are authorized to call the service of the application program. In the above manner, the preset white list indicates the sub-applications authorized to call the service of the application, and the first sub-application is the sub-application in the white list of the application. Under preset conditions, the first token can be obtained, thereby improving the security of application services.

The following describes in detail the process of obtaining authorization for the sub-application from the application with reference to Figs. 4 and 5. Fig. 4 is a schematic diagram of the steps of authorization for the sub-application in an application service management method in an embodiment of the application; Fig. 5 This is a schematic diagram of an authorization page in an application service management method in an embodiment of this application.

There are many schemes for specific implementation. Because the pre-authorization code needs to be obtained in real time, a more concise method is to provide an authorization jump page. When you need to authorize the official account and the applet, you can obtain the authorization code through the authorization jump page and Jump to the authorization page of the third party platform to proceed.

Step 401: The user enters the website.

The user of the sub-application can enter the component side website of the application by clicking on the website.

Step 402: Obtain a pre-authorization code.

The component side website obtains the pre-authorization code through the application program interface provided by the application program to enter the pre-authorization.

Step 403: Guide the user to enter the application component authorization page.

Users can authorize on the application component authorization page.

Step 404: Authorize the user.

Step 405: Return the verification code.

Step 404 After the authorization is successful, the application program authorizes the website to send a verification code to the component side website.

Step 406: Use the authorization code to obtain user information.

The component website uses the authorization code to obtain user information through the application interface.

In the foregoing implementation of the preset whitelist, the process of obtaining the first token according to the first message in step 201 may be:

According to the service indicated by the first message, determine the first sub-authority required to perform the service indicated by the first message, and determine that the first message comes from the first sub-application; determine the first The sub-application is a sub-application verified by the preset whitelist, and obtains the first token uniquely mapped to the first sub-authority.

Further, security can also be increased through the following implementations:

If the first sub-application does not meet the preset condition, discard the first message and send alarm information.

You can also increase flexibility through the following implementations:

If it is determined that the application program has completed invoking the service indicated by the first message, the application program is used to release the locked state of the first token.

As shown in FIG. 6, it is a schematic structural diagram of an application service management apparatus in an embodiment of this application.

An embodiment of the present application provides an application service management apparatus, including: a receiving module 601, configured to receive a first message from a first sub-application of an application, and the first message is used to request a request from the application Obtain service; processing module 602, configured to determine, according to the service indicated by the first message, the first sub-authority required to invoke the service indicated by the first message; the first sub-authority is the service for invoking the application The preset sub-permission in the permission; if the first sub-application meets the preset condition, a first token is obtained according to the first sub-permission; the first token is in the first sub-permission The token that calls the service authority within; the first sub-authority uniquely corresponds to the first token; according to the first token, within the first sub-authority, the application is called The service indicated by the first message, and set the first token to a locked state.

In an optional implementation manner, the first token is valid for a preset period of time after being acquired, and the processing module 602 is further configured to: if the first message indicated by the application is called When the first token becomes invalid during the service process, the service indicated by the first message is interrupted; the first token is updated, and the updated token of the first token is used as the second token; According to the second token, the service indicated by the first message is re-invoked through the application.

In an optional implementation manner, the processing module 602 is further configured to: if the first sub-application does not meet the preset condition, discard the first message and send alarm information.

In an optional implementation manner, the processing module 602 is further configured to: if it is determined that the application program has completed the invocation of the service indicated by the first message, release the first order through the application program The locked state of the card.

An embodiment of the application provides a computer device, including a program or instruction, when the program or instruction is executed, it is used to execute the application service management method and any optional method provided by the embodiment of the application.

The embodiment of the present application provides a storage medium including a program or instruction, and when the program or instruction is executed, it is used to execute the application service management method and any optional method provided by the embodiment of the present application.

Finally, it should be noted that those skilled in the art should understand that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, this application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, optical storage, etc.) containing computer-usable program codes.

This application is described with reference to the flow chart and/or block diagram of the method, device (system), and computer program product according to the application. It should be understood that each process and/or block in the flowchart and/or block diagram, and the combination of processes and/or blocks in the flowchart and/or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing equipment to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing equipment are generated It is a device that realizes the functions specified in one process or multiple blocks in the flowchart and/or one block or multiple blocks in the block diagram.

These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing equipment to work in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction device. The device implements the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.

Obviously, those skilled in the art can make various changes and modifications to the application without departing from the scope of the application. In this way, if these modifications and variations of this application fall within the scope of the claims of this application and their equivalent technologies, this application also intends to include these modifications and variations.

Claims

An application service management method, characterized in that it includes:

Receiving a first message from a first sub-application of the application, where the first message is used to request to obtain a service from the application;

Determine, according to the service indicated by the first message, the first sub-authority required for invoking the service indicated by the first message; the first sub-authority is a preset sub-authority in the service permission for invoking the application;

If the first sub-application meets a preset condition, a first token is obtained according to the first sub-authority; the first token is a command to invoke the service authority within the first sub-authority Card; the first sub-authority uniquely corresponds to the first token;

According to the first token, within the first sub-authority, call the service indicated by the first message through the application program, and set the first token to a locked state.
The method of claim 1, wherein the preset condition is that the first sub-application is a sub-application in a white list of the application, and the white list of the application is used to indicate A sub-application that is authorized to be able to call the service of the application.
The method according to claim 1 or 2, wherein the first token is valid for a preset period of time after acquisition, and the method further comprises:

If the first token becomes invalid during the process of invoking the service indicated by the first message through the application program, interrupt the service indicated by the first message;

Updating the first token, and using the updated token of the first token as the second token;

According to the second token, the service indicated by the first message is re-invoked through the application.
The method according to claim 1 or 2, wherein the method further comprises:

If the first sub-application does not meet the preset condition, discard the first message and send alarm information.
The method according to claim 1 or 2, wherein after setting the first token to the locked state, the method further comprises:

If it is determined that the application program has completed invoking the service indicated by the first message, the application program is used to release the locked state of the first token.
An application service management device, characterized in that it comprises:

A receiving module, configured to receive a first message from a first sub-application of the application, the first message being used to request to obtain a service from the application;

The processing module is configured to determine, according to the service indicated by the first message, the first sub-authority required to invoke the service indicated by the first message; the first sub-authority is preset in the service authority for invoking the application If the first sub-application meets a preset condition, obtain a first token according to the first sub-authority; the first token is to call the first sub-authority within the The token of the service authority; the first sub-authority uniquely corresponds to the first token; according to the first token, within the first sub-authority, the first message is called by the application Indicates the service and sets the first token to the locked state.
The device according to claim 6, wherein the preset condition is that the first sub-application is a sub-application in a white list of the application, and the white list of the application is used to indicate A sub-application that is authorized to be able to call the service of the application.
The device according to claim 6 or 7, wherein the first token is valid for a preset period of time after acquisition, and the processing module is further configured to:

If the first token becomes invalid during the process of invoking the service indicated by the first message through the application program, interrupt the service indicated by the first message;

Updating the first token, and using the updated token of the first token as the second token;

According to the second token, the service indicated by the first message is re-invoked through the application.
A computer device characterized by comprising a program or an instruction, and when the program or an instruction is executed, the method according to any one of claims 1 to 5 is executed.
A storage medium, characterized by comprising a program or instruction, and when the program or instruction is executed, the method according to any one of claims 1 to 5 is executed.