Dynamic interface path request method and device and readable storage medium

Abstract

The invention provides a dynamic interface path request method and device and a readable storage medium, and the method comprises the steps: responding to a received dynamic interface path request from a front end, and judging whether a dynamic interface path exists in a path list or not; 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 through a private key corresponding to the public key to obtain a real request path, a first timestamp and a second timestamp when the request is decrypted; judging whether a time interval between the first timestamp and the second timestamp is within a preset duration or not; and if the time interval is within the preset duration, performing request processing according to the real request path, and sending corresponding request response data to the front end. The validity of the request path can be verified, sniffing is prevented from the source, the system safety is guaranteed, and the investment is saved.

Description

Technical Field

[0001] The present application relates to the field of Internet technology, and in particular to a dynamic interface path request method, device and readable storage medium. Background Art

[0002] With the development of Internet technology, Web applications have become an important bridge between enterprises and users. In order 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 systems grow in complexity, security issues become more prominent, especially when third-party components and services are involved.

[0004] Therefore, how to improve the security of the front-end and back-end separation architecture becomes a problem that needs to be solved. Summary of the invention

[0005] The technical problem to be solved by the present application is to provide a dynamic interface path request method, device and readable storage medium to solve the problems existing in the prior art in view of the above-mentioned deficiencies in the prior art.

[0006] In a first aspect, the present application provides a dynamic interface path request method, which is applied to a backend, and the method includes:

[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 encrypting the real request path and the first timestamp when the request is generated by the front end based on the public key sent by the back end;

[0008] A2. If the dynamic interface path does not exist in the path list, 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 the decrypted request is made;

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

[0010] A4. If the time interval is within the preset time length, the request is processed according to the actual request path, and the corresponding request response data is 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 is sent to the front end.

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

[0016] In a second aspect, the present application provides a dynamic interface path request method, which is applied to a front end, and the method includes:

[0017] B1. In response to obtaining the front-end interface interaction request, 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, sending the dynamic interface path request to the back end;

[0020] B4. In response to receiving the request response data sent by the back end, output a request success prompt message and display the request response data on the front end interface.

[0021] In some embodiments, encrypting 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 includes:

[0022] Combining the real request path and the current first timestamp to obtain combined information;

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

[0024] In some embodiments, it also includes:

[0025] In response to receiving the request failure information sent by the backend, outputting the request failure prompt information;

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

[0027] In a third aspect, the present application provides a dynamic interface path request device, which is applied to a backend, and the device includes:

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

[0029] a request decryption module, 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 decrypted request is made;

[0030] A determination module, configured to determine whether a time interval between the first timestamp and the second timestamp is within a preset time length;

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

[0032] In a fourth aspect, the present application provides a dynamic interface path request device, applied to a front end, the device comprising:

[0033] A request acquisition module, which is configured to obtain a corresponding real request path in response to obtaining a front-end interface interaction request;

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

[0035] A sending module, configured to send the dynamic interface path request to a backend;

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

[0037] In a fifth aspect, the present application provides a dynamic interface path request device, comprising 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, the present application provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the dynamic interface path request method described in the first aspect above is implemented.

[0039] The present application provides a dynamic interface path request method, device and readable storage medium, the method comprising: 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 encrypting the real request path and the first timestamp when the request is generated by the front end based on the public key sent by the back end; 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 by the private key corresponding to the public key to obtain the real request path, the first timestamp and the second timestamp when the request is decrypted; determining whether the time interval between the first timestamp and the second timestamp is within a preset time length; if the time interval is within the preset time length, performing request processing according to the real request path, and sending the corresponding request response data to the front end. The present application provides a dynamic interface path request method, which does not require changes to the original front-end and back-end business processing logic. The front-end only needs to modify the request module, implant an asymmetric encryption module, and generate a dynamic path in conjunction with a timestamp. The back-end uses a slice to write a filter or interceptor, and does not need to modify the original logic processing module to achieve decryption and establish a path list blacklist to implement the read-and-burn technology, verify the validity of the request path, prevent sniffing from the source, ensure system security and save investment. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

[0043] Figure 3 A schematic diagram of the overall solution of the dynamic interface path request method provided in an embodiment of the present application;

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

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

[0046] Figure 6 A schematic diagram of the structure of another dynamic interface path request device provided in an embodiment of the present application.

[0047] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0048] In order to enable those skilled in the art to better understand the technical solution of the present application, the implementation mode of the present application will be further described in detail below with reference to the accompanying drawings.

