Configuration-free interface permission verification method, device and system

Abstract

This invention provides a configuration-free interface permission verification method, apparatus, and system applied to a front-end system. In response to login operations, it retrieves a generated HTTP message header and a random number. The HTTP message header contains a user token returned by the back-end system, and the back-end system has correspondingly stored the user token and the random number. In response to access operations targeting a control on the front-end page, it uses the random number to encrypt the URL address and parameters of the API interface called by the target control, and adds the encrypted string to the HTTP message header. It then sends an HTTP request carrying the HTTP message header to the back-end system, enabling the back-end system to: determine a random number based on the user token in the HTTP message header; decrypt the encrypted string in the HTTP message header using the random number, and compare the decrypted URL address and parameters with the URL address and parameters of the queried API interface; if they match, the HTTP request is executed; otherwise, the HTTP request is rejected.

Description

Technical Field

[0001] This invention relates to the field of software technology, and more specifically, to a configuration-free interface permission verification method, apparatus, and system. Background Technology

[0002] Access control is a crucial part of system development. With the evolution of business and technology, front-end and back-end separation has become a very popular development model. In this model, user access control is divided into two parts: the front-end page controls user permissions for page functions, buttons, and controls; the back-end system verifies the access permissions of back-end APIs (Application Programming Interfaces) called by controls on the page.

[0003] The entire business system needs to provide functional permission maintenance for two main parts: page function permissions, page button permissions, page control usage permissions, and backend API interface access permissions. These two types of permission data need to be assigned to users' functional permission lists. In practical applications, a single page may display a large amount of data and access numerous API interfaces; in typical systems, the number of API interfaces can be dozens of times the number of pages. Maintaining API interface functional permissions becomes extremely cumbersome, with each new page adding significant amounts of data to the backend API interfaces requiring maintenance. Summary of the Invention

[0004] In view of this, to solve the above problems, the present invention provides a configuration-free interface permission verification method, apparatus, and system, the technical solution of which is as follows:

[0005] A configuration-free interface permission verification method, applied to a front-end system, the method comprising:

[0006] In response to a login operation, the system retrieves the generated HTTP message header and random number. The HTTP message header contains a user token, which is returned by the backend system and has been stored in the backend system along with the random number.

[0007] In response to an access operation to a target control on the front-end page, the URL address and parameters of the API interface called by the target control are encrypted using the random number, and the encrypted string obtained is added to the HTTP message header;

[0008] Send an HTTP request carrying the HTTP header to the backend system so that the backend system:

[0009] The random number is determined based on the user token in the HTTP message header; the encrypted string in the HTTP message header is decrypted using the random number, and the decrypted URL address and parameters are compared with the URL address and parameters of the queried API interface; if they are the same, the HTTP request is executed; if they are different, the HTTP request is rejected.

[0010] Preferably, the process of generating the HTTP message header and the random number includes:

[0011] Obtain login information and send the login information to the backend system so that the backend system can verify the login information;

[0012] Receive the user token returned by the backend system when the login information verification is successful, and set the user token in the HTTP message header;

[0013] The random number is generated and sent to the backend system so that the backend system stores the user token and the random number in its backend cache.

[0014] A configuration-free interface permission verification device, the device comprising:

[0015] The login response module is used to respond to login operations and retrieve the generated HTTP message header and random number. The HTTP message header contains a user token, which is returned by the backend system and the backend system has stored the user token and the random number accordingly.

[0016] The access response module is used to respond to access operations targeting a target control on the front-end page. It encrypts the URL address and parameters of the API interface called by the target control using the random number, and adds the encrypted string to the HTTP message header. It then sends an HTTP request carrying the HTTP message header to the back-end system, enabling the back-end system to:

[0017] The random number is determined based on the user token in the HTTP message header; the encrypted string in the HTTP message header is decrypted using the random number, and the decrypted URL address and parameters are compared with the URL address and parameters of the queried API interface; if they are the same, the HTTP request is executed; if they are different, the HTTP request is rejected.

[0018] Preferably, the process by which the login response module generates the HTTP message header and the random number includes:

