A method, apparatus and readable storage medium for dynamic interface path request

Abstract

This application provides a dynamic interface path request method, apparatus, and readable storage medium. The method includes: responding to receiving a dynamic interface path request from a front end, determining whether the dynamic interface path exists in a path list; if the dynamic interface path does not exist in the path list, adding the dynamic interface path to the path list, and decrypting the dynamic interface path request using the private key corresponding to the public key to obtain the actual request path, a first timestamp, and a second timestamp at the time of decryption; determining whether the time interval between the first timestamp and the second timestamp is within a preset duration; if the time interval is within the preset duration, processing the request according to the actual request path and sending the corresponding request response data to the front end. This application can verify the validity of the request path, prevent sniffing from the source, ensure system security, and save investment.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and in particular to a dynamic interface path request method, apparatus and readable storage medium. Background Technology

[0002] With the development of internet technology, web applications have become an important bridge between enterprises and users. To improve development efficiency and maintainability, the front-end and back-end separation architecture has gradually become the mainstream development model. In this architecture, the front-end is responsible for the presentation of the user interface, while the back-end focuses on business logic processing and data management.

[0003] However, as the complexity of the system increases, security issues become increasingly prominent, especially when third-party components and services are involved.

[0004] Therefore, improving the security of a front-end / back-end separation architecture has become a problem that needs to be solved. Summary of the Invention

[0005] The technical problem to be solved by this application is to provide a dynamic interface path request method, apparatus and readable storage medium to address the above-mentioned shortcomings of the prior art.

[0006] Firstly, this application provides a dynamic interface path request method, applied to a backend, the method comprising:

[0007] A1. In response to receiving a dynamic interface path request from the front end, determine whether the dynamic interface path exists in the path list; wherein, the dynamic interface path request is generated by the front end encrypting the real request path and the first timestamp when the request is generated based on the public key sent by the back end.

[0008] A2. If the dynamic interface path does not exist in the path list, the dynamic interface path is added to the path list, and the dynamic interface path request is decrypted using the private key corresponding to the public key to obtain the real request path, the first timestamp, and the second timestamp when the request was decrypted.

[0009] A3. Determine whether the time interval between the first timestamp and the second timestamp is within a preset duration;

[0010] A4. If the time interval is within the preset duration, the request will be processed according to the actual request path, and the corresponding request response data will be sent to the front end.

[0011] In some embodiments, it also includes:

[0012] If the dynamic interface path exists in the path list, a request failure message is sent to the front end.

[0013] In some embodiments, it also includes:

[0014] If the time interval exceeds the preset duration, a request failure message will be sent to the front end.

[0015] In some embodiments, the public key and the corresponding private key are generated by the backend using an asymmetric encryption algorithm.

[0016] Secondly, this application provides a dynamic interface path request method, applied to a front-end, the method comprising:

[0017] B1. In response to the request to obtain the front-end interface interaction, obtain the corresponding real request path;

[0018] B2. Encrypt the real request path and the current first timestamp based on the public key sent by the backend to generate a dynamic interface path request;

[0019] B3. Send the dynamic interface path request to the backend;

[0020] B4. Upon receiving the request response data sent by the backend, output a request success message and display the request response data on the frontend interface.

[0021] In some embodiments, the real request path and the current first timestamp are encrypted based on the public key sent by the backend to generate a dynamic interface path request, including:

[0022] The actual request path and the current first timestamp are combined to obtain combined information;

[0023] The combined information is encrypted using the public key to generate a dynamic interface path request.

[0024] In some embodiments, it also includes:

[0025] Upon receiving a request failure message from the backend, output a request failure message;

[0026] The request failure information is sent when the backend determines that the dynamic interface path exists in the path list or when it determines that the time interval between the first timestamp and the second timestamp when the backend decrypts the request exceeds a preset duration.

[0027] Thirdly, this application provides a dynamic interface path request device, applied to a backend, the device comprising:

[0028] The request receiving module is configured to, in response to receiving a dynamic interface path request from the front end, determine whether the dynamic interface path exists in the path list; wherein, the dynamic interface path request is generated by the front end encrypting the actual request path and the first timestamp when the request was generated based on the public key sent by the back end.

[0029] The request decryption module is configured to add the dynamic interface path to the path list if the dynamic interface path does not exist in the path list, and decrypt the dynamic interface path request using the private key corresponding to the public key to obtain the real request path, the first timestamp, and the second timestamp when the decryption request was made.

[0030] The judgment module is configured to determine whether the time interval between the first timestamp and the second timestamp is within a preset duration;

[0031] The request processing module is configured to process the request according to the actual request path and send the corresponding request response data to the front end if the time interval is within a preset duration.

[0032] Fourthly, this application provides a dynamic interface path request device, applied to a front-end, the device comprising:

[0033] The request retrieval module is configured to retrieve the corresponding real request path in response to requests for front-end interface interaction.

[0034] The encryption module is configured to encrypt the real request path and the current first timestamp based on the public key sent by the backend, and generate a dynamic interface path request.

[0035] The sending module is configured to send the dynamic interface path request to the backend.

[0036] The receiving module is configured to respond to the request response data sent by the backend, output a request success message, and display the request response data on the front-end interface.

[0037] Fifthly, this application provides a dynamic interface path request apparatus, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to implement the dynamic interface path request method described in the first aspect above.

[0038] In a sixth aspect, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the dynamic interface path request method described in the first aspect.

[0039] The present application provides a dynamic interface path request method, apparatus, and readable storage medium. The method includes: in response to receiving a dynamic interface path request from a front-end, determining whether the dynamic interface path exists in a path list; wherein the dynamic interface path request is generated by the front-end encrypting the actual request path and a first timestamp when the request is generated based on a public key sent by the back-end; if the dynamic interface path does not exist in the path list, adding the dynamic interface path to the path list, and decrypting the dynamic interface path request using the private key corresponding to the public key to obtain the actual request path, the first timestamp, and a second timestamp when the request is decrypted; determining whether the time interval between the first timestamp and the second timestamp is within a preset duration; if the time interval is within the preset duration, processing the request according to the actual request path and sending the corresponding request response data to the front-end. This application provides a dynamic interface path request method that does not require modification of the original front-end and back-end business processing logic. The front-end only needs to modify the request module, embed an asymmetric encryption module, and generate a dynamic path with timestamps. The back-end uses slices to write to filters or interceptors without modifying the original logic processing module. This method achieves decryption and establishes a path list blacklist, thus implementing the self-destructing technology after reading, verifying the validity of the request path, preventing sniffing from the source, ensuring system security, and saving investment. Attached Figure Description

[0040] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0041] Figure 1 A schematic diagram illustrating a dynamic interface path request method applied to the backend, as provided in an embodiment of this application;

[0042] Figure 2 A schematic diagram illustrating a dynamic interface path request method applied to the front end, as provided in an embodiment of this application;

[0043] Figure 3 A schematic diagram of the overall scheme of the dynamic interface path request method provided in the embodiments of this application;

[0044] Figure 4 A schematic diagram of a dynamic interface path request device applied to the backend, provided in an embodiment of this application;

[0045] Figure 5 A schematic diagram of a dynamic interface path request device applied to the front end, provided in an embodiment of this application;

[0046] Figure 6 This is a schematic diagram of another dynamic interface path request device provided in an embodiment of this application.

[0047] The accompanying drawings have illustrated specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to specific embodiments. Detailed Implementation

[0048] To enable those skilled in the art to better understand the technical solution of this application, the embodiments of this application will be further described in detail below with reference to the accompanying drawings.

[0049] It is understood that the specific embodiments and accompanying drawings described herein are merely for explaining this application and are not intended to limit this application.