[0049] It should be understood that the specific embodiments and drawings described herein are only used to explain the present application, rather than to limit the present application.

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

[0051] It can be understood that, for the convenience of description, the drawings of the present application only show the parts related to the present application, while the parts unrelated to the present application are not shown in the drawings.

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

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

[0054] It is understandable that, in the absence of conflict, the functions and steps marked in the flowcharts and block diagrams of the present application may occur in an order different from that marked in the drawings.

[0055] It is understood that the flowcharts and block diagrams of the present application illustrate the possible architectures, functions, and operations of the systems, devices, equipment, and methods according to the various embodiments of the present application. Among them, each box in the flowchart or block diagram may represent a unit, module, program segment, code, which contains executable instructions for implementing the specified functions. Moreover, each box or combination of boxes in the block diagram and flowchart may be implemented by a hardware-based system that implements the specified functions, or by a combination of hardware and computer instructions.

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

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

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

[0059] In some cases, in order to speed up development or utilize mature functional modules, developers will choose to integrate third-party components or services into their own systems to provide users with additional services or functions. Monitoring and sniffing tools can capture data packets during network transmission and extract valuable information from them, such as backend interface addresses. Once this information falls into malicious hands, it may be used to further carry out attacks.

[0060] Specifically, the shortcomings of the prior art 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 to prepare for subsequent attacks;

[0062] 2. Use a stricter authentication mechanism, such as OAuth2.0 or JWT: It is difficult to continuously guarantee the interface address when the sniffing tool is continuously monitoring, especially when there are vulnerabilities in the authentication mechanism and third-party components, such as the swagger password-free login request interface;

[0063] 3. Security audit: It can only record the attacker's behavior and issue timely warnings, but cannot avoid attacks caused by sniffing and monitoring.

[0064] 4. Default address protection: By changing the default management interface address or using other methods (such as identity authentication, IP whitelist) to increase the difficulty of discovery by attackers. However, as long as the user uses the address, it will be found by the listener and cannot be hidden at all. IP restrictions can also be bypassed through a proxy.