[0019] Obtain login information and send the login information to the backend system so that the backend system can verify the login information; receive the user token returned by the backend system when the login information is verified and set the user token in the HTTP message header; generate the random number and send the random number to the backend system so that the backend system stores the user token and the random number in its backend cache.

[0020] A configuration-free interface permission verification method, applied to a backend system, the method comprising:

[0021] The system receives an HTTP request sent by the front-end system. The HTTP request carries an HTTP header containing a user token and an encrypted string. The encrypted string is obtained by the front-end system in response to an access operation of a target control on the front-end page, which uses a random number to encrypt the URL address and parameters of the API interface called by the target control. The random number and the HTTP header containing the user token are retrieved by the front-end system in response to a login operation. The user token is returned by the back-end system, and the back-end system has stored the user token and the random number accordingly.

[0022] The random number is determined based on the user token in the HTTP message header;

[0023] The encrypted string in the HTTP message header is decrypted using the random number, and the obtained URL address and parameters are compared with the URL address and parameters of the queried API interface.

[0024] If the two are the same, then execute the HTTP request;

[0025] If the two are different, the HTTP request is rejected.

[0026] Preferably, the method further includes:

[0027] If the two are different, an error message is returned to the front-end system so that the front-end system outputs the error message.

[0028] A configuration-free interface permission verification device, the device comprising:

[0029] The request receiving module is used to receive HTTP requests sent by the front-end system. The HTTP request carries an HTTP message header containing a user token and an encrypted string. The encrypted string is obtained by the front-end system using a random number to encrypt the URL address and parameters of the API interface called by the target control in response to the access operation of the target control on the front-end page. The random number and the HTTP message header containing the user token are retrieved by the front-end system in response to the login operation. The user token is returned by the back-end system, and the back-end system has stored the user token and the random number accordingly.

[0030] The authorization verification module is used to determine the random number based on the user token in the HTTP message header; use the random number to decrypt the encrypted string in the HTTP message header, and compare the decrypted URL address and parameters with the URL address and parameters of the queried API interface; if they are the same, the HTTP request is executed; if they are different, the HTTP request is rejected.

[0031] Preferably, the permission verification module is further used for:

[0032] If the two are different, an error message is returned to the front-end system so that the front-end system outputs the error message.

[0033] A configuration-free interface permission verification system is provided, comprising a front-end system and a back-end system, wherein the front-end system is used to execute the configuration-free interface permission verification method, and the back-end system is used to execute the configuration-free interface permission verification method.

[0034] Compared with the prior art, the beneficial effects achieved by the present invention are as follows:

[0035] This invention provides a configuration-free interface permission verification method, apparatus, and system applied to a front-end system. In response to login operations, it retrieves a generated HTTP message header and a random number. The HTTP message header contains a user token returned by the back-end system, and the back-end system has correspondingly stored the user token and the random number. In response to access operations targeting a control on the front-end page, it uses the random number to encrypt the URL address and parameters of the API interface called by the target control, and adds the encrypted string to the HTTP message header. It then sends an HTTP request carrying the HTTP message header to the back-end system, enabling the back-end system to: determine a random number based on the user token in the HTTP message header; decrypt the encrypted string in the HTTP message header using the random number, and compare the decrypted URL address and parameters with the URL address and parameters of the queried API interface; if they match, the HTTP request is executed; otherwise, the HTTP request is rejected. This invention eliminates the need for API interface permission configuration. Users only need to configure the functional permissions of the front-end page, reducing the workload of system configuration personnel in configuring system permissions, saving operation and maintenance costs, and eliminating the need for the back-end system to verify whether the current user has access permissions for each API interface call. While ensuring system security, it greatly improves efficiency. Attached Figure Description

[0036] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0037] Figure 1 A flowchart illustrating the configuration-free interface permission verification method provided in this embodiment of the invention;

[0038] Figure 2 Signaling flowchart of the configuration-free interface permission verification method provided in the embodiments of the present invention;

[0039] Figure 3 This is a schematic diagram of access control provided in an embodiment of the present invention;

[0040] Figure 4 A schematic diagram of the structure of the configuration-free interface permission verification device provided in an embodiment of the present invention;

[0041] Figure 5 A flowchart illustrating another configuration-free interface permission verification method provided in this embodiment of the invention;