[0050] It is understood that, without conflict, the various embodiments and features in the embodiments of this application can be combined with each other.

[0051] It is understood that, for ease of description, only the parts relevant to this application are shown in the accompanying drawings, while parts unrelated to this application are not shown in the drawings.

[0052] It is understood that each unit or module involved in the embodiments of this application may correspond to only one entity structure, or may be composed of multiple entity structures, or multiple units or modules may be integrated into one entity structure.

[0053] It is understood that the terms "first," "second," etc., used in the embodiments of this application are used to distinguish different objects or to distinguish different treatments of the same object, rather than to describe a specific order of objects.

[0054] It is understood that, without conflict, the functions and steps marked in the flowcharts and block diagrams of this application may occur in a different order than those marked in the accompanying drawings.

[0055] It is understood that the flowcharts and block diagrams of this application illustrate the possible architecture, functions, and operations of systems, apparatuses, devices, and methods according to various embodiments of this application. Each block in a flowchart or block diagram may represent a unit, module, program segment, or code, containing executable instructions for implementing the specified function. Furthermore, each block or combination of blocks in the block diagrams and flowcharts may be implemented using a hardware-based system to implement the specified function, or using a combination of hardware and computer instructions.

[0056] It is understood that the units and modules involved in the embodiments of this application can be implemented by software or by hardware. For example, the units and modules can be located in the processor.

[0057] In a front-end / back-end separation architecture, the front-end is typically built using technologies such as HTML, CSS, and JavaScript, while the API interface is the core of the interaction between the front-end and back-end. The back-end uses languages ​​such as Java, Python, and Node.js to write server-side programs and exchanges data with the front-end through RESTful APIs or other protocols.

[0058] The front-end is responsible for rendering the user interface and handling interaction logic, while the back-end provides data processing and storage services. The front-end requests data from the back-end, which processes it and returns it to the front-end for display.

[0059] In some cases, to accelerate the development or utilize mature functional modules, developers may choose to integrate third-party components or services into their own systems, thereby providing users with additional services or functions. Meanwhile, eavesdropping and sniffing tools can capture data packets during network transmission and extract valuable information, such as backend interface addresses. If this information falls into malicious hands, it could be used to launch further attacks.

[0060] Specifically, the shortcomings of existing technologies include the following:

[0061] 1. Fixed request address: In the current network environment, the abuse of various sniffing tools makes it easy to obtain the interface address for subsequent attacks.

[0062] 2. Adopt a more stringent authentication mechanism, such as OAuth2.0 or JWT: Under continuous monitoring by sniffing tools, it is difficult to continuously guarantee the interface address, especially when there are vulnerabilities in the authentication mechanism and third-party components, such as Swagger passwordless login request interface;

[0063] 3. Security audit: It can only record the attacker's behavior and provide timely warnings, but it cannot prevent attacks caused by sniffing and eavesdropping.

[0064] 4. Default Address Protection: This increases the difficulty for attackers to detect the IP address by changing the default management interface address or using other methods (such as authentication or IP whitelisting). However, as long as someone uses the address, it will inevitably be detected by eavesdroppers, making it impossible to completely hide. IP restrictions can also be bypassed through proxies.

[0065] Based on the above problems, the purpose of this application is to generate an encrypted dynamic request address on the front end to initiate the request, and then decrypt it on the back end and forward it to the original address, while recording the list of requested addresses to prevent secondary access. This application can avoid sniffing by various sniffing tools and malicious exploitation of vulnerabilities to carry out attacks, thereby greatly improving the security of the front-end and back-end separation architecture and reducing the cost of building system transformation solutions.

[0066] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0067] Figure 1 This is a schematic diagram of a dynamic interface path request method applied to the backend, as provided in an embodiment of this application. Figure 1 As shown, this application provides a dynamic interface path request method, the method comprising:

[0068] A01. The backend generates a public key and a private key using an asymmetric encryption algorithm. The public key is sent to the frontend for storage, and the private key is stored in the application's backend code.

[0069] A1. The backend responds to the dynamic interface path request received from the frontend by determining whether the dynamic interface path exists in the path list.

[0070] The dynamic interface path request is generated by the front end encrypting the actual request path and the first timestamp when the request is generated based on the public key sent by the back end; the path list is used to store the paths corresponding to the requests sent by the front end.

[0071] Specifically, when a user interacts with the front-end application and interface, the front-end obtains the front-end interface interaction request, obtains the corresponding real request path, and then encrypts the real request path and the current first timestamp based on the public key sent by the back-end to generate a dynamic interface path request, and sends the dynamic interface path request to the back-end.

[0072] After receiving a dynamic interface path request, the backend, based on slice-oriented development technology, calls the dynamic interface decryption filter (or interceptor) before calling the controller to execute the logic to determine whether the dynamic interface path request is in the path list. The dynamic request path list is obtained by querying the backend cache (or database).

[0073] A2. If the dynamic interface path does not exist in the path list, the backend will add the dynamic interface path to the path list and decrypt the dynamic interface path request using the private key corresponding to the public key to obtain the real request path, the first timestamp, and the second timestamp when decrypting the request.

[0074] Specifically, when a dynamic interface path does not exist in the path list, the backend adds the current path to the dynamic request path list in the backend cache (or database). The backend cache (or database) periodically (for a period longer than the preset time in step A3, such as 1 minute, the preset time is used to verify the validity of the path) cleans up and destroys the cached dynamic request path list. This can avoid the frontend repeatedly refreshing and retrying, which slows down the backend processing speed, and at the same time achieves the effect of "read and burn".

[0075] For example, the cached data shown below is automatically cleared one minute after it was added:

[0076]

[0077] Then, the backend uses the private key to decrypt the dynamic interface path request to deconstruct the real request path and the first timestamp of the request generation, and records the second timestamp of the current deconstruction for subsequent judgment of the authenticity and validity of the request.

[0078] In some embodiments, the method further includes: if the dynamic interface path exists in the path list, then sending a request failure message to the front end.

[0079] Specifically, if the dynamic interface path exists in the path list, it indicates that the front-end is refreshing and retrying. Since the same request has already existed, the back-end returns a request failure message for this request.

[0080] A3. The backend determines whether the time interval between the first timestamp and the second timestamp is within a preset duration;

[0081] In this step, the logic for judging whether the time interval between the first timestamp and the second timestamp is within a preset duration (such as 10 seconds) is executed. Through this judgment, the authenticity and validity of the request can be determined. For example, if the time interval is too long, the request may have been intercepted and forwarded by a sniffing program.

[0082] A4. If the time interval is within the preset duration, the backend will process the request according to the actual request path and send the corresponding request response data to the frontend.

[0083] When the time interval is within the preset duration, the backend processes the request according to the actual request path. Specifically, the backend rewrites the request path according to the actual request path. At this time, the backend completes the proxy slice and continues to call the original controller according to the normal call chain to complete the original related processing logic and feed back the request response data to the frontend.

[0084] In some embodiments, the method further includes sending a request failure message to the front end if the time interval exceeds a preset duration.

[0085] Specifically, if the time interval is too long, the request may have been intercepted and forwarded by a sniffing program. The backend can then determine that the request is not genuine and valid, and therefore, the backend sends a request failure message to the frontend.

[0086] Figure 2 This is a schematic diagram of a dynamic interface path request method applied to the front end, as provided in an embodiment of this application. Figure 2 As shown, this application provides a dynamic interface path request method, the method comprising:

[0087] B01. The backend generates a public key and a private key using an asymmetric encryption algorithm, and sends the public key to the frontend. The frontend receives the public key sent by the backend and saves it.