[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 a request, and then forward it to the original address after decryption on the back end, and record the list of requested addresses to prevent secondary access. This application can avoid sniffing by various sniffing tools and malicious exploitation of vulnerabilities to attack, thereby greatly improving the security of the front-end and back-end separation architecture and reducing the cost of building a system transformation plan.

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

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

[0068] A01. The backend generates a public key and a private key through an asymmetric encryption algorithm, sends the public key to the frontend for storage, and saves the private key in the application backend code.

[0069] A1. In response to receiving a dynamic interface path request from the front end, the back end determines whether the dynamic interface path exists in the path list;

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

[0071] Specifically, when the user interacts with the interface in the front-end application, 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, generates a dynamic interface path request, and sends the dynamic interface path request to the back-end.

[0072] After the backend receives the dynamic interface path request, based on the slice-oriented development technology, the dynamic interface decryption filter (or interceptor) is called before calling the controller to execute the judgment logic of whether the dynamic interface path request is in the path list, where 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 adds the dynamic interface path to the path list, and decrypts 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 decrypted request is made;

[0074] Specifically, when the 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 (greater than the preset time in step A3, such as 1 minute, the preset time is used to verify the path validity period) cleans and destroys the cached dynamic request path list, which can avoid the front-end repeatedly refreshing and retrying to slow down the back-end processing speed, and at the same time achieve the effect of reading and burning.

[0075] For example, the data in the cache is as follows, and it is automatically cleared after 1 minute of the addition time:

[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, it also includes: if the dynamic interface path exists in the path list, sending request failure information to the front end.

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

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

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

[0082] A4. If the time interval is within the preset time length, the backend processes the request according to the actual request path and sends the corresponding request response data to the frontend.

[0083] When the time interval is within the preset time length, 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 slicing, continues to call the original controller according to the normal call chain to complete the original related processing logic, and feeds back the request response data to the front end.

[0084] In some embodiments, it also includes: if the time interval exceeds a preset duration, a request failure message is sent to the front end.

[0085] Specifically, if the time interval is too long, the request may be intercepted and forwarded by a sniffer program, and the backend may determine that the request is not authentic and valid, so the backend sends a request failure message to the frontend.

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

[0087] B01. The backend generates a public key and a private key through 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 obtains the corresponding real request path in response to obtaining the front end interface interaction request;

[0089] Specifically, when a user interacts with the interface in the front-end application, the front-end obtains the front-end interface interaction request and obtains 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 to generate a dynamic interface path request;

[0091] In some embodiments, encrypting 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 includes:

[0092] Combining the real request path and the current first timestamp to obtain combined information;

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

[0094] Specifically, when the user interacts with the interface in the front-end application and triggers the original interface function in the front-end logic module, the front-end instead adopts the dynamic interface request generation method of the present application to generate the current timestamp, and simply combines it with the actual request path of the interface (such as using | to separate it) and then uses the public key to encrypt it to generate a dynamic request path.

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

[0096] B4. In response to receiving the request response data sent by the back end, the front end outputs a request success prompt message and displays the request response data on the front end interface.

[0097] In some embodiments, it also includes:

[0098] The front end outputs request failure prompt information in response to receiving the request failure information sent by the back end;

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

[0100] Figure 3 The overall scheme diagram of the dynamic interface path request method provided in the embodiment of the present application is as follows: Figure 3 As shown, the present application provides a dynamic interface path request method, the method comprising:

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

[0102] (2) When the user interacts with the interface in the front-end application (4 in the figure), the original interface function (5 in the figure) in the front-end logic module is triggered, and the dynamic interface generation function (6 in the figure) of the present application is accessed to generate the current timestamp, and the real request path of the interface is simply combined (such as separated by |) and encrypted with the public key to generate a dynamic request path (7 in the figure), and a request is sent to the back-end path;

[0103] (3) After the backend receives the request, based on the slice-oriented development technology, the dynamic interface decryption filter (or interceptor) is called before calling the controller (8 in the figure), the dynamic request path is judged in the path list (9 in the figure), and the dynamic request path list saved in the backend cache (or database) is queried (10 in the figure);

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

[0105] When the dynamic request path does not exist, add the current path to the dynamic request path list (10 in the figure) in the backend cache (or database) (this can prevent the frontend from repeatedly refreshing and retrying to slow down the backend processing speed, and achieve the effect of burning after reading). The backend cache (or database) regularly (longer than the agreed time, such as 1 minute, the agreed time is used to verify the validity period of the path) cleans up and destroys the cached dynamic request path list (10 in the figure);

[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 generated timestamp, and records the current deconstructed timestamp, and executes the judgment logic of whether the deconstructed timestamp-generated timestamp is within the agreed time (such as 10 seconds) (12 in the figure);

[0107] If not, it means that the front end initiates a request (which may be intercepted and forwarded by the sniffer program), and the request failure is fed back to the front end. An error message is displayed in the UI (11 in the figure), and the process ends (16 in the figure).

[0108] When satisfied, the request path is rewritten according to the real request path (13 in the figure). At this time, the backend completes the proxy slicing of the present invention, and continues to call the original controller according to the normal call chain (14 in the figure) to complete the original related processing logic and feedback the response data to the front end, prompting that the request is successful and displayed in the UI (15 in the figure), and the process ends (16 in the figure).

[0109] The present application provides a dynamic interface path request method, which does not require changes to the original front-end and back-end business processing logic. The front-end only needs to modify the request module, implant an asymmetric encryption module, and generate a dynamic path in conjunction with a timestamp. The back-end uses a slice to write a filter or interceptor, and does not need to modify the original logic processing module to achieve decryption and establish a path list blacklist to implement the read-and-burn technology, verify the validity of the request path, prevent sniffing from the source, ensure system security and save investment.

[0110] It should be understood that, although the various steps in the flowcharts in the above-described embodiments are sequentially displayed according to the indications of the arrows, these steps are not necessarily executed sequentially in the order indicated by the arrows. Unless there is a clear description in this article, the execution of these steps is not strictly limited in order, and they can be executed in other orders. Moreover, at least a portion of the steps in the figure may include a plurality of sub-steps or a plurality of stages, and these sub-steps or stages are not necessarily executed at the same time, but can be executed at different times, and their execution order is not necessarily to be carried out sequentially, but can be executed in turn or alternately with other steps or at least a portion of the sub-steps or stages of other steps.

[0111] Figure 4 A schematic diagram of a dynamic interface path request device applied to a backend provided in an embodiment of the present application, such as Figure 4 As shown, the present application provides a dynamic interface path request device, which is applied to a backend, and the device includes:

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

[0113] A request decryption module 12, which 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 by 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 is made;

[0114] A judging module 13, configured to judge whether the time interval between the first timestamp and the second timestamp is within a preset time length;

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

[0116] Figure 5 A schematic diagram of a dynamic interface path request device applied to a front end provided in an embodiment of the present application, such as Figure 5 As shown, the present application provides a dynamic interface path request device, which is applied to a front end, and the device includes:

[0117] A request acquisition module 21, which is configured to obtain a corresponding real request path in response to obtaining a front-end interface interaction request;

[0118] An encryption module 22, which is configured to 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;

[0119] A sending module 23, configured to send the dynamic interface path request to a backend;

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

[0121] Regarding the limitation of the dynamic interface path request device, reference may be made to the limitation of the dynamic interface path request method in the above embodiments of the present application, which will not be repeated in this embodiment.

[0122] Figure 6 Another schematic diagram of a dynamic interface path request device provided in an embodiment of the present application is as follows Figure 6 As shown, in some embodiments, the present application provides a dynamic interface path request device, 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-mentioned embodiments of the present application.

[0123] The memory is connected to the processor, the memory may be a flash memory or a read-only memory or other memory, and the processor may be a central processing unit or a single-chip microcomputer.

[0124] In some embodiments, the present application provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the dynamic interface path request method in the above-mentioned embodiments of the present application is implemented.

[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 technology, CD-ROM (Compact Disc Read-Only Memory), digital versatile disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by a computer.

[0126] It is to be understood that the above embodiments are merely exemplary embodiments used to illustrate the principles of the present application, but the present 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 the present application, and these modifications and improvements are also considered to be within the scope of protection of the present 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 encrypting the real request path and the first timestamp when the request is generated by the front end based on the public key sent by the back end; A2. If the dynamic interface path does not exist in the path list, 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 the decrypted request is made; A3. Determine whether the time interval between the first timestamp and the second timestamp is within a preset time length; A4. If the time interval is within the preset time length, the request is processed according to the actual request path, and the corresponding request response data is 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 is sent to the front end.

4. The dynamic interface path request method according to claim 1, characterized in that: The public key and the private key corresponding to the public key are generated by the backend through 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 obtaining the front-end interface interaction request, 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, sending the dynamic interface path request to the back end; B4. In response to receiving the request response data sent by the back end, output a request success prompt message and display the request response data on the front end interface.

6. The dynamic interface path request method according to claim 5, characterized in that: Encrypting 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, including: Combining the real request path and the current first timestamp to obtain combined information; The combined information is encrypted by 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: In response to receiving the request failure information sent by the backend, outputting the request failure prompt information; The request failure information is sent when the backend determines that the dynamic interface path exists in the path list or determines that the time interval between the first timestamp and the second timestamp of the backend decryption request exceeds a preset time length.

8. A dynamic interface path request device, characterized in that: Applied to the back end, the device comprises: A request receiving module, which is configured to determine whether the dynamic interface path exists in the path list in response to receiving a dynamic interface path request from the front end; wherein the dynamic interface path request is generated by encrypting the real request path and the first timestamp when the request is generated by the front end based on the public key sent by the back end; a request decryption module, 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 decrypted request is made; A determination module, configured to determine whether a time interval between the first timestamp and the second timestamp is within a preset time length; The request processing module is configured to process the request according to the actual request path if the time interval is within a preset time length, and send the corresponding request response data to the front end.

9. A dynamic interface path request device, characterized in that: Applied to the front end, the device comprises: A request acquisition module, which is configured to obtain a corresponding real request path in response to obtaining a front-end interface interaction request; An encryption module, configured to encrypt the real request path and the current first timestamp based on a public key sent by the backend to generate a dynamic interface path request; A sending module, configured to send the dynamic interface path request to a backend; The receiving module is configured to output a request success prompt message in response to receiving the request response data sent by the back end, and display the request response data on the front end interface.

10. A dynamic interface path request device, characterized in that: The method comprises 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 according to any one of claims 1 to 7.

11. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the dynamic interface path request method according to any one of claims 1 to 7 is implemented.

Images