[0042] Figure 6 This is a schematic diagram of another configuration-free interface permission verification device provided in an embodiment of the present invention. Detailed Implementation

[0043] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0044] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0045] To facilitate understanding of this invention, the relevant concepts involved in this invention are explained below:

[0046] Front-end and back-end separation: A very popular development model that clarifies the division of labor in a project: the back-end is responsible for processing and storing data; the front-end is responsible for displaying data. Front-end and back-end developers exchange data through API interfaces.

[0047] Front-end: This refers to the front-end part of a website, which is the webpage displayed to the user on a PC browser.

[0048] Backend: The system responsible for accessing, processing, and storing data.

[0049] API interface: The way for front-end and back-end to interact. In the front-end and back-end separation mode, the HTTP + JSON method is generally used.

[0050] Request Header: Also known as an HTTP header, it represents fields used to convey additional information in an HTTP request or response. HTTP headers accurately describe the resource being retrieved, the server's or client's behavior, and define specific operation parameters within an HTTP transaction.

[0051] HTTP interceptors: Interceptors that block or modify HTTP requests or responses.

[0052] Access control: After a user logs in, the permissions they are allowed to access, such as which pages they are permitted to access and which APIs they are allowed to request, are set by the administrator. Only users with the appropriate permissions can browse pages and access and call API interfaces. Permissions are the scope of restrictions on rights.

[0053] Token: A token generated by the user, typically used for authentication in a front-end / back-end separation model.

[0054] Symmetric encryption: The sender processes the plaintext (original data) and encryption key together using a special encryption algorithm, transforming it into complex encrypted ciphertext before sending it out. The receiver, upon receiving the ciphertext, needs to use the same encryption key and the inverse algorithm of the same encryption method to decrypt the ciphertext and recover the readable plaintext.

[0055] With the development of business and technology, the front-end technology stack has become increasingly rich, leading most systems to adopt a front-end / back-end separation development model. This model has become very popular, making project division of labor clearer: the back-end is responsible for processing and storing data; the front-end is responsible for displaying data. Front-end and back-end developers exchange data through API interfaces.

[0056] In a front-end / back-end separated development model, user access control is divided into two parts. The front-end page is responsible for controlling users' page function permissions, page button permissions, and page control usage permissions. The back-end system needs to verify the access permissions of back-end API interfaces called by controls on the page. Based on the front-end / back-end separated model, the system needs to provide access control maintenance for both parts: front-end page access permissions and back-end API interface access permissions, and assign these two sets of permission data to the user's access permission list so that users can securely access the system.

[0057] In a front-end / back-end separation model, the traditional permission verification process is as follows: A user accesses the system login page, enters their username and password, and upon successful login, the back-end system returns a list of the user's functional permissions and a token to authenticate the user's identity to the front-end system. The front-end system obtains the user's list of functional permissions and displays the corresponding page to the user based on the data in the list. When a user accesses a page, the page needs to query data through the back-end API. The page initiates an API request, typically by placing the user's token in the Request Header and sending it to the back-end system. The back-end system uses the user token to verify the user's identity, then queries the user's list of API interface permissions to verify whether the user can access the current API interface.

[0058] In practical applications, a single page may display a large amount of data and access numerous API interfaces, often dozens of times more than the number of pages. Furthermore, this data needs to be synchronized and maintained across development, testing, UAT (User Acquisition), and production environments. If some data is missing, preventing users from accessing it, troubleshooting requires meticulously checking the maintained page function list and the backend API list, significantly increasing the difficulty of problem finding. Each time a user accesses a backend API interface, the backend system must query and filter through a vast list of API interfaces to determine if the user has the necessary permissions. When the number of API interfaces is large, this matching and verification process can also impose a significant performance burden on the system.

[0059] See Figure 1 , Figure 1 The flowchart illustrates a configuration-free interface permission verification method provided in this embodiment of the invention. This configuration-free interface permission verification method is applied to a front-end system and includes the following steps:

[0060] S101, responding to the login operation, retrieves the generated HTTP message header and random number. The HTTP message header contains a user token, which is returned by the backend system, and the backend system has already stored the user token and random number.