[0088] B1. The front-end responds to the front-end interface interaction request and obtains the corresponding real request path;

[0089] Specifically, when a user interacts with the front-end application and interface, the front-end obtains the front-end interface interaction request and retrieves the corresponding real request path.

[0090] B2. The front end encrypts the real request path and the current first timestamp based on the public key sent by the back end, and generates a dynamic interface path request.

[0091] In some embodiments, the real request path and the current first timestamp are encrypted based on the public key sent by the backend to generate a dynamic interface path request, including:

[0092] The actual request path and the current first timestamp are combined to obtain combined information;

[0093] The combined information is encrypted using the public key to generate a dynamic interface path request.

[0094] Specifically, when a user interacts with the front-end application and interface, triggering the original interface function in the front-end logic module, the front-end switches to the dynamic interface request generation method of this application to generate the current timestamp, and then combines it with the actual interface request path in a simple way (such as using | as a separator) and encrypts it with a public key to generate a dynamic request path.

[0095] B3. The front end sends the dynamic interface path request to the back end;

[0096] B4. Upon receiving the request response data sent by the backend, the frontend responds by outputting a request success message and displaying the request response data on the frontend interface.

[0097] In some embodiments, it also includes:

[0098] The frontend responds to the request failure information received from the backend by outputting a request failure message;

[0099] The request failure information is sent when the backend determines that the dynamic interface path exists in the path list or when it determines that the time interval between the first timestamp and the second timestamp when the backend decrypts the request exceeds a preset duration.

[0100] Figure 3 This is a schematic diagram of the overall scheme of the dynamic interface path request method provided in the embodiments of this application, as shown below. Figure 3 As shown, this application provides a dynamic interface path request method, the method comprising:

[0101] (1) First, the backend uses an asymmetric encryption algorithm (Figure 1) to generate a pair of public keys (Figure 2) and private keys (Figure 3). The public key is stored in the frontend code, and the private key is stored in the application backend code.

[0102] (2) When the user interacts with the interface in the front-end application (Figure 4), the original interface function in the front-end logic module (Figure 5) is triggered, and the dynamic interface generation function of this application (Figure 6) is connected to generate the current timestamp, and after a simple combination (such as using | to separate) with the actual request path of the interface, it is encrypted with the public key to generate the dynamic request path (Figure 7), and a request is sent to the back-end for that path.

[0103] (3) After receiving the request, the backend calls the dynamic interface decryption filter (or interceptor) (Figure 8) before calling the controller based on the slice-oriented development technology, executes the logic to determine whether the dynamic request path is in the path list (Figure 9), and queries the list of dynamic request paths stored in the backend cache (or database) (Figure 10).

[0104] When the dynamic request path exists, the request failure is reported to the front end, and the error message is displayed in the UI (Figure 11), and the process ends (Figure 16).

[0105] When a dynamic request path does not exist, add the current path to the list of dynamic request paths in the backend cache (or database) (Figure 10) (this can avoid the frontend repeatedly refreshing and retrying, which slows down the backend processing speed, and achieves the effect of reading and burning). The backend cache (or database) periodically (more than the agreed time, such as 1 minute, the agreed time is used to verify the validity of the path) cleans up and destroys the cached list of dynamic request paths (Figure 10).

[0106] (4) The backend uses the private key (3 in the figure) to decrypt the dynamic request path to deconstruct the real request path and the generation timestamp, and records the current deconstruction timestamp. It then executes the logic to determine whether the deconstruction timestamp - generation timestamp is within the agreed time (e.g., 10 seconds) (12 in the figure).

[0107] If the condition is not met, it means that the front end initiated a request (which may have been intercepted and forwarded by the sniffing program). The request failed and the error message (Figure 11) is displayed on the UI, and the process ends (Figure 16).