[0061] In this embodiment of the invention, when a user logs in for the first time, the front-end system can send the login information to the back-end system for verification. The back-end system then returns a user token to the front-end system. The front-end system then generates a random number and sets it in the HTTP message header. This ensures that the user token is included in the HTTP message header (i.e., the request header) of every subsequent HTTP request, and the random number can be sent to the back-end system via an HTTP request carrying the HTTP message header. Upon receiving the random number and the user token (i.e., the HTTP request header), the back-end system caches the mapping between the random number and the user token (i.e., the token) in its back-end cache.

[0062] When a user logs in subsequently, the HTTP message header containing the user token (i.e., Token) and a random number can be retrieved.

[0063] In the specific implementation process, the generation of HTTP message headers and random numbers includes the following steps:

[0064] Obtain login information and send it to the backend system so that the backend system can verify the login information;

[0065] Receive the user token returned by the backend system after successful login information verification, and set the user token in the HTTP message header;

[0066] Generate a random number and send it to the backend system so that the backend system stores the user token and the random number in its backend cache.

[0067] See Figure 2 , Figure 2 This is a signaling flowchart for the configuration-free interface permission verification method provided in this embodiment of the invention. The front-end system can consist of a front-end framework and front-end pages, while the back-end system can consist of a back-end permission management service and a back-end API service.

[0068] Users log in to the system through the front-end framework. The back-end permission management service verifies the username and password. Upon successful verification, it generates a user token for the user based on the username and login time, confirms successful login, and returns the user token to the front-end framework. The front-end framework, upon receiving the user token, uses an HTTP interceptor to set it in the HTTP request header, ensuring that subsequent HTTP requests include the user token in their headers. The front-end framework then generates a random number and sends it to the back-end permission management service via an HTTP request. The back-end permission management service receives the random number and the user token from the HTTP request and caches the mapping between the random number and the user token in its back-end cache.

[0069] S102, responding to the access operation of the target control on the front-end page, encrypts the URL address and parameters of the API interface called by the target control using a random number, and adds the encrypted string obtained by encryption to the HTTP message header.

[0070] This invention does not require maintaining a list of API interfaces; it only needs to maintain a list of permissions for the front-end page. When a user is assigned permissions for the front-end page and the controls on that page, the user can access the front-end page and the controls on that page.

[0071] When a control on the front-end page (i.e., the target control) calls a back-end API interface, it first encrypts the URL (Uniform Resource Locator) address and parameters of the API interface to be requested. The resulting encrypted string is sent to the back-end system along with the HTTP request header. Thus, by adding HTTP request interception processing to the front-end system, a user token and the encrypted string (i.e., the encrypted URL address and parameters) are added to the HTTP request header sent to the back-end system.

[0072] See also Figure 2 When a user accesses data on the front-end page, the front-end page uses a random number generated after the user logs in as a key, employing a symmetric encryption algorithm to encrypt the URL address and parameters of the upcoming HTTP request. The encrypted string is then added to a field in the HTTP request header, and the request is forwarded to the back-end system upon API access. The following are the main processing steps of the front-end system's HTTP interception:

[0073] Obtain the user token for this login session; obtain the generated random number; symmetrically encrypt the URL address and parameters using the random number as the key to generate the encrypted string ApiKeys.

[0074] All HTTP requests sent through the front-end system are intercepted by the HTTP interceptor. The user token and the encrypted string "ApiKeys" are then added to the HTTP request header before being sent to the back-end system. Specifically, the encrypted string "ApiKeys" is assigned to the Header field of the HTTP request header.

[0075] S103, send an HTTP request with HTTP headers to the backend system so that the backend system:

[0076] A random number is determined based on the user token in the HTTP message header; the encrypted string in the HTTP message header is decrypted using the random number, and the decrypted URL address and parameters are compared with the URL address and parameters of the queried API interface; if they are the same, the HTTP request is executed; if they are different, the HTTP request is rejected.

[0077] In this embodiment of the invention, for API interfaces that store the association between user tokens and random numbers, the backend system does not verify the specific content of the encrypted string ApiKeys, but only verifies the user token (i.e., Token).