[0108] When the conditions are met, the request path is rewritten according to the actual request path (Figure 13). At this time, the backend completes the proxy slice of this invention and continues to call the original controller according to the normal call chain (Figure 14) to complete the original related processing logic and feed back the response data to the frontend, indicating that the request was successful and displaying it in the UI (Figure 15). The process ends (Figure 16).

[0109] This application provides a dynamic interface path request method that does not require modification of the original front-end and back-end business processing logic. The front-end only needs to modify the request module, embed an asymmetric encryption module, and generate a dynamic path with timestamps. The back-end uses slices to write to filters or interceptors without modifying the original logic processing module. This method achieves decryption and establishes a path list blacklist, thus implementing the self-destructing technology after reading, verifying the validity of the request path, preventing sniffing from the source, ensuring system security, and saving investment.

[0110] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some of the steps in the figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0111] Figure 4 A schematic diagram of a dynamic interface path request device applied to the backend provided in the embodiments of this application, as shown below. Figure 4 As shown, this application provides a dynamic interface path request device, applied to a backend, the device comprising:

[0112] The request receiving module 11 is configured to, in response to receiving a dynamic interface path request from the front end, determine whether the dynamic interface path exists in the path list; wherein, the dynamic interface path request is generated by the front end encrypting the real request path and the first timestamp when the request is generated based on the public key sent by the back end.

[0113] The request decryption module 12 is configured to add the dynamic interface path to the path list if the dynamic interface path does not exist in the path list, and decrypt the dynamic interface path request using the private key corresponding to the public key to obtain the real request path, the first timestamp, and the second timestamp when the decryption request was made.

[0114] The judgment module 13 is configured to determine whether the time interval between the first timestamp and the second timestamp is within a preset duration;

[0115] The request processing module 14 is configured to process the request according to the actual request path and send the corresponding request response data to the front end if the time interval is within a preset duration.

[0116] Figure 5 A schematic diagram of a dynamic interface path request device applied to the front end, as provided in the embodiments of this application, is shown below. Figure 5 As shown, this application provides a dynamic interface path request device, applied to a front-end, the device comprising:

[0117] The request acquisition module 21 is configured to retrieve the corresponding real request path in response to a request to retrieve front-end interface interaction;

[0118] The encryption module 22 is configured to encrypt the real request path and the current first timestamp based on the public key sent by the backend, and generate a dynamic interface path request.

[0119] Sending module 23 is configured to send the dynamic interface path request to the backend;

[0120] The receiving module 24 is configured to respond to receiving request response data sent by the backend, output a request success message, and display the request response data on the front-end interface.

[0121] Regarding the limitations on the dynamic interface path request device, please refer to the limitations on the dynamic interface path request method in the above embodiments of this application, which will not be repeated here.

[0122] Figure 6 Another schematic diagram of the dynamic interface path request device provided in the embodiments of this application is shown below. Figure 6 As shown, in some embodiments, this application provides a dynamic interface path request apparatus, including a memory 32 and a processor 31. The memory stores a computer program, and the processor is configured to run the computer program to execute the dynamic interface path request method in the above embodiments of this application.

[0123] The memory is connected to the processor. The memory can be flash memory, read-only memory or other types of memory. The processor can be a central processing unit or a microcontroller.

[0124] In some embodiments, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the dynamic interface path request method in the above embodiments of this application.

[0125] The computer-readable storage medium includes volatile or non-volatile, removable or non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, computer program modules, or other data). Computer-readable storage media include, but are not limited to, RAM (Random Access Memory), ROM (Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), flash memory or other memory technologies, CD-ROM (Compact Disc Read-Only Memory), DVD or other optical disc storage, cartridges, magnetic tapes, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer.

[0126] It is understood that the above embodiments are merely exemplary implementations used to illustrate the principles of this application, and this application is not limited thereto. For those skilled in the art, various modifications and improvements can be made without departing from the spirit and substance of this application, and these modifications and improvements are also considered to be within the scope of protection of this application.

Claims