[0078] The backend system intercepts the HTTP request, first retrieving the URL and parameters of the HTTP request for the currently accessing API interface. Then, it decrypts the encrypted string `ApiKeys` in the HTTP request header (i.e., the Request Header) to obtain the original URL and parameters of the API request before encryption. It then compares the two sets of data for verification. In this way, the backend system doesn't need to determine if the user has permission to access the API interface; it only needs to verify if the encrypted string `ApiKeys` in the HTTP request header matches the currently accessed API interface. This verifies whether the user has permission to access the API interface, whether the user has modified the URL and parameters without authorization, and whether they have unauthorized access to the API interface. The above process ensures that calling the backend API always sends the encrypted string `ApiKeys`, and that the encrypted string `ApiKeys` must be generated within a trusted frontend system. This guarantees that when the frontend system calls the backend API interface, it doesn't need to verify pre-defined permissions; it only needs to verify the encrypted string.

[0079] See also Figure 2The front-end page accesses the API interface and sends an HTTP request to the back-end permission management service; the back-end permission management service intercepts this HTTP request and analyzes the HTTP message header (i.e., Request header) carried in the HTTP request. The user token is obtained from the HTTP header. The backend cache is then queried using this token to retrieve a random number generated after the current user logs in. This random number is used as a key to decrypt the encrypted string `ApiKeys` in the HTTP header's Header field. If `ApiKeys` is empty, an error is returned to the frontend page, which then displays the error message. The backend permission management service retrieves the HTTP request's URL and parameters through the web server's API and compares them with the decrypted URL and parameters. If both the retrieved and decrypted URLs and parameters match perfectly, the HTTP request is executed, and access to the backend API resources is granted. If either the retrieved or decrypted URL or parameters do not match perfectly, the HTTP request fails and is terminated.

[0080] Of course, if the URL address found is not exactly the same as the URL address obtained through decryption, or if the parameters found are not exactly the same as the parameters obtained through decryption, the backend permission management service can also report an error and return an error message to the frontend page while refusing to execute the HTTP request. The frontend page will then output the error message through page rendering.

[0081] Through the above methods, this invention enables API interface permission verification and management without requiring users to maintain and configure backend API interface permissions, effectively saving manpower costs for system configuration personnel. Furthermore, because configuration is unnecessary, permission configuration information does not need to be stored, thus avoiding database resource consumption, synchronization across different environments, and preventing issues with query, filtering, and processing efficiency due to excessive permission data volume. See also Figure 3 , Figure 3 This is a schematic diagram of access control provided for an embodiment of the present invention. Figure 3 As shown, the system only needs to control user permissions for pages and functions on those pages. For users, what they see is what they get; the page functions a user can access correspond to API access permissions. Furthermore, it ensures that users cannot access API interfaces beyond their authorized privileges.

[0082] The configuration-free interface permission verification method provided in this embodiment of the invention has the following advantages:

[0083] 1) The API interface permission list does not need to be maintained, nor does it need to maintain the association between users and API interfaces, which greatly reduces the workload of system configuration personnel and ensures the security of data access.

[0084] 2) When the backend verifies API permissions, it does not need to read permission configuration data, filter permission data by user ID, or query the database, thus improving the efficiency of permission verification.

[0085] 3) Random key encryption is used. The random key is generated on the client's front end after authentication, and the back end stores the association between the authenticated user and the random key. This ensures that encryption can only be generated on trusted clients, guaranteeing the security of the API interface. Issues such as untrusted clients accessing the API, users modifying access parameters privately through technical means after authentication, and users accessing the API without authorization can all be resolved.

[0086] Based on the configuration-free interface permission verification method provided in the above embodiments, this invention provides an apparatus for executing the configuration-free interface permission verification method, the structural diagram of which is shown below. Figure 4 As shown, it includes:

[0087] The login response module 101 is used to respond to login operations, retrieve the generated HTTP message header and random number. The HTTP message header contains a user token, which is returned by the backend system and has been stored in the backend system along with the user token and random number.

[0088] Access response module 102 is used to respond to access operations targeting the target control on the front-end page. It encrypts the URL address and parameters of the API interface called by the target control using a random number, and adds the encrypted string to the HTTP message header. It then sends an HTTP request carrying the HTTP message header to the back-end system so that the back-end system can:

[0089] A random number is determined based on the user token in the HTTP message header; the encrypted string in the HTTP message header is decrypted using the random number, and the decrypted URL address and parameters are compared with the URL address and parameters of the queried API interface; if they are the same, the HTTP request is executed; if they are different, the HTTP request is rejected.

[0090] Optionally, the process of the login response module 101 generating the HTTP message header and random number includes:

[0091] Obtain login information and send it to the backend system for verification; receive the user token returned by the backend system if the login information is verified, and set the user token in the HTTP message header; generate a random number and send it to the backend system so that the backend system stores the user token and the random number in its backend cache.

[0092] It should be noted that the detailed functions of each module in the embodiments of the present invention can be found in the corresponding disclosure of the above-mentioned configuration-free interface permission verification method embodiments, and will not be repeated here.

[0093] Based on the configuration-free interface permission verification method provided in the above embodiments, this invention also provides another configuration-free interface permission verification method. This configuration-free interface permission verification method is applied to a backend system, and the method flowchart is as follows. Figure 5 As shown, it includes the following steps:

[0094] S201, Receive an HTTP request sent by the front-end system. The HTTP request carries an HTTP header containing a user token and an encrypted string. The encrypted string is obtained by the front-end system in response to the access operation of the target control on the front-end page, which uses a random number to encrypt the URL address and parameters of the API interface called by the target control. The random number and the HTTP header with the user token are retrieved by the front-end system in response to the login operation. The user token is returned by the back-end system, and the back-end system has already stored the user token and the random number.

[0095] S202, determine a random number based on the user token in the HTTP message header.

[0096] S203, use a random number to decrypt the encrypted string in the HTTP message header, and compare the decrypted URL address and parameters with the URL address and parameters of the queried API interface.

[0097] S204 If the two are the same, then execute the HTTP request.

[0098] S205: If the two are different, the HTTP request will be rejected.

[0099] The above method also includes the following steps:

[0100] If the two are different, return an error message to the front-end system so that the front-end system can output an error message.

[0101] It should be noted that the detailed implementation of each step in the embodiments of the present invention can be found in the corresponding disclosure of the above-mentioned configuration-free interface permission verification method embodiments, and will not be repeated here.

[0102] Based on the configuration-free interface permission verification method provided in the above embodiments, this invention provides an apparatus for executing the configuration-free interface permission verification method, the structural diagram of which is shown below. Figure 6 As shown, it includes:

[0103] The request receiving module 201 is used to receive the HTTP request sent by the front-end system. The HTTP request carries an HTTP message header containing a user token and an encrypted string. The encrypted string is obtained by the front-end system using a random number to encrypt the URL address and parameters of the API interface called by the target control in response to the access operation of the target control on the front-end page. The random number and the HTTP message header with the user token set are retrieved by the front-end system in response to the login operation. The user token is returned by the back-end system, and the back-end system has stored the user token and the random number accordingly.

[0104] The authorization verification module 202 is used to determine a random number based on the user token in the HTTP message header; use the random number to decrypt the encrypted string in the HTTP message header, and compare the decrypted URL address and parameters with the URL address and parameters of the queried API interface; if they are the same, the HTTP request is executed; if they are different, the HTTP request is rejected.

[0105] Optionally, the permission verification module 202 is also used for:

[0106] If the two are different, return an error message to the front-end system so that the front-end system can output an error message.

[0107] It should be noted that the detailed implementation of each step in the embodiments of the present invention can be found in the corresponding disclosure of the above-mentioned configuration-free interface permission verification method embodiments, and will not be repeated here.

[0108] This invention also provides a configuration-free interface permission verification system, which includes a front-end system and a back-end system. The front-end system is used to execute its corresponding configuration-free interface permission verification method, and the back-end system is used to execute its corresponding configuration-free interface permission verification method.

[0109] The foregoing has provided a detailed description of the configuration-free interface permission verification method, apparatus, and system provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

[0110] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.

[0111] It should also be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that elements inherent to a process, method, article, or apparatus that comprises a list of elements, or elements inherent to such processes, methods, articles, or apparatus, are also included. Without further limitations, 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.

[0112] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A configuration-free interface permission verification method, characterized in that, The method is applied to a front-end system, and the method includes: In response to a login operation, the system retrieves the generated HTTP message header and a random number. The HTTP message header contains a user token, which is returned by the backend system and has been stored in the backend system along with the random number. In response to an access operation to a target control on the front-end page, the URL address and parameters of the API interface called by the target control are encrypted using the random number, and the encrypted string obtained is added to the HTTP message header; Send an HTTP request carrying the HTTP header to the backend system so that the backend system: The random number is determined based on the user token in the HTTP message header; the encrypted string in the HTTP message header is decrypted using the random number, and the decrypted URL address and parameters are compared with the URL address and parameters of the queried API interface; if they are the same, the HTTP request is executed; if they are different, the HTTP request is rejected. The process of generating the HTTP message header and the random number includes: Obtain login information and send the login information to the backend system so that the backend system can verify the login information; Receive the user token returned by the backend system when the login information verification is successful, and set the user token in the HTTP message header; The random number is generated and sent to the backend system so that the backend system stores the user token and the random number in its backend cache.

2. A configuration-free interface permission verification device, characterized in that, The device is used in a front-end system, and the device includes: The login response module is used to respond to login operations and retrieve the generated HTTP message header and random number. The HTTP message header contains a user token, which is returned by the backend system and the backend system has stored the user token and the random number accordingly. The access response module is used to respond to access operations targeting a target control on the front-end page. It encrypts the URL address and parameters of the API interface called by the target control using the random number, and adds the encrypted string to the HTTP message header. It then sends an HTTP request carrying the HTTP message header to the back-end system, enabling the back-end system to: The random number is determined based on the user token in the HTTP message header; the encrypted string in the HTTP message header is decrypted using the random number, and the decrypted URL address and parameters are compared with the URL address and parameters of the queried API interface; if they are the same, the HTTP request is executed; if they are different, the HTTP request is rejected. The process by which the login response module generates the HTTP message header and the random number includes: Obtain login information and send the login information to the backend system so that the backend system can verify the login information; receive the user token returned by the backend system when the login information is verified and set the user token in the HTTP message header; generate the random number and send the random number to the backend system so that the backend system stores the user token and the random number in its backend cache.

3. A configuration-free interface permission verification method, characterized in that, The method is applied to a backend system, and the method includes: The system receives an HTTP request sent by the front-end system. The HTTP request carries an HTTP header containing a user token and an encrypted string. The encrypted string is obtained by the front-end system in response to an access operation of a target control on the front-end page, which uses a random number to encrypt the URL address and parameters of the API interface called by the target control. The random number and the HTTP header containing the user token are retrieved by the front-end system in response to a login operation. The user token is returned by the back-end system, and the back-end system has stored the user token and the random number accordingly. The random number is determined based on the user token in the HTTP message header; The encrypted string in the HTTP message header is decrypted using the random number, and the obtained URL address and parameters are compared with the URL address and parameters of the queried API interface. If the two are the same, then execute the HTTP request; If the two are different, the HTTP request is rejected. The method further includes: If the two are different, an error message is returned to the front-end system so that the front-end system outputs the error message.

4. A configuration-free interface permission verification device, characterized in that, The device is used in a backend system, and the device includes: The request receiving module is used to receive HTTP requests sent by the front-end system. The HTTP request carries an HTTP message header containing a user token and an encrypted string. The encrypted string is obtained by the front-end system using a random number to encrypt the URL address and parameters of the API interface called by the target control in response to the access operation of the target control on the front-end page. The random number and the HTTP message header containing the user token are retrieved by the front-end system in response to the login operation. The user token is returned by the back-end system, and the back-end system has stored the user token and the random number accordingly. The authorization verification module is used to determine the random number based on the user token in the HTTP message header; use the random number to decrypt the encrypted string in the HTTP message header, and compare the decrypted URL address and parameters with the URL address and parameters of the queried API interface; if they are the same, the HTTP request is executed; if they are different, the HTTP request is rejected. The permission verification module is further configured to: If the two are different, an error message is returned to the front-end system so that the front-end system outputs the error message.

5. A configuration-free interface permission verification system, characterized in that, The system includes a front-end system and a back-end system, wherein the front-end system is used to execute the configuration-free interface permission verification method according to claim 1, and the back-end system is used to execute the configuration-free interface permission verification method according to claim 3.

Images