1. A dynamic interface path request method, characterized in that, Applied to the backend, the method includes: A1. In response to receiving a dynamic interface path request from the front end, determine whether the dynamic interface path exists in the path list; wherein, the dynamic interface path request is generated by the front end encrypting the real request path and the first timestamp when the request is generated based on the public key sent by the back end. A2. If the dynamic interface path does not exist in the path list, the dynamic interface path is added to the path list, and the dynamic interface path request is decrypted using the private key corresponding to the public key to obtain the real request path, the first timestamp, and the second timestamp when the request was decrypted. A3. Determine whether the time interval between the first timestamp and the second timestamp is within a preset duration; A4. If the time interval is within the preset duration, the request will be processed according to the actual request path, and the corresponding request response data will be sent to the front end.

2. The dynamic interface path request method according to claim 1, characterized in that, Also includes: If the dynamic interface path exists in the path list, a request failure message is sent to the front end.

3. The dynamic interface path request method according to claim 1, characterized in that, Also includes: If the time interval exceeds the preset duration, a request failure message will be sent to the front end.

4. The dynamic interface path request method according to claim 1, characterized in that, The public key and the corresponding private key are generated by the backend using an asymmetric encryption algorithm.

5. A dynamic interface path request method, characterized in that, Applied to the front end, the method includes: B1. In response to the request to obtain the front-end interface interaction, obtain the corresponding real request path; B2. Encrypt the real request path and the current first timestamp based on the public key sent by the backend to generate a dynamic interface path request; B3. Send the dynamic interface path request to the backend so that the backend application can obtain the request response data as described in steps A1 to A4 of claim 1; B4. Upon receiving the request response data sent by the backend, output a request success message and display the request response data on the frontend interface.

6. The dynamic interface path request method according to claim 5, characterized in that, Based on the public key sent by the backend, the actual request path and the current first timestamp are encrypted to generate a dynamic interface path request, including: The actual request path and the current first timestamp are combined to obtain combined information; The combined information is encrypted using the public key to generate a dynamic interface path request.

7. The dynamic interface path request method according to claim 5, characterized in that, Also includes: Upon receiving a request failure message from the backend, output a request failure message; The request failure information is sent when the backend determines that the dynamic interface path exists in the path list or when it determines that the time interval between the first timestamp and the second timestamp when the backend decrypts the request exceeds a preset duration.

8. A dynamic interface path request device, characterized in that, Applied to the backend, the device includes: The request receiving module is configured to, in response to receiving a dynamic interface path request from the front end, determine whether the dynamic interface path exists in the path list; wherein, the dynamic interface path request is generated by the front end encrypting the actual request path and the first timestamp when the request was generated based on the public key sent by the back end. The request decryption module is configured to add the dynamic interface path to the path list if the dynamic interface path does not exist in the path list, and decrypt the dynamic interface path request using the private key corresponding to the public key to obtain the real request path, the first timestamp, and the second timestamp when the decryption request was made. The judgment module is configured to determine whether the time interval between the first timestamp and the second timestamp is within a preset duration; The request processing module is configured to process the request according to the actual request path and send the corresponding request response data to the front end if the time interval is within a preset duration.

9. A dynamic interface path request device, characterized in that, Applied to the front end, the device includes: The request retrieval module is configured to retrieve the corresponding real request path in response to requests for front-end interface interaction. The encryption module is configured to encrypt the real request path and the current first timestamp based on the public key sent by the backend, and generate a dynamic interface path request. The sending module is configured to send the dynamic interface path request to the backend so that the backend application can obtain the request response data as described in steps A1 to A4 of claim 1. The receiving module is configured to respond to the request response data sent by the backend, output a request success message, and display the request response data on the front-end interface.

10. A dynamic interface path request device, characterized in that, It includes a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to implement the dynamic interface path request method as described in any one of claims 1-7.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the dynamic interface path request method as described in any one of claims 1-7.

Images