Method and apparatus for loading web application content by means of native application, and electronic device, computer-readable storage medium and computer program product

Abstract

A method for loading web application content by means of a native application, and a related apparatus and a medium. The method comprises: intercepting a first request sent to a native application processing end, wherein the first request is used for indicating that a native application requests the loading of web application content; acquiring a request parameter of the first request, generating a first request identification code for identifying the first request, and sending the request parameter and the first request identification code to the native application processing end for associated storage; adding the first request identification code to the first request to obtain a second request; and sending the second request to the native application processing end, wherein the second request is used by the native application processing end to execute the following type of processing: on the basis of the first request identification code in the second request, searching for the request parameter stored in association with the first request identification code, parsing the first request in the second request to obtain a parsing result, assembling the parsing result and the found request parameter to obtain a page loading request, and sending the page loading request to a web application server.

Description

Methods, apparatus, electronic devices, computer-readable storage media, and computer program products for loading web application content via native applications.

[0001] Cross-reference of related applications

[0002] This application is based on Chinese Patent Application No. 202410680448.6, filed on May 29, 2024, and claims priority to that Chinese Patent Application, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure relates to the field of page display technology, and in particular to a method, apparatus, electronic device, computer-readable storage medium, and computer program product for loading web application content through native applications. Background Technology

[0004] Currently, in typical web applications, content on a server is accessed via a domain name. Domain names are susceptible to domain name blocking, while Internet Protocol (IP) addresses are not. This domain name blocking frequently leads to page loading failures.

[0005] The aforementioned problems can be solved in a hybrid development model based on web applications and native apps. For example, in a hybrid application, web application content (such as a video website application) can be loaded through a native application (such as a common chat application). In a hybrid application, business requests that attempt to load web application content through the native application are intercepted at the native application's processing end. The native application's processing end replaces the domain name address of the business request with the IP address using a domain name resolution service, thus reducing the risk of domain name interception. Then, when the access request is sent to the server, and the resources returned by the server are rendered into an H5 page through the web application, the risk of domain name interception is further reduced.

[0006] However, in the above method, after the native application processing end receives the business request, the request parameters in the business request (such as the type of image or text information requested to be displayed) cannot be parsed by the native application. Therefore, these request parameters cannot be passed to the native application processing end, resulting in the final loading and display failing due to the lack of request parameters. Summary of the Invention

[0007] This disclosure provides a method, apparatus, electronic device, computer-readable storage medium, and computer program product for loading web application content through native applications, which can reduce loading failures when loading web application content through native applications.

[0008] This disclosure provides a method for loading web application content through a native application, applied to a front-end plugin of a native application processor, the method comprising:

[0009] Intercept the first request sent to the native application processing end, the first request being used to indicate that the native application requests to load the web application content;

[0010] Obtain the request parameters of the first request, generate a first request identifier code to identify the first request, and send the request parameters and the first request identifier code to the native application processing terminal for associated storage;

[0011] Add the first request identifier code to the first request to obtain the second request;

[0012] Send the second request to the native application processing terminal;

[0013] The second request is used by the native application processing terminal to perform the following processing:

[0014] Based on the first request identifier in the second request, the request parameters associated with the first request identifier are located, the first request in the second request is parsed to obtain the parsing result, the parsing result and the found request parameters are assembled to obtain the page loading request, and the page loading request is sent to the web application server.

[0015] This disclosure provides a method for loading web application content through a native application, applied to a native application processing end, wherein the native application processing end has a pre-installed plugin, and the method includes:

[0016] The system receives and stores the request parameters and first request identifier code sent by the pre-plugin, wherein the request parameters are obtained by the pre-plugin from the first request when it receives the first request, and the first request identifier code is generated by the pre-plugin for the first request. The first request is used to characterize the native application requesting to load the web application content.

[0017] Receive a second request sent by the pre-plugin, the second request including the first request and the first request identifier;

[0018] Based on the first request identifier in the second request, locate the request parameters stored in association with the first request identifier;

[0019] The first request in the second request is parsed to obtain the parsing result. The parsing result and the found request parameters are assembled to obtain the page loading request, and the page loading request is sent to the web application server.

[0020] According to one aspect of this disclosure, an apparatus for loading web application content through a native application is provided, which is applied to a front-end plugin on the native application processing end, the apparatus comprising:

[0021] The interception unit is configured to intercept a first request sent to the native application processing end, wherein the first request is used to indicate that the native application requests to load the web application content;

[0022] The acquisition unit is configured to acquire the request parameters of the first request, generate a first request identifier code to identify the first request, and send the request parameters and the first request identifier code to the native application processing terminal for associated storage.

[0023] The generation unit is configured to add the first request identifier code to the first request to obtain the second request;

[0024] The sending unit is configured to send the second request to the native application processing terminal; wherein the second request is used by the native application processing terminal to perform the following processing:

[0025] Based on the first request identifier in the second request, the request parameters associated with the first request identifier are located, the first request in the second request is parsed to obtain the parsing result, the parsing result and the found request parameters are assembled to obtain the page loading request, and the page loading request is sent to the web application server.

[0026] This disclosure provides an apparatus for loading web application content through a native application, applied to a native application processing end, wherein the native application processing end has a pre-installed plugin, and the apparatus includes:

[0027] The first receiving unit is configured to receive and store the request parameters and the first request identifier code sent by the pre-plugin, wherein the request parameters are obtained by the pre-plugin from the first request when it receives the first request, the first request identifier code is generated by the pre-plugin for the first request, and the first request is used to characterize the native application requesting to load the web application content.

[0028] The second receiving unit is configured to receive a second request sent by the pre-plugin, wherein the second request includes the first request and the first request identifier code;

[0029] The lookup unit is configured to look up the request parameters stored in association with the first request identifier code based on the first request identifier code in the second request;

[0030] The processing unit is configured to parse the first request in the second request, obtain the parsing result, assemble the parsing result and the found request parameters to obtain a page loading request, and send the page loading request to the web application server.

[0031] This disclosure provides an electronic device, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described above for loading web application content through a native application.

[0032] This disclosure provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described above for loading web application content through a native application.

[0033] This disclosure provides a computer program product including a computer program that is read and executed by a processor of a computer device, causing the computer device to perform the method described above for loading web application content through a native application.

[0034] In this embodiment, since the native application processor cannot parse the request parameters after receiving the first request, a pre-plugin is set up for the native application processor. Upon receiving the first request from the native application to load web application content, the pre-plugin intercepts it, obtains the request parameters, generates a first request identifier code to identify the target request, and sends the request parameters and the first request identifier code to the native application processor for associated storage. Because the pre-plugin can obtain the request parameters of the first request, and the relationship between the pre-plugin and the native application processor is a normal transmission relationship, not restricted by protocol, the native application processor can receive the request parameters sent by the pre-plugin and associate them with the first request identifier code. When the pre-plugin forwards the first request to the native application processor, it also forwards the first request identifier code accordingly. In this way, the native application processor can find the associated stored request parameters based on the first request identifier code and integrate the found request parameters with the parsing result of the first request into a page loading request. Compared to related technologies where the page loading request sent to the web application server only contains the parsing result, the page loading request in this embodiment contains not only the parsing result but also request parameters, thus preventing the final loading and display from failing due to missing request parameters.

[0035] Other features and advantages of this disclosure will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the disclosure. The objectives and other advantages of this disclosure may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0036] The accompanying drawings are provided to further understand the technical solutions of this disclosure and constitute a part of the specification. They are used together with the embodiments of this disclosure to explain the technical solutions of this disclosure and do not constitute a limitation on the technical solutions of this disclosure.

[0037] Figure 1 is a system architecture diagram of the method for loading web application content through native application according to an embodiment of the present disclosure;

[0038] Figure 2A illustrates a method for loading web application content via native application using relevant technologies in a page loading scenario;

[0039] Figure 2B illustrates a schematic diagram of the method for loading web application content via native application according to an embodiment of the present disclosure in a page loading scenario;

[0040] Figure 3 is a flowchart of a method for loading web application content through a native application by a pre-plugin according to an embodiment of the present disclosure;

[0041] Figure 4 is a flowchart of obtaining the request parameters of the first request and generating the first request identifier code according to an embodiment of the present disclosure;

[0042] Figure 5 is a flowchart of encoding request body parameters according to an embodiment of the present disclosure;

[0043] Figure 6 is a schematic diagram illustrating the implementation process of encoding request body parameters according to an embodiment of the present disclosure;

[0044] Figure 7 is a flowchart of generating a second request according to an embodiment of the present disclosure;

[0045] Figure 8 is a flowchart showing that the determined request parameters have been stored in the native application processing end according to an embodiment of the present disclosure;

[0046] Figure 9 is a flowchart of the deployment of a pre-plugin according to an embodiment of the present disclosure;

[0047] Figure 10 is an overall execution flowchart of the pre-plugin according to an embodiment of the present disclosure;

[0048] Figure 11 is a flowchart of a method for loading web application content through a native application, executed by a native application processing terminal according to an embodiment of the present disclosure;

[0049] Figure 12 is a flowchart of parsing a first request according to an embodiment of the present disclosure;

[0050] Figure 13 is a flowchart of an assembly page loading request according to an embodiment of the present disclosure;

[0051] Figure 14 is a flowchart of object verification according to an embodiment of the present disclosure;

[0052] Figure 15 is a detailed flowchart of the assembly page loading request according to an embodiment of the present disclosure;

[0053] Figure 16 is a flowchart of loading web application content according to an embodiment of the present disclosure;

[0054] Figure 17 is a flowchart of a web application server providing target resources according to an embodiment of the present disclosure;

[0055] Figure 18 is a flowchart of a first verification according to an embodiment of the present disclosure;

[0056] Figure 19 is a flowchart of the first sub-verification according to an embodiment of the present disclosure;

[0057] Figure 20 is a flowchart of the second sub-verification according to an embodiment of the present disclosure;

[0058] Figure 21 is a schematic diagram illustrating the implementation details of a method for loading web application content through a native application according to an embodiment of the present disclosure;

[0059] Figures 22A and 22B are experimental time comparison charts between the embodiments of this disclosure and the prior art methods for loading web application content through native applications;

[0060] Figure 23 is a block diagram of an apparatus for loading web application content through a native application according to an embodiment of the present disclosure;

[0061] Figure 24 is a block diagram of an apparatus for loading web application content through a native application according to an embodiment of the present disclosure;

[0062] Figure 25 is a terminal structure diagram of a method for loading web application content through a native application according to an embodiment of the present disclosure;

[0063] Figure 26 is a server structure diagram of a method for loading web application content through a native application according to an embodiment of the present disclosure. Detailed Implementation

[0064] To make the objectives, technical solutions, and advantages of this disclosure clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this disclosure.

[0065] Before providing a further detailed description of the embodiments of this disclosure, the terms and concepts used in these embodiments are explained, and they are subject to the following interpretations:

[0066] Domain name blocking: Domain name blocking is a type of internet attack that involves attacking or forging Domain Name Resolution Servers (DNS) to redirect the target website's domain name to an incorrect IP address. This prevents users from accessing the target website or intentionally or maliciously forces users to access a specific IP address (website).

[0067] HTTPDNS, a DNS server cluster based on the Hypertext Transfer Protocol (HTTP), is a domain name resolution service for multi-platform applications (mobile apps, PC client applications). It features domain name anti-interception, precise scheduling, and real-time resolution effectiveness. It is typically suitable for mobile applications (APPs) to prevent malicious interception or for applications with high access speed requirements.

[0068] Hybrid applications (or hybrid apps) are software applications that combine elements of both native applications and web applications. Essentially, a hybrid application is a web application with a native application shell. Once the user downloads and installs the application locally, the native application shell connects to any functionality offered by the mobile platform via a browser embedded within the application. The browser and its plugins run in the background and are invisible to the end user.

[0069] Native apps refer to native programs, generally relying on the operating system, possessing strong interactivity, and being complete apps with high extensibility. They require users to download and install them. In short, native apps are specifically developed for operating systems, such as Apple's iOS and Android, and run on their respective mobile devices. The architecture of a native app typically consists of two parts: "cloud server data + app client." All user interface (UI) elements, data content, and logic framework of the app are installed on the mobile terminal. Furthermore, native apps differ from web applications. Web applications are web applications that run in a browser, while native apps can directly call the mobile operating system's device API.

[0070] Figure 1 is a system architecture diagram of the method for loading web application content through a native application according to an embodiment of the present disclosure. The system architecture of the method for loading web application content through a native application includes a terminal 140, an Internet 130, a gateway 120, a native application server 110, a web application server 160, and a database 150, etc.

[0071] Terminal 140 can take various forms, such as a desktop computer, laptop computer, personal digital assistant (PDA), mobile phone, in-vehicle terminal, home theater terminal, or dedicated terminal. Furthermore, terminal 140 can be a single device or a collection of multiple devices. Terminal 140 can communicate with the Internet 130 via wired or wireless means to exchange data. Terminal 140 includes a hybrid app consisting of a web application with a pre-installed plugin and a native application; the hybrid app allows web application content to be loaded within the native application.

[0072] Native application server 110 and web application server 160 refer to computer systems that can provide certain services to terminal 140. Compared to ordinary terminal 140, native application server 110 and web application server 160 have higher requirements in terms of stability, security, and performance. Native application server 110 and web application server 160 can be a single high-performance computer in a network platform, a cluster of multiple high-performance computers, a portion of a single high-performance computer (e.g., a virtual machine), or a combination of portions of multiple high-performance computers (e.g., virtual machines). Native application server 110 and web application server 160 contain various types of services, and the implementation of each service of native application server 110 and web application server 160 is often associated with some intermediate databases or storage media. The native application server 110 responds to business requests sent by the target object on the web application of the hybrid APP, receives request parameters and other information sent by the front-end plugin, and initiates a direct IP connection request to the web application server 160 based on the business request and request parameters, so as to load the web application content on the hybrid APP on the terminal 140. The direct IP connection request refers to the native application server 110 bypassing traditional Domain Name System (DNS) resolution or intermediate proxy layers and directly initiating a network request to the web application server 160. The database 150 stores the request parameters and other information obtained from the front-end plugin.

[0073] Gateway 120, also known as an internetwork connector or protocol converter, is a computer system or device that enables network interconnection at the transport layer and acts as a translator. It bridges the gap between two systems using different communication protocols, data formats, languages, or even completely different architectures. Gateway 120 also provides filtering and security functions. Messages sent from terminal 140 to native application server 110 and web application server 160 are forwarded to the corresponding native application server 110 and web application server 160 via gateway 120. Similarly, messages sent from native application server 110 and web application server 160 to terminal 140 are also forwarded to the corresponding terminal 140 via gateway 120.

[0074] Figure 2A illustrates the specific application of this technology in loading web application content during a page loading scenario. When a regular web application (web application / web browser) sends a data request (POST request) to a server, with the domain name "https: / / www.xxx.com" and the request parameters "request body: a=1&b=1", the request is prone to being intercepted. The domain name is often replaced with another domain name, resulting in the web application server providing the required network resources, and the browser failing to display the necessary web application content.

[0075] Based on this, to reduce the risk of domain name interception, another implementation method has been proposed. When a web application (webview) in a hybrid application sends a data request (POST request) to the server, the domain name address in the request is "https: / / www.xxx.com", and the request parameter is "request body: a=1&b=1". In this case, the hybrid application can access a domain name resolution service to convert the domain name address in the request into the IP address "https: / / 1.2.3.4", changing the original request to an IP address + request parameter format, thus reducing the risk of domain name interception. However, the request parameter "request body: a=1&b=1" in the POST request cannot pass certificate verification and cannot be parsed to send to the web application server. The web application server cannot obtain the specific request parameters, which will also lead to the inability to load the required web application content.

[0076] The embodiments disclosed herein can be applied to various scenarios, such as the page loading scenario shown in Figure 2B.

[0077] To address the aforementioned issues, this disclosure provides a method for loading web application content via a native application. This method effectively prevents domain name interception and ensures that request parameters are successfully sent to both the native application and the web application server, thereby improving the content loading success rate. A pre-plugin on the native application processing end (i.e., the native application server 110) intercepts a first request sent to the native application processing end. This first request represents a request from the native application to load web application content. The pre-plugin obtains the request parameters of the first request, generates a first request identifier code to identify the first request, and sends the request parameters and the first request identifier code to the native application processing end for associated storage. The first request identifier code is then added to the first request to obtain a second request, which is then sent to the native application processing end. Upon receiving the second request, the native application processing end, based on the first request identifier code in the second request, searches for the request parameters associated with the first request identifier code, parses the first request in the second request, obtains the parsing result, assembles the parsing result and the found request parameters to obtain a page loading request, and sends the page loading request to the web application server 160.

[0078] Figure 2B illustrates a specific schematic of loading web application content in a page loading scenario according to an embodiment of this disclosure. A front-end plugin (JSBridge) is set up between the web application and the native application in the hybrid application as a bridge for data transmission. When the web application in the hybrid application requests to load web application content from the web application server, firstly, when the web application (web application / webview) in the hybrid application initiates a request (POST request) with data to the server, the domain name address in the request is "https: / / www.xxx.com", and the request parameters are "request body: a=1&b=1". At this time, the front-end plugin (JSBridge) in the hybrid application intercepts the POST request. In step 1, the front-end plugin generates a unique identifier code AA124 for the POST request and obtains the request parameters; in step 2, the front-end plugin sends the request parameters and the unique identifier code to the native application. In step 3, the native application saves the correspondence between the identifier code and the request parameters (a=1&b=1, AA124); in step 4, the native application notifies the front-end plugin that the identifier code and request parameters have been stored and that it can continue to send requests. In step 5, the pre-plugin sends a request (a POST request with an identifier (httpsdns: / / www.xxx.com?identifier=AA124)) to the native application. In step 6, the request is intercepted, the request parameters are obtained through the identifier, HTTPDNS is used for request resolution, and the request parameters are written into a new request. That is, the native application uses HTTPDNS to resolve the domain name address "https: / / www.xxx.com" into the IP address "https: / / 1.2.3.4", then uses the identifier of the intercepted POST request with the identifier to find the request parameters, and assembles a new request containing the IP address "https: / / 1.2.3.4" and the request parameters "request body: a=1&b=1". In step 7, the native application sends a new request to the web application server. In step 8, the web application server returns the requested data; that is, the web application server returns the requested data through the native application and loads the web application content through the web application.

[0079] This disclosure provides a method for loading web application content through a native application. This method is generally used in hybrid applications where fast and accurate content loading is required, such as the page loading scenario shown in Figure 2B. This disclosure also provides a scheme for data transfer by setting a pre-plugin (i.e., a pre-plugin set for the native application processing end) between the web application and the native application, which can reduce loading failures when loading web application content through the native application.

[0080] As shown in Figure 3, the method for loading web application content through a native application provided in this embodiment of the present disclosure is applied to a pre-plugin set for the native application processing end.

[0081] The native application processing end refers to the server processing part of the native application, such as the native application server.

[0082] A front-end plugin refers to a functional plugin in a hybrid application that acts as a bridge between the native application and the web application. Front-end plugins enable message passing between the native and web applications, ensuring seamless interaction and data sharing. For example, a front-end plugin supports the web application sending requests to the native application (such as calling device APIs or retrieving user data), supports the native application proactively pushing data (such as notifications or status updates) to the web application, and can convert JavaScript calls from the web side into instructions recognizable by the native side (such as Java / Kotlin, Objective-C / Swift), and vice versa. In this embodiment, the front-end plugin can be a JavaScript SDK (JSSDK) interface, which is a set of API interfaces. The JSSDK can utilize the JSBridge principle (a technology that allows interaction between JavaScript code and native applications) to establish a communication bridge between the web application running in the webview and the native application, enabling bidirectional communication between the web application and the native application. The pre-plugin can also encrypt and sign the communication content to prevent malicious code injection or illegal calls. When the web page layer of a hybrid app is restricted (such as cross-domain issues or inability to directly access certain APIs), the pre-plugin can proxy the request to the native layer for processing.

[0083] The following section, with reference to Figure 3, explains how to load web application content through a native application. The specific steps are as follows:

[0084] Step 310: Intercept the first request sent to the native processing end;

[0085] Step 320: Obtain the request parameters of the first request, generate a first request identifier code to identify the first request, and send the request parameters and the first request identifier code to the native application processing end for associated storage;

[0086] Step 330: Add the first request identifier code to the first request to obtain the second request;

[0087] Step 340: Send the second request to the native application processing end so that the native application processing end can find the request parameters stored in association with the first request identifier code based on the first request identifier code in the second request, parse the first request, obtain the parsing result, assemble the parsing result and the found request parameters to obtain the page loading request, and send the page loading request to the web application server.

[0088] Steps 310-340 are described in detail below.

[0089] In step 310, the first request sent to the native processing end is intercepted.

[0090] The first request represents a native application requesting to load web application content. This first request includes the domain name of the web application server where the resource corresponding to the web application content to be loaded resides (specifying the web server where the resource is located), and request parameters identifying the resource (parameters that identify the specific resource to be loaded, i.e., the specific resource to be loaded or to pass necessary information such as page path, user ID, environment identifier, etc.). In short, the first request is initiated by the native application to request the loading of web application (Web App) content. This first request is typically initiated directly by the native application server (or client-side native code), with the goal of obtaining the necessary HTML, JS, CSS, and other resources from the web application server and rendering them in the WebView.

[0091] Taking loading the user's profile page as an example, let's illustrate the first request. The request method for the first request is GET; the domain address for the first request is https: / / web.xxxx.com / user; the request parameters (URL query parameters) for the first request are: user_id = 12345 (unique user identifier); token = abcde (login credentials, provided by the native layer). Thus, the native application loads the user's profile H5 page through this first request, and the web server returns the corresponding user data based on the user_id and token.

[0092] Taking submitting order data (a POST request) as an example, the first request has the following parameters: POST method; https: / / api.example.com / order / submit; and the request body data includes: product_id = 1001 (product ID); quantity = 2 (quantity); address_id = 456 (shipping address ID); and payment_method = alipay (payment method). Thus, the native application submits order information to the web server, and the server processes it and returns a payment page or order result.

[0093] In this specific implementation, when loading web application content through the native application, the target object first initiates a first request from the web application in the hybrid application to the native application to obtain resources for loading the web application content from the web application server. At this time, the pre-plugin intercepts the first request, preventing it from being sent to the native application processing end temporarily.

[0094] In step 320, the request parameters of the first request are obtained, a first request identifier code is generated to identify the first request, and the request parameters and the first request identifier code are sent to the native application processing end for associated storage.

[0095] Request parameters are used to indicate the parameters present in the request body of the first request that are to be sent to the web application server. The request body refers to the part of the first request used in the HTTP protocol to transmit the data sent from the web page to the web application server. Request parameters can also be called body parameters.

[0096] The first request identifier is used to identify the first request and distinguish it from other requests. The first request identifier for each first request is unique. For example, the first request identifier is an encoded string used to uniquely identify the first request, ensuring that different requests are not confused.

[0097] It should be noted that the embodiments disclosed herein are not limited to the form of generating the first request identifier. As an example of generating the first request identifier, the request parameters (such as URL, user_id, timestamp) in the first request are concatenated into a string, and a hash operation (such as SHA-256) is performed on the concatenated string to generate a fixed-length unique code (i.e., the first request identifier). For example, if the original parameters in the first request are url = https: / / example.com / page&user_id = 123 × tamp = 1630000000, the final generated first request identifier is d4e5f6... (hash result). As another example of generating the first request identifier, the current timestamp of receiving the first request is obtained, and a random string is obtained. The current timestamp and the random number string are concatenated to obtain the first request identifier.

[0098] In this specific implementation, firstly, the request content of the first request is parsed to obtain the parameters of the request body portion, thus obtaining the request parameters. Next, a unique identifier is generated for the first request using a random number algorithm or other algorithm, serving as the first request identifier. Further, the mapping relationship between the first request identifier and the request parameters is determined. According to the mapping relationship, the request parameters and the first request identifier are sent to the native application processing end, enabling the native application processing end to associate and store the request parameters and the first request identifier according to the mapping relationship, thereby ensuring that one first request identifier uniquely corresponds to one request parameter.

[0099] In step 330, a first request identifier code is added to the first request to obtain the second request.

[0100] The second request can be a Uniform Resource Locator (URL) request, which is formed by concatenating the first request and the first request identifier. Since a URL request identifies the address of a resource on the Internet and specifies the method of locating that resource, the second request in this embodiment of the disclosure can locate the specific location of the resource corresponding to the web application content to be loaded, and specify the method of locating this resource.

[0101] In the specific implementation of this embodiment, firstly, the concatenation method of the first request and the first request identifier is determined. Then, according to the concatenation method, the front-end plugin concatenates the first request and the first request identifier to obtain the second request.

[0102] It should be noted that, in order to ensure that the second request meets the protocol transmission requirements, the pre-plugin does not modify the content and format of the first request when splicing the first request and the first request identifier code; it simply appends the first request identifier code to the first request.

[0103] In step 340, the second request is sent to the native application processing end, so that the native application processing end can find the request parameters stored in association with the first request identifier code based on the first request identifier code in the second request, parse the first request, obtain the parsing result, assemble the parsing result and the found request parameters to obtain the page loading request, and send the page loading request to the web application server.

[0104] The parsing result is used to indicate the address (such as IP address) of the web application server that provides the web application content.

[0105] A page load request is a request sent from the native application processor to the web application server to load the content of the web application. The page load request includes the web application server's address (derived from the domain name) and the aforementioned request parameters.

[0106] Among them, a web application server refers to a server that can provide various business-side resources for rendering different content.

[0107] In this specific implementation, in order to obtain resources from the web application server for loading web application content, the pre-plugin sends a second request to the native application processing end according to the protocol requirements. The native application processing end then creates a direct IP connection request (page loading request) with an IP address and request parameters based on the second request. This allows the native application processing end to make a resource acquisition request to the web application server via a direct IP connection, thereby enabling the web application server to provide resources according to the request and load the web application content through the native application.

[0108] To save space, the specific process of the native application processing terminal in this disclosure to find the request parameters stored corresponding to the first request identifier, the specific process of parsing the first request, and the specific process of assembling the parsing result and the request parameters into a page loading request and sending it to the web application server will be described in detail below when the execution flow of the native application processing terminal is described, and will not be repeated here.

[0109] Through steps 310-340 above, in this embodiment of the disclosure, since the native application processing end cannot parse the request parameters after receiving the first request, a front-end plugin is set up for the native application processing end. After receiving the first request from the native application to load web application content, the front-end plugin intercepts it, obtains the request parameters of the first request, generates a first request identifier code to identify the target request, and sends the request parameters and the first request identifier code to the native application processing end for associated storage. Since the front-end plugin can obtain the request parameters of the first request, and the relationship between the front-end plugin and the native application processing end is a normal transmission relationship, not restricted by protocol, the native application processing end can receive the request parameters sent by the front-end plugin and associate them with the first request identifier code. When the front-end plugin forwards the first request to the native application processing end, it also forwards the first request identifier code accordingly. In this way, the native application processing end can find the associated stored request parameters based on the first request identifier code and integrate the found request parameters with the parsing result of the first request into a page loading request. Compared to related technologies where the page loading request sent to the web application server only contains the parsing result, the page loading request in this embodiment contains not only the parsing result but also request parameters, thus preventing the final loading and display from failing due to missing request parameters.

[0110] The above is a general description of steps 310-340. Since step 310 has been detailed in the above general description, the specific implementations of steps 320, 330 and 340 will be described in detail below.

[0111] Step 320 will be described in detail below.

[0112] In step 320, the request parameters of the first request are obtained, a first request identifier code is generated to identify the first request, and the request parameters and the first request identifier code are sent to the native application processing end for associated storage.

[0113] Referring to Figure 4, in one embodiment, the specific process of obtaining the request parameters of the first request and generating a first request identifier code to identify the first request may include, but is not limited to, the following steps 410-420:

[0114] Step 410: Extract the request body parameters of the first request and encode the request body parameters to obtain the request parameters;

[0115] Step 420: Based on the request type of the first request and the preset identifier generation method, generate a first request identifier code to identify the first request.

[0116] Steps 410-420 are described in detail below.

[0117] In step 410, the request body parameters of the first request are extracted and encoded to obtain the request parameters.

[0118] Request body parameters refer to the parameters contained in the request body of the first request and intended to be sent to the web application server. Common formats for request body parameters include JSON, XML, form data, etc.

[0119] In this specific implementation, firstly, with authorization, the parameters loaded in the request body of the first request are extracted to obtain the request body parameters of the first request. Next, since web applications and native applications can only transmit strings when transferring data via a pre-installed plugin, and request body parameters are often not limited to strings but may also include image data, form data, etc., the request body parameters are encoded and converted into string form to obtain the request parameters.

[0120] In this embodiment of the disclosure, the request body parameters are encoded in step 410, which can standardize the request parameters, unify the format of the request parameters, avoid parsing errors caused by special characters (such as &, =, and spaces), ensure the integrity of data during transmission, and enable the encoded parameters to adapt to the specifications of different protocols or platforms (such as HTTP / HTTPS, WebSocket), avoid request failures caused by differences in character sets, and improve the compatibility of request parameters.

[0121] In step 420, a first request identifier code is generated to identify the first request based on the request type of the first request and the preset identifier code generation method.

[0122] The request type indicates the operation that the first request is to perform in the web application.

[0123] For example, request types include, but are not limited to: POST requests for creating new resources, PUT requests for updating the appearance of a specified resource on the server or creating a new resource on the server, DELETE requests for deleting a specified resource from the server, and PATCH requests for providing fields or field values ​​to be updated in order to update resources on the server, etc.

[0124] The preset identification code generation method is used to indicate the specific method and process for generating the identification code.

[0125] In the specific implementation of this embodiment, the format of the request body parameters often differs depending on the request type. Therefore, firstly, the request type of the first request is determined based on the request body parameters. Next, based on the request type, the appropriate identifier generation method for this request type is found among preset identifier generation methods. Finally, a unique first request identifier is generated for the first request based on the found identifier generation method.

[0126] As an example, the first request identifier can be in the form of letters and numbers. Different request types correspond to different letters. The identifier generation method for the first request type specifies the letters to be used, and based on the numbers used for this request type before the current time, it increments by 1 from the numbers used before the current time to form the first request identifier. For example, the first request identifier for a certain first request might be AA19.

[0127] In addition, to improve the efficiency of identifier generation, the number of bits in the identifier code to be generated for the first request can be constrained by a preset identifier generation method. Then, a random number generation algorithm is used to generate a unique random number that meets the identifier code bit length requirement, and this generated random number is used as the first request identifier code.

[0128] For example, after obtaining the request parameters and generating the first request identifier, the pre-plugin first determines the message sending method applicable to the native application processing end. Then, based on this message sending method, it sends the request parameters and the first request identifier to the native application processing end, and the native application processing end associates and stores the first request identifier and the request parameters.

[0129] Specifically, when storing the first request identifier and request parameters together, the first request identifier can be used as the key for searching, and the request parameters can be used as the value to be searched. The first request identifier and request parameters can be stored in key-value pairs, thereby improving the convenience of searching for request parameters.

[0130] Table 1 illustrates how the native application processor associates and stores the first request identifier and request parameters in a predefined database. In this database, the first request identifier and request parameters are stored as key-value pairs. Specifically, the request parameter corresponding to the first request identifier KK14 is request parameter 1; the request parameter corresponding to the first request identifier AA13 is request parameter 2; the request parameter corresponding to the first request identifier B894a is request parameter 3; the request parameter corresponding to the first request identifier KK007 is request parameter 4; the request parameter corresponding to the first request identifier AA147 is request parameter 5; the request parameter corresponding to the first request identifier B8143 is request parameter 6; and the request parameter corresponding to the first request identifier MK0187 is request parameter 7.

[0131] Table 1 shows the pre-defined database storing request parameters and the first request identifier.

[0132] The advantage of this embodiment is that it addresses the limitation that only strings can be transmitted when data is transferred between web applications and native applications via a pre-installed plugin. After extracting the request body parameters of the first request, these parameters are encoded into string format. Simultaneously, a unique first request identifier is assigned to the first request. The mapped request parameters and the first request identifier are then sent to the native application's processing end for associated storage. This resolves the issue of the native application being unable to parse the request parameters of the first request, thus preventing the acquisition of these parameters. This allows the native application to obtain the request parameters of the first request more conveniently and quickly.

[0133] Referring to Figure 5, in one embodiment, step 410 may specifically include, but is not limited to, the following steps 510-520:

[0134] Step 510: Based on the request type of the first request, determine the target encoding method from multiple candidate encoding methods;

[0135] Step 520: Encode the request body parameters based on the target encoding method to obtain the request parameters.

[0136] Steps 510-520 are described in detail below.

[0137] In step 510, based on the request type of the first request, the target encoding method is determined from multiple candidate encoding methods.

[0138] Among them, the candidate encoding method is used to indicate the specific encoding method for the request body parameters of a request that meets a certain request type.

[0139] In the specific implementation of this embodiment, since the format of request body parameters often differs for different request types, different encoding methods are applicable to different request body parameter formats. Therefore, an appropriate encoding method can be set for each request type. Based on this, firstly, with permission, the mapping table between each candidate request type and each candidate encoding rule is invoked. Next, a candidate request type that matches the request type of the first request is searched in the mapping table. Finally, the candidate encoding method corresponding to the candidate request type that matches the request type of the first request in the mapping table is determined as the target encoding method.

[0140] Figure 6 illustrates the correspondence between different request types and candidate encoding methods. For example, when the request body parameter indicated by the request type is a binary data type (ArrayBuffer type), a large object of binary type such as an image, sound, or multimedia file (Blob type), or a general file type (File type), Base64 encoding is used as the target encoding method. Base64 encoding is used for request body parameters of ArrayBuffer, File, and Blob types. When the request body parameter indicated by the request type is a utility type used to process URL query strings (URLSearchParams type), key-value pair concatenation string encoding is used as the target encoding method. Key-value pair concatenation string encoding is used for request body parameters of URLSearchParams type. When the request body parameter indicated by the request type is a serialized table or form format data (FormData type), the encoding method is used for file types that are traversed and concatenated into specific domains (Multipart type) or form types that support file uploads (form-data type). Multipart or form-data type encoding is used for request body parameters of FormData type.

[0141] In step 520, the request body parameters are encoded based on the target encoding method to obtain the request parameters.

[0142] In the specific implementation of this embodiment, based on the target encoding rules, the request body parameters are encoded according to the order of the request body parameters in the first request, and all request body parameters are converted into string form to obtain the request parameters.

[0143] The effect achieved by steps 510 and 520 in this embodiment is that, considering the differences in the format of request body parameters carried by different request types, a matching encoding method is used for the request body parameters of each request type to encode the parameters, converting request body parameters with different formats into string form. This enables the request parameters to be successfully transmitted to the native application processing end using a pre-plugin, thereby improving the success rate of loading web application content through the native application. It also avoids request failures or data parsing errors caused by incompatibility between encoding methods and protocols, adapting to the interaction needs of multiple platforms (Web / App / API). There is no need to write multiple sets of parsing logic for different encoding methods; it is only necessary to decode the target encoding method according to the agreed rules (such as using Base64 to decode all POST request bodies), reducing redundant code.

[0144] Step 330 will be described in detail below.

[0145] In step 330, a first request identifier code is added to the first request to obtain the second request.

[0146] Referring to Figure 7, in one embodiment, the specific process of generating the second request may include, but is not limited to, the following steps 710-720:

[0147] Step 710: When the request parameters have been stored in the native application processing end, based on the request type of the first request, select the target concatenation method from multiple candidate concatenation methods;

[0148] Step 720: Create a second request based on the first request and the first request identifier using the target concatenation method.

[0149] Steps 710-720 are described in detail below.

[0150] In step 710, when the request parameters have been stored in the native application processing end, the target splicing method is selected from multiple candidate splicing methods based on the request type of the first request.

[0151] Among them, the candidate splicing method is used to indicate that the first request and the first request identifier code are spliced ​​into a whole without changing the specific content and original format of the first request.

[0152] In this specific implementation, firstly, if it is determined that the request parameters have been stored on the native application processing side, then, with permission, the mapping table between each candidate request type and each candidate concatenation method is invoked. Next, a candidate request type that matches the request type of the first request is searched in the mapping table. Finally, the candidate concatenation method corresponding to the candidate request type that matches the request type of the first request in the mapping table is determined as the target concatenation method.

[0153] In step 720, a second request is created based on the first request and the first request identifier code using a target concatenation method.

[0154] In the specific implementation of this embodiment, the first request and the first request identifier are concatenated into a whole according to the target concatenation method to obtain the second request.

[0155] For example, if the request body parameter indicated by the request type is a serialized table and form format data (FormData type), the candidate concatenation method is set to add the first request identifier to the beginning of the first request; if the request body parameter indicated by the request type is a utility type (URLSearchParams type) used to process URL query strings, the candidate concatenation method is set to add the first request identifier to the end of the first request.

[0156] The effect achieved by steps 710 and 720 in this embodiment is that, after determining that the first request and the first request identifier are stored, a second request is created and then initiated. This reduces the risk that the request parameters cannot be found even though the first request and the first request identifier were not successfully stored, but a second request has been sent. Since the pre-plugin merely appends the first request identifier to the first request without changing its specific form or content, the native application processing end receives a request that is almost identical to the first request initiated on the web application, thus improving request accuracy.

[0157] Referring to Figure 8, in one embodiment, the specific process of determining that the request parameters have been stored on the native application processing side may include, but is not limited to, the following steps 910-920:

[0158] Step 910: Receive message data sent by the native application processing end;

[0159] Step 920: When the message data contains the target field, determine that the request parameters have been stored on the native application processing side.

[0160] Steps 910-920 are described in detail below.

[0161] In step 910, message data sent by the native application processing end is received.

[0162] The message data is used to notify the front-end plugin that the first request identifier and request parameters have been stored.

[0163] For example, the native application processing end can send message data through the target function. The target function refers to the callback function that passes the function as a parameter to another function. The target function is called only after the native application processing end has completed the storage of the first request identifier and request parameters.

[0164] In this specific implementation, after the native application processor completes the storage of the first request identifier and request parameters, it calls a predefined JavaScript callback function (target function) to send message data to the web application, notifying the web application that the storage of the first request identifier and request parameters is complete. Based on this, the front-end plugin receives the message data sent by the native application processor through the target function.

[0165] In step 920, when the message data contains the target field, it is determined that the request parameters have been stored on the native application processing side.

[0166] The target field refers to the field used to identify where the first request identifier and request parameters are stored.

[0167] In the specific implementation of this embodiment, firstly, the message data is parsed to identify the code, fields, etc. contained in the message data. Then, if it is determined that the message data has a target field for identifying the first request identifier code and the completion of request parameter storage, it is determined that the request parameters have been completely stored on the native application processing side; if it is determined that the message data does not have a target field for identifying the first request identifier code and the completion of request parameter storage, it is determined that the request parameters have not been completely stored on the native application processing side.

[0168] The beneficial effects achieved by steps 910 and 920 in this embodiment are that by sending message data through the target function and determining whether the request parameters have been stored on the native application processing end based on whether the target field exists in the message data, the accuracy of parameter storage identification can be improved, so that a new request corresponding to the first request can be successfully assembled on the native application processing end, thereby reducing the failure of loading web application content through the native application.

[0169] Next, the deployment and initialization process of the pre-installed plugins will be described in detail.

[0170] Referring to Figure 9, in one embodiment, the specific process of deploying the pre-plugin may include, but is not limited to, the following steps 1010-1020:

[0171] Step 1010: Embed the pre-plugin into the web application and register the message sending method of the pre-plugin on the native application processing side;

[0172] Step 1020: Initialize the pre-plugin, wherein the initialized pre-plugin processes requests according to a predetermined logic.

[0173] Steps 1010-1020 are described in detail below.

[0174] In step 1010, the pre-plugin is embedded into the web application, and the message sending method of the pre-plugin is registered on the native application processing end.

[0175] Among them, web application refers to web application in hybrid applications. Web application in hybrid applications can be represented by a control (webview) used to display web pages.

[0176] The message sending method is used to indicate the sending process, message format, and so on for request messages. It's a core function of the pre-installation plugin, establishing a communication channel between the web application (WebView) and the native application's processing end, enabling bidirectional data transmission. Its core purpose is to allow the web application to securely and efficiently call native functions (such as camera, GPS, local storage, etc.) and receive responses or proactively pushed messages from the native application. By registering the pre-installation plugin's message sending method on the native application's processing end, bidirectional data transmission between the web application (WebView) and the native application is ensured.

[0177] In this specific implementation, firstly, with authorization, the pre-plugin is embedded into the web application, enabling the web application to interact with the native application processing end through the API provided by the pre-plugin. Next, the message sending method of the pre-plugin is registered on the native application processing end, ensuring that the data interaction between the native application processing end and the pre-plugin meets protocol requirements.

[0178] In step 1020, the pre-plugin is initialized, wherein the initialized pre-plugin processes requests according to predetermined logic.

[0179] The predefined logic is used to indicate the receiving and sending process of request messages by the front-end plugin, as well as the compatible protocol formats and request forms between the front-end plugin and web applications and native applications.

[0180] In this specific implementation, firstly, with authorization, predefined logic created for the pre-plugin and executed at runtime is obtained. Next, the predefined logic is injected into the pre-plugin as script code to perform the pre-plugin's initialization operation, enabling the pre-plugin to process requests according to the predefined logic during interaction between the web application and the native application.

[0181] The beneficial effects achieved by steps 1010 and 1020 in this embodiment are that embedding the pre-plugin into the web application and setting the pre-plugin before the native application processing end can quickly and conveniently build a data transmission bridge between the web application and the native application, improving the transmission efficiency and comprehensiveness of request messages, etc.

[0182] Figure 10 illustrates the overall workflow of the front-end plugin in the native application processing end. Step 1: Import the front-end plugin JSSDK into the H5 page of the web application. Step 2: Register the message passing method of the front-end plugin on the native application processing end (APP native). Step 3: Initialize the front-end plugin, the specific process of which is similar to steps 1010-1020 above. Step 4: The front-end plugin intercepts the first request initiated by the object in the web application, generates a first request identifier code for the first request, and generates a second request, the specific process of which is similar to steps 410-420 and 710-720 above. Step 5: The front-end plugin sends the first request identifier code and request parameters to the native application processing end. Step 6: The native application processing end saves the first request identifier code and request parameters, the specific process of which is similar to step 320 above. Step 7: Once the native application processing end has finished storing the corresponding first request identifier code and request parameters, it notifies the front-end plugin to continue initiating requests. Step 8: The pre-installation plugin sends a second request to the native application processor, the specific process of which is similar to steps 910-920 above. Step 9: The native application processor intercepts the second request, writes the request parameters, generates and sends a page loading request to the web application server, the specific process of which is similar to step 340 above. For the sake of brevity, these details will not be elaborated further.

[0183] The following is a general description of the specific execution method of the native application processing terminal in the embodiments of this disclosure.

[0184] According to another embodiment of this disclosure, a method for loading web application content through a native application is provided.

[0185] As shown in Figure 11, a method for loading web application content through a native application according to an embodiment of the present disclosure is applied to the native application processing end.

[0186] The method of loading web application content through native applications can include:

[0187] Step 1210: Receive the request parameters and the first request identifier code sent by the front-end plugin and store them together;

[0188] Step 1220: Receive the second request sent by the pre-plugin;

[0189] Step 1230: Based on the first request identifier in the second request, find the request parameters stored in association with the first request identifier;

[0190] Step 1240: Parse the first request in the second request to obtain the parsing result. Assemble the parsing result and the found request parameters to obtain the page loading request, and send the page loading request to the web application server.

[0191] Steps 1210-1240 are described in detail below.

[0192] In step 1210, the request parameters and the first request identifier code sent by the pre-plugin are received and associated and stored.

[0193] The request parameters are obtained by the pre-plugin from the first request when it receives the first request. The first request identifier is generated by the pre-plugin for the first request. The first request is used to indicate that the native application is requesting to load web application content.

[0194] In this specific implementation, after the front-end plugin obtains the request parameters and generates the first request identifier, it sends the request parameters and the generated first request identifier to the native application processing end. Based on this, the native application processing end receives the request parameters and the first request identifier sent by the front-end plugin, thus compensating for the original inability to parse the request parameters from the business requests sent by the web application.

[0195] Since the first request identifier is used to uniquely identify the first request, in order to distinguish the request parameters of different requests, the native application processing end will also store the request parameters of the first request and the first request identifier in correspondence, so that there is a one-to-one correspondence between the first request identifier and the request parameters.

[0196] In step 1220, a second request sent by the pre-plugin is received.

[0197] The second request includes the first request and the first request identifier.

[0198] In this specific implementation, after the front-end plugin generates the second request, it will send the second request to the native application processing end after confirming that the first request identifier and request parameters have been stored. Based on this, the native application processing end will receive the second request sent by the front-end plugin.

[0199] It should be noted that the second request is identical to the first request except for the first request identifier. Therefore, the native application processor obtains the first request and its identifier from the second request. When parsing the first request within the second request, the native application processor still cannot directly extract the request parameters.

[0200] In step 1230, based on the first request identifier in the second request, the request parameters stored corresponding to the first request identifier are located.

[0201] In this specific implementation, the native application processor stores multiple request identifiers and corresponding request parameters in a predetermined database. Based on this, with authorization, the predetermined database is invoked. This database contains multiple candidate request identifiers and corresponding candidate request parameters for each candidate identifier. Each candidate request parameter is present in a request initiated by the web application. Next, the first request identifier in the second request is compared with each candidate request identifier. The candidate request parameter corresponding to the candidate request identifier that matches the first request identifier is used as the found request parameter stored corresponding to the first request identifier.

[0202] In step 1240, the first request in the second request is parsed to obtain the parsing result. The parsing result and the found request parameters are assembled to obtain the page loading request, and the page loading request is sent to the web application server.

[0203] To save space, the specific process of parsing the first request and assembling the parsing result and request parameters in this embodiment will be described in detail below, and will not be repeated here.

[0204] Through steps 1210-1240 above, in this embodiment of the disclosure, a pre-plugin is set up before the native application processing end. After receiving a first request to load web application content via the native application, the pre-plugin intercepts it, obtains the request parameters of the first request, generates a first request identifier code to identify the target request, and sends the request parameters and the first request identifier code to the native application processing end for associated storage. Since the pre-plugin can recognize the format of the first request and obtain the request parameters, and since its communication with the native application processing end is a normal transmission without protocol restrictions, the native application processing end can receive the request parameters and associate them with the first request identifier code. When the pre-plugin forwards the first request to the native application processing end, it also forwards the first request identifier code accordingly. In this way, the native application processing end can find the associated stored request parameters based on the first request identifier code and integrate them with the parsing result of the first request to form a page loading request. Compared with the related technologies where the page loading request sent to the web application server only contains the parsing result, this page loading request contains both the parsing result and the request parameters, thus preventing the final loading and display from failing due to missing request parameters.

[0205] The above is a general description of steps 1210-1240. Since steps 1210, 1220 and 1230 have been detailed in the above general description, the specific implementation of step 1240 will be described in detail below.

[0206] Step 1240 will be described in detail below.

[0207] In step 1240, the first request in the second request is parsed to obtain the parsing result. The parsing result and the found request parameters are assembled to obtain the page loading request, and the page loading request is sent to the web application server.

[0208] Referring to Figure 12, in one embodiment, the specific process of parsing the first request may include, but is not limited to, the following steps 1310-1320:

[0209] Step 1310: Based on the predetermined loading conditions, determine the target domain name resolution service from multiple candidate domain name resolution services;

[0210] Step 1320: Based on the target domain name resolution service, perform domain name resolution on the first request in the second request to obtain the resolution result.

[0211] Steps 1310-1320 are described in detail below.

[0212] In step 1310, the target domain name resolution service is determined from multiple candidate domain name resolution services based on predetermined loading conditions.

[0213] The pre-defined loading conditions include the time range for limiting the loading of web application content for the first request, or the degree of prevention of domain name interception required for the domain name resolution service for the first request.

[0214] Candidate domain name resolution services are used to indicate domain name resolution services from different sources. For example, candidate domain name resolution services include, but are not limited to, HttpDNS and LocalDNS services differentiated by network location; they can also include various domain name resolution services differentiated by different ISPs. The Domain Name System (DNS) is one of the core infrastructures of the Internet, used to translate human-readable domain names (such as www.example.com) into machine-readable IP addresses (such as 192.0.2.1) so that devices can correctly access target servers.

[0215] In this specific implementation, the latency and degree of domain name interception prevention vary for each candidate domain name resolution service. Therefore, firstly, the latency score and anti-interception score of each candidate domain name resolution service are determined. The latency score is obtained by averaging the latency data of the candidate domain name resolution service up to the current time and inputting this average into a first function, which is a decreasing function with latency data as the independent variable and latency score as the dependent variable. The anti-interception score is determined based on the non-interception rate of the candidate domain name resolution service up to the current time. The non-interception rate is the proportion of all requests processed by the candidate domain name resolution service that did not result in domain name interception. The non-interception rate is then input into a second function to obtain the anti-interception score, which is an increasing function with the non-interception rate as the independent variable and anti-interception score as the dependent variable.

[0216] For example, among multiple candidate domain name resolution services, the one that meets both the anti-interception score and latency score, and thus meets the predetermined loading conditions, is selected as the intermediate domain name resolution service. Finally, one of the intermediate domain name resolution services is randomly selected as the target domain name resolution service.

[0217] For example, considering both the latency performance and the ability to prevent domain name blocking in DNS resolution services, the following steps are taken: First, weighting coefficients are assigned to the latency score and the anti-blocking score. The latency weighting coefficient is determined based on current network quality requirements; higher network quality requirements result in a larger latency weighting coefficient. The anti-blocking weighting coefficient is determined based on the current security threat level; higher security threat levels result in a larger anti-blocking weighting coefficient. Then, a comprehensive score is calculated for each candidate DNS resolution service. This comprehensive score is obtained by multiplying the latency score by the latency weighting coefficient and adding the anti-blocking score multiplied by the anti-blocking weighting coefficient. From among the candidate DNS resolution services, those whose comprehensive scores meet a predetermined threshold are selected as intermediate DNS resolution services. Finally, one intermediate DNS resolution service is randomly selected as the target DNS resolution service.

[0218] It should be noted that, based on experimental comparisons, in this embodiment of the disclosure, HttpDNS can be preferentially selected as the target domain name resolution service.

[0219] In step 1320, based on the target domain name resolution service, the first request is resolved to obtain the resolution result.

[0220] In this specific implementation, when performing domain name resolution on the first request, the native application processor first uses a protocol supported by the target domain name resolution service to directly access the target domain name resolution service's interface and sends the domain name address from the first request to the target domain name resolution service. Next, the target domain name resolution service, based on the domain name address provided by the native application processor, finds the IP address of the server with the lowest configured access latency and returns it to the native application processor. Finally, the native application processor uses the obtained IP address as the resolution result.

[0221] The beneficial effects achieved by steps 1310 and 1320 in this embodiment are that, based on predetermined loading conditions, the target domain name resolution service that best meets the requirements is selected from multiple candidate domain name resolution services, and then the target domain name resolution service is used to perform domain name resolution on the first request. This can improve the security of domain name resolution and reduce the latency of request transmission and the risk of domain name interception.

[0222] Referring to Figure 13, in one embodiment, the specific process of assembling the parsing results and request parameters to obtain a page loading request may include, but is not limited to, the following steps 1410-1420:

[0223] Step 1410: Perform object verification on the target object that initiated the first request;

[0224] Step 1420: When the object verification passes, assemble the page loading request based on the parsing results and the found request parameters.

[0225] Steps 1410-1420 are described in detail below.

[0226] In step 1410, object verification is performed on the target object that initiated the first request.

[0227] In this context, the target object refers to the user who initiates the request to load web application content in a web application within a hybrid application (Web page).

[0228] Among them, object verification is used to verify whether the target object has the permission to send the request corresponding to the request type to which the first request belongs.

[0229] To save space, the specific process of object verification of the target object initiating the first request in this embodiment of the present disclosure will be described in detail below. It will not be repeated here.

[0230] In step 1420, when the object verification passes, a page loading request is assembled based on the parsing results and the found request parameters.

[0231] In this specific implementation, if the object verification passes, it indicates that the target object initiating the first request is legitimate and has the authority to send the first request, allowing the loading of the corresponding web application content based on the target object's request. Based on this, a page loading request is assembled from the parsing results and request parameters. The specific process of assembling the page loading request based on the parsing results and request parameters is similar to steps 1710-1730 below. For the sake of brevity, it will not be elaborated here.

[0232] The beneficial effect achieved by steps 1410 and 1420 in this embodiment is that after verifying that the target object has the permission to send the first request, the page loading request is assembled according to the first request. This can prevent the page loading request from being assembled when the target object does not have the permission to send the first request, thereby reducing resource consumption caused by erroneous requests.

[0233] Referring to Figure 14, in one embodiment, the specific process of performing object verification on the target object that initiated the first request may include, but is not limited to, the following steps 1510-1530:

[0234] Step 1510: Determine the terminal address of the target object;

[0235] Step 1520: Compare the terminal address with the candidate addresses of the authorized object that initiated the first request;

[0236] Step 1530: If a candidate address matches the terminal address, the object verification is confirmed to be successful; if no candidate address matches the terminal address, the object verification is confirmed to be unsuccessful.

[0237] Steps 1510-1530 are described in detail below.

[0238] In step 1510, the terminal address of the target object is determined.

[0239] The terminal address is used to represent the address of the terminal used by the target object.

[0240] In step 1520, the terminal address is compared with the candidate addresses of the authorized initiating objects for the first request.

[0241] The candidate address is the address of the terminal used by the authorized object that initiated the first request.

[0242] In the specific implementation of this embodiment, the terminal address is compared with the candidate addresses of the authorized initiating objects for the first request to determine whether the target object is one of the authorized initiating objects.

[0243] In step 1530, if a candidate address matches the terminal address, the object verification is deemed successful; if no candidate address matches the terminal address, the object verification is deemed unsuccessful.

[0244] For example, if a candidate address matches the terminal address, it indicates that the target object is one of the authorized objects to initiate the request, and the object verification is successful; if no candidate address matches the terminal address, it indicates that the target object is not an authorized object to initiate the request, and the object verification is unsuccessful, and the first request is rejected.

[0245] Table 2 shows the list of objects authorized to initiate the first request. For example, there are 7 objects authorized to initiate the first request. These 7 objects are, in order: Object 1 with candidate address Qeda1, Object 2 with candidate address dqaq414, Object 3 with candidate address dmqe89, Object 4 with candidate address cnad14, Object 5 with candidate address quncqo51, Object 6 with candidate address foqnfa87, and Object 7 with candidate address cmqfiqw09.

[0246] Table 2 List of authorized entities for the first request

[0247] The beneficial effect achieved by steps 1510 and 1520 in this embodiment of the present disclosure is that by comparing the terminal address of the target object with the candidate address of the authorized initiating object for the first request, it is possible to determine whether the target object is an authorized initiating object in a relatively quick manner, thereby improving the efficiency and accuracy of object verification.

[0248] Referring to Figure 15, in one embodiment, the specific process of assembling the parsed results and the found request parameters to obtain the page loading request may include, but is not limited to, the following steps 1710-1730:

[0249] Step 1710: Deencode the request parameters to obtain the request body parameters of the first request;

[0250] Step 1720: Fill the request body parameters into the predefined code template to obtain the target code segment;

[0251] Step 1730: Assemble the target code segment and the Internet Protocol address from the parsing result to obtain the page loading request.

[0252] Steps 1710-1730 are described in detail below.

[0253] In step 1710, the request parameters are de-encoded to obtain the request body parameters of the first request.

[0254] Decoding refers to restoring the request parameters from string format to the request body parameters.

[0255] In the specific implementation of this embodiment, firstly, the target encoding method used during encoding is determined according to the request type of the first request. Next, the request parameters conforming to the target encoding method are de-encoded into request body parameters in the parameter format corresponding to the request type, according to the request type of the first request. This process restores the string-formatted request parameters to request body parameters, enabling the native application processing end to obtain the request body parameters of the first request.

[0256] In step 1720, the request body parameters are filled into the predetermined code template to obtain the target code segment.

[0257] The pre-defined code template refers to the template used to load the request body parameters, and it is the template used by the request body of the first request.

[0258] The target code segment is used to indicate the code formed by the request body portion of the first request.

[0259] In the specific implementation of this embodiment, firstly, the position where the request body parameters are to be filled is determined in the predetermined code template, wherein the predetermined code template has a dictionary container request_header; then, the request body parameters are filled into the dictionary container request_header in the predetermined code template to form the target code segment.

[0260] In step 1730, the target code segment and the Internet Protocol address from the parsing result are assembled to obtain the page loading request.

[0261] In the specific implementation of this embodiment, the target code segment and the IP address in the parsing result are assembled into a request that a web application server can receive according to the protocol format, thus obtaining a page loading request.

[0262] The beneficial effect achieved by steps 1710-1730 in this embodiment is that the request parameters are de-encoded at the native application processing end to obtain the request body parameters loaded in the request body of the first request. The request body parameters are then filled into a predetermined code template to obtain the target code segment. The target code segment and the IP address are then assembled into a page loading request, enabling the native application processing end to initiate a direct IP connection to the web application server using the page loading request. This successfully sends the request to the web application server while preventing domain name interception, thereby improving the loading success rate of web application content loaded by the native application.

[0263] Referring to Figure 16, in one embodiment, after sending a page loading request to the web application server, the method for loading web application content via native application may also include, but is not limited to, the following steps 1810-1820:

[0264] Step 1810: Receive the target resource provided by the web application server based on the page loading request;

[0265] Step 1820: Load web application content based on the target resource.

[0266] Steps 1810-1820 are described in detail below.

[0267] In step 1810, the target resource provided by the web application server based on the page loading request is received.

[0268] The target resource refers to the resource in the web application server that can load the web application content required by the first request.

[0269] In this specific implementation, after the native application processor sends a page loading request to the web application server, the web application server determines the content of the web application to be loaded based on the page loading request, finds the corresponding target resource according to the required web application content, and sends the target resource to the native application processor. Based on this, the native application processor receives the target resource provided by the web application server according to the page loading request.

[0270] In step 1820, web application content is loaded based on the target resource.

[0271] In this specific implementation, the native application processing end uses the webview engine of the web application to load the web application content into a visual page for display, thereby realizing the loading of web application content through the native application.

[0272] The beneficial effect achieved by steps 1810-1820 in this embodiment is that after sending a page loading request to the web application server, the web application content is rendered and loaded using the webview engine based on the target resources provided by the web application server. This enables loading web application content through native applications, which can meet the page loading requirements of the first request for different request types and improve the loading success rate of web application content loaded through native applications.

[0273] The following is a detailed description of the target resources provided by the web application server in the embodiments of this disclosure.

[0274] Since different resources on a web application server have varying levels of security, providing resources directly based on page loading requests often leads to low resource security. Therefore, this disclosure provides a resource output scheme based on request verification, which can improve the security of web application servers providing resources to native applications.

[0275] Referring to Figure 17, in one embodiment, the web application server provides the target resource in the following manner:

[0276] Step 1910: Perform the first verification of the page loading request;

[0277] Step 1920: When the first verification passes, based on the page loading request, determine the target resource for loading the web application content from multiple candidate resources;

[0278] Step 1930: Based on the response to the page load request, provide the target resource.

[0279] Steps 1910-1930 are described in detail below.

[0280] In step 1910, the page load request is first verified.

[0281] The first verification is used to verify the legitimacy of the source and content of the page loading request.

[0282] To save space, the specific process of the first verification in this embodiment will be described in detail below. It will not be repeated here.

[0283] In step 1920, when the first verification passes, the target resource for loading the web application content is determined from multiple candidate resources based on the page loading request.

[0284] Candidate resources refer to the resources used to render different pages. Different candidate resources generally render different web pages.

[0285] In this specific implementation, if the first verification passes, the request body parameters from the page loading request are first extracted. Next, based on the request body parameters, the candidate resources indicated by the request body parameters are selected from multiple candidate resources. Finally, all selected candidate resources are integrated into the target resource.

[0286] In step 1930, the target resource is provided based on the response to the page load request.

[0287] In a specific implementation of this embodiment, when responding to a page loading request, the target resource is added to the response, thereby providing the target resource in response to the page loading request.

[0288] The beneficial effect achieved by the embodiments of this disclosure through steps 1910-1930 is that resource output is based on request verification, which introduces a verification step for the page loading request. Only when the first verification of the page loading request is successful will the target resource used to load the web application content be provided to the native application. This method can improve the security and reliability of the web application server providing resources to the native application.

[0289] Referring to Figure 18, in one embodiment, the specific process of performing the first verification of the page loading request may include, but is not limited to, the following steps 2010-2030:

[0290] Step 2010: Determine the object that initiated the page load request, the request timestamp, and the request content;

[0291] Step 2020: Perform the first sub-verification of the page loading request based on the initiating object and the request timestamp;

[0292] Step 2030: Based on the request content of the page loading request, perform a second sub-verification on the page loading request.

[0293] Steps 2010-2030 are described in detail below.

[0294] In step 2010, the object that initiated the page load request, the request timestamp, and the request content are determined.

[0295] The initiating object refers to the object that triggers the generation of the page loading request through the first request; it is essentially the object that initiates the first request.

[0296] The request timestamp is used to indicate the creation time of the page load request.

[0297] In the specific implementation of this embodiment, with authorization, the page loading request is parsed to obtain the initiating object of the page loading request, the request timestamp, and the request content.

[0298] In step 2020, the first sub-verification of the page loading request is performed based on the initiating object and the request timestamp.

[0299] The first sub-verification is used to verify whether the initiating object has the authority to initiate the request and whether the page loading request meets the time dimension requirements (whether it is time-sensitive).

[0300] To save space, the specific process of the first sub-verification in this embodiment will be described in detail below. It will not be repeated here.

[0301] In step 2030, a second sub-verification is performed on the page loading request based on the request content of the page loading request.

[0302] The second sub-verification is used to verify whether the content of the page loading request is correct.

[0303] To save space, the specific process of the second verification in this embodiment will be described in detail below. It will not be repeated here.

[0304] The beneficial effects achieved by steps 2010-2030 in this embodiment are as follows: through a hierarchical verification mechanism, firstly, in step 2010, the initiating object, timestamp, and request content of the request are accurately collected, providing a complete data foundation for subsequent verification; then, in step 2020, permission and timeliness verification is performed to ensure that the request source is legitimate and has not timed out, preventing unauthorized access or replay attacks; finally, in step 2030, the integrity of the request content is verified to ensure that the parameter format is correct and the data has not been tampered with, thereby comprehensively improving the security, reliability, and compliance of page loading requests and effectively defending against malicious requests.

[0305] Referring to Figure 19, in one embodiment, the specific process of the first sub-verification may include, but is not limited to, the following steps 2110-2120:

[0306] Step 2110: Based on the comparison between the initiating object and each authorized initiating object in the preset address mapping table, perform object verification on the page loading request;

[0307] Step 2120: When the object verification passes, perform time validity verification on the page loading request based on the time difference between the request timestamp and the current time.

[0308] Steps 2110-2120 are described in detail below.

[0309] In step 2110, object verification is performed on the page loading request based on the comparison between the initiating object and each authorized initiating object in the preset address mapping table.

[0310] The preset address mapping table is used to store the terminal addresses of each authorized initiating object.

[0311] In this specific implementation, step 2110 is similar to steps 1510-1530 described above. The difference is that the execution entity of steps 1510-1530 is the native application processing end, while the execution entity of step 2110 is the web application server. For the sake of brevity, further details will not be provided.

[0312] In step 2120, when the object verification passes, the time validity of the page loading request is verified based on the time difference between the request timestamp and the current time.

[0313] In this specific implementation, if object verification passes, it indicates that the initiating object has the necessary permissions. Based on this, firstly, the time difference between the request timestamp and the current time is calculated. Next, the time difference is compared with a predetermined time threshold, which is used to measure whether the page loading request is valid in the time dimension. Further, if the time difference is less than or equal to the predetermined time threshold, it indicates that the page loading request is valid in the time dimension, and the validity verification of the page loading request passes, and the first sub-verification passes. If the time difference is greater than the predetermined time threshold, it indicates that the page loading request has expired in the time dimension, and the validity verification of the page loading request fails, and the first sub-verification fails.

[0314] The beneficial effect achieved by steps 2110-2120 in this embodiment is that it considers verifying the time validity and source legitimacy of the page loading request. By using a serial verification method, the source legitimacy of the page loading request is verified first. Once the source legitimacy is confirmed, the timeliness of the page loading request is then verified. This improves the verification efficiency of the page loading request, thereby reducing the risk of being unable to load web application content through native applications and increasing the loading success rate.

[0315] Referring to Figure 20, in one embodiment, the specific process of the second sub-verification may include, but is not limited to, the following steps 2210-2230:

[0316] Step 2210: Obtain the public key of the object that initiated the page loading request;

[0317] Step 2220: Design the request content based on the object's public key to obtain the designing result;

[0318] Step 2230: Based on the designing result and the comparison with the request content of the first request, perform a second sub-verification on the page loading request.

[0319] Steps 2210-2230 are described in detail below.

[0320] In step 2210, the public key of the object that initiated the page loading request is obtained.

[0321] Among them, the object public key refers to the key publicly disclosed by the initiating object that initiates the page loading request. The object public key is used to decrypt data encrypted by the initiating object using the object private key corresponding to the object public key.

[0322] In a specific implementation of this embodiment, the public key of the object that initiated the page loading request can be obtained from the object that initiated the page loading request or from a trusted third-party platform.

[0323] In step 2220, the request content is designed based on the object's public key to obtain the designing result.

[0324] The decryption result is used to indicate the unencrypted content of the page loading request.

[0325] In the specific implementation of this embodiment, the request content is decrypted using the object's public key to achieve the designing process of the request content, and the decrypted result is used as the designing result.

[0326] In step 2230, a second sub-verification is performed on the page loading request based on the designing result and the comparison with the request content of the first request.

[0327] In this specific implementation, firstly, the desigration result is compared with the request content of the first request. Next, if the desigration result matches the request content of the first request, it indicates that the request content of the page loading request is correct, and the second sub-verification of the page loading request is determined to have passed. Conversely, if the desigration result does not match the request content of the first request, it indicates that the request content of the page loading request is incorrect, and the second sub-verification of the page loading request is determined to have failed.

[0328] The beneficial effect achieved by steps 2210-2230 in this embodiment is that, considering the verification of the correctness of the request content of the page loading request, and determining the correctness of the request content based on the consistency between the designing result and the request content of the first request, the accuracy of the page loading request can be improved, thereby reducing the risk of being unable to load web application content through native applications and improving the loading success rate.

[0329] The implementation details of the method for loading web application content through native applications according to embodiments of the present disclosure will be described in detail below with reference to Figures 21, 22A-22B.

[0330] Figure 21 illustrates the overall process of loading web application content through a native application in a hybrid application. Step 1: The web application initiates a first request via a webview. Step 2: The web application injects a custom request script into its pre-plugin to initialize the pre-plugin. After initialization, it obtains the request parameters, generates a first request identifier, and sends it to the native application processor (APP Naive). The specific process is similar to steps 310-320 above. Step 3: The native application processor receives and saves the request parameters and the first request identifier. Step 4: The native application processor notifies the web application to continue the request. At this point, the object sends a second request to the native application processor through the web application. Step 5: The webview intercepts the second request and sends it to the native application processor via the pre-plugin. The specific implementation process is similar to step 330 above. Step 6: The native application processor performs domain name resolution on the second request. Specifically, it calls the target domain name resolution service (HTTPDNSSDK) to obtain the resolution result, which includes an IP address. Step 7: Assemble a page load request using the IP address and request parameters found based on the first request identifier. The specific process is similar to steps 1230-1240 above. Step 8: The native application processor initiates a page load request (direct IP connection request) to the web application server (business server). Step 9: The web application server processes the page load request. Step 10: The web application server returns a response to the native application processor, providing resources for loading the web application content. This allows the native application processor to utilize the resources, respond to the web application's resource requests, load and display the web application content. The specific process is similar to steps 1810-1820 above. For brevity, these details will not be elaborated further.

[0331] Figure 22A illustrates a comparison of the latency of upload data requests of different data sizes when introducing a pre-plugin and different domain name resolution services, and when not introducing a pre-plugin and any domain name resolution service, according to an embodiment of this disclosure. For upload data requests of the same data size, the latency differences between introducing a pre-plugin and httpdns service, introducing a pre-plugin and localdns service, and not introducing a pre-plugin and any domain name resolution service are small. However, for upload data requests of different data sizes, the latency of introducing a pre-plugin and httpdns service, introducing a pre-plugin and localdns service, and not introducing a pre-plugin and any domain name resolution service increases with the size of the requested data. Therefore, the loading scheme proposed in this embodiment, which introduces a pre-plugin and httpdns service, does not differ significantly in latency from other schemes, but it can meet the content loading requirements of any request, thereby reducing loading failures when loading web application content through native applications.

[0332] Figure 22B illustrates a comparison of latency for download data requests of different data sizes when introducing a pre-plugin and different domain name resolution services, and when not introducing a pre-plugin and any domain name resolution service, according to an embodiment of this disclosure. For download data requests of the same data size, the latency differences between introducing a pre-plugin and httpdns service, introducing a pre-plugin and localdns service, and not introducing a pre-plugin and any domain name resolution service are small. However, for download data requests of different data sizes, the latency increases with the size of the requested data, depending on whether a pre-plugin and httpdns service are introduced, the latency between introducing a pre-plugin and localdns service, and the latency between not introducing a pre-plugin and any domain name resolution service. Therefore, the loading scheme proposed in this embodiment, which introduces a pre-plugin and httpdns service, does not show a significant difference in latency compared to other schemes, but it can meet the content loading requirements of any request, thereby reducing loading failures when loading web application content through native applications.

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

[0334] It should be noted that in various specific embodiments of this application, when processing is required based on data related to the characteristics of the target object, such as target object attribute information or a set of attribute information, the permission or consent of the target object will be obtained first. Furthermore, the collection, use, and processing of this data will comply with relevant laws, regulations, and standards. In addition, when embodiments of this application require obtaining target object attribute information, separate permission or consent from the target object will be obtained through pop-ups or redirection to a confirmation page. Only after obtaining the target object's separate permission or consent will the necessary target object-related data for the normal operation of the embodiments of this application be obtained.

[0335] Figure 23 is a schematic diagram of the structure of the apparatus 2500 for loading web application content through a native application according to an embodiment of this disclosure. The apparatus 2500 is applied to a front-end plugin configured for a native application processor. The apparatus 2500 includes:

[0336] Interception unit 2510 is configured to intercept a first request sent to the native application processing terminal, wherein the first request is used to indicate that the native application requests to load the web application content;

[0337] The acquisition unit 2520 is configured to acquire the request parameters of the first request, generate a first request identifier code to identify the first request, and send the request parameters and the first request identifier code to the native application processing terminal for associated storage.

[0338] The generation unit 2530 is configured to add the first request identifier code to the first request to obtain the second request;

[0339] Sending unit 2540 is configured to send the second request to the native application processing terminal; wherein the second request is used for the native application processing terminal to perform the following processing:

[0340] Based on the first request identifier in the second request, the request parameters associated with the first request identifier are located, the first request in the second request is parsed to obtain the parsing result, the parsing result and the found request parameters are assembled to obtain the page loading request, and the page loading request is sent to the web application server.

[0341] In some embodiments, the acquisition unit 2520 includes:

[0342] An encoding module (not shown) is configured to extract the request body parameters of the first request and encode the request body parameters to obtain the request parameters;

[0343] The generation module (not shown) is configured to generate a first request identifier code to identify the first request based on the request type of the first request and a preset identifier code generation method.

[0344] In some embodiments, the encoding module (not shown) is configured to: determine a target encoding method from multiple candidate encoding methods based on the request type of the first request; and encode the request body parameters based on the target encoding method to obtain the request parameters.

[0345] In some embodiments, the second request is generated as follows: when the request parameters have been stored on the native application processing end, a target splicing method is selected from multiple candidate splicing methods based on the request type of the first request; and the second request is created based on the first request and the first request identifier code using the target splicing method.

[0346] In some embodiments, determining that the request parameters are stored on the native application processing end includes: receiving message data sent by the native application processing end; and determining that the request parameters have been stored on the native application processing end when the message data contains a target field.

[0347] In some embodiments, the pre-plugin is deployed in the following manner: the pre-plugin is embedded into a web application, and the message sending method of the pre-plugin is registered in the native application processing end; the pre-plugin is initialized, wherein the initialized pre-plugin processes requests according to predetermined logic.

[0348] Figure 24 is a schematic diagram of the structure of the apparatus 2600 for loading web application content through a native application according to an embodiment of this disclosure. This apparatus for loading web application content through a native application is applied to a native application processing end, and the apparatus 2600 includes:

[0349] The first receiving unit 2610 is configured to receive and store the request parameters and the first request identifier code sent by the pre-plugin, wherein the request parameters are obtained by the pre-plugin from the first request when it receives the first request, the first request identifier code is generated by the pre-plugin for the first request, and the first request is used to characterize the native application request to load the web application content.

[0350] The second receiving unit 2620 is configured to receive a second request sent by the front-end plug-in, the second request including a first request and a first request identifier code;

[0351] The lookup unit 2630 is configured to look up the request parameters stored in association with the first request identifier code based on the first request identifier code in the second request;

[0352] The processing unit 2640 is configured to parse the first request in the second request, obtain the parsing result, assemble the parsing result and the found request parameters to obtain a page loading request, and send the page loading request to the web application server.

[0353] In some embodiments, the processing unit 2640 is configured to: determine a target domain name resolution service among a plurality of candidate domain name resolution services based on predetermined loading conditions; and perform domain name resolution on the first request in the second request based on the target domain name resolution service to obtain the resolution result, wherein the resolution result is used to indicate the Internet Protocol address of the web application server that provides the web application content.

[0354] In some embodiments, the processing unit 2640 is configured to: perform object verification on the target object that initiated the first request; and when the object verification is successful, assemble the page loading request based on the parsing result and the found request parameters.

[0355] In some embodiments, object verification of the target object that initiates the first request includes: determining the terminal address of the target object; comparing the terminal address with candidate addresses of authorized objects that initiate the first request; determining that the object verification passes when one of the candidate addresses matches the terminal address; and determining that the object verification fails when no candidate address matches the terminal address.

[0356] In some embodiments, the processing unit 2640 is configured to: perform de-encoding processing on the request parameters to obtain the request body parameters of the first request; fill the request body parameters into a predetermined code template to obtain a target code segment; and assemble the target code segment and the Internet Protocol address in the parsing result to obtain the page loading request.

[0357] In some embodiments, the apparatus 2600 for loading web application content via native application further includes a resource processing unit (not shown), which is configured to: receive a target resource provided by a web application server according to a page loading request; and load the web application content based on the target resource.

[0358] In some embodiments, the web application server provides the target resource in the following manner:

[0359] A verification module (not shown) is configured to perform the first verification on the page load request;

[0360] The determination module (not shown) is configured to determine the target resource for loading the web application content from multiple candidate resources based on the page loading request when the first verification passes.

[0361] The feedback module (not shown) is configured to provide the target resource based on the response to the page load request.

[0362] In some embodiments, the verification module (not shown) includes:

[0363] The Determine Submodule (not shown) is configured to determine the initiating object, request timestamp, and request content of the page load request;

[0364] The first verification submodule (not shown) is configured to perform the first sub-verification on the page loading request based on the initiating object and the request timestamp;

[0365] The second verification submodule (not shown) is configured to perform a second sub-verification on the page loading request based on the request content of the page loading request.

[0366] In some embodiments, the first verification submodule (not shown) is configured to: perform object verification on the page loading request based on the comparison between the initiating object and each authorized initiating object in the preset address mapping table; when the object verification passes, perform time validity verification on the page loading request based on the time difference between the request timestamp and the current time.

[0367] In some embodiments, the second verification submodule (not shown) is configured to: obtain the object public key of the initiating object that initiated the page loading request; design the request content based on the object public key to obtain the designing result; and perform a second sub-verification on the page loading request based on the designing result and the comparison with the request content of the first request.

[0368] Referring to Figure 25, which is a partial structural block diagram of a terminal implementing the method of loading web application content through a native application according to an embodiment of the present disclosure, the terminal includes: a radio frequency (RF) circuit 2710, a memory 2715, an input unit 2730, a display unit 2740, a sensor 2750, an audio circuit 2760, a wireless fidelity (WiFi) module 2770, a processor 2780, and a power supply 2790, etc. Those skilled in the art will understand that the terminal structure shown in Figure 25 does not constitute a limitation on a mobile phone or computer, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0369] The RF circuit 2710 can be used to receive and transmit signals during information transmission or calls. In particular, it receives downlink information from the base station and processes it with the processor 2780; in addition, it transmits uplink data to the base station.

[0370] The memory 2715 can be used to store software programs and modules, and the processor 2780 executes various functional applications and data processing of the target terminal by running the software programs and modules stored in the memory 2715.

[0371] The input unit 2730 can be used to receive input numeric or character information, and to generate key signal inputs related to the settings and function control of the target terminal. Specifically, the input unit 2730 may include a touch panel 2731 and other input devices 2732.

[0372] Display unit 2740 can be used to display input or provided information, as well as various menus of the target terminal. Display unit 2740 may include display panel 2741.

[0373] Audio circuitry 2760, speaker 2761, and microphone 2762 provide an audio interface.

[0374] In this embodiment, the processor 2780 included in the terminal can execute the method of loading web application content through native application in the previous embodiment.

[0375] The terminals disclosed in this embodiment include, but are not limited to, mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle terminals, and aircraft. The embodiments of this invention can be applied to various scenarios, including but not limited to data security, blockchain, data storage, and information technology.

[0376] Figure 26 is a partial structural block diagram of a server implementing the method of loading web application content through a native application according to an embodiment of the present disclosure. The server can vary considerably due to different configurations or performance, and may include one or more central processing units (CPUs) 2822 (e.g., one or more processors) and memory 2832, and one or more storage media 2830 (e.g., one or more mass storage devices) for storing application programs 2842 or data 2844. The memory 2832 and storage media 2830 may be temporary or persistent storage. The program stored in the storage media 2830 may include one or more modules (not shown in the figure), each module including a series of instruction operations on the server. Furthermore, the CPU 2822 may be configured to communicate with the storage media 2830 and execute the series of instruction operations in the storage media 2830 on the server.

[0377] The server may also include one or more power supplies 2826, one or more wired or wireless network interfaces 2850, one or more input / output interfaces 2858, and / or one or more operating systems 2841, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0378] The central processing unit 2822 in the server can be used to execute the method of loading web application content through native application according to the embodiments of this disclosure.

[0379] This disclosure also provides a computer-readable storage medium for storing program code for executing the methods of loading web application content through native applications in the foregoing embodiments.

[0380] This disclosure also provides a computer program product comprising a computer program. A processor of a computer device reads and executes the computer program, causing the computer device to perform the method described above for loading web application content via a native application.

[0381] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in this disclosure and the foregoing drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of this disclosure described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “including,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatuses.

[0382] It should be understood that in this disclosure, "at least one item" means one or more, and "more than one" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0383] It should be understood that in the description of the embodiments disclosed herein, "multiple" means two or more, "greater than", "less than", "exceeding" etc. are understood to exclude the number itself, and "above", "below", "within" etc. are understood to include the number itself.

[0384] In the several embodiments provided in this disclosure, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0385] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0386] Furthermore, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0387] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0388] It should also be understood that the various implementation methods provided in this disclosure can be combined arbitrarily to achieve different technical effects.

[0389] The above is a detailed description of the embodiments of this disclosure. However, this disclosure is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this disclosure. All such equivalent modifications or substitutions are included within the scope defined by the claims of this disclosure.

Claims

1. A method for loading web application content through a native application, applied to a pre-plugin set up for the native application processing end, the method comprising: Intercept the first request sent to the native application processing end, the first request being used to indicate that the native application requests to load the web application content; Obtain the request parameters of the first request, generate a first request identifier code to identify the first request, and send the request parameters and the first request identifier code to the native application processing terminal for associated storage; Add the first request identifier code to the first request to obtain the second request; Send the second request to the native application processing terminal; The second request is used by the native application processing terminal to perform the following processing: Based on the first request identifier in the second request, the request parameters associated with the first request identifier are located, the first request in the second request is parsed to obtain the parsing result, the parsing result and the found request parameters are assembled to obtain the page loading request, and the page loading request is sent to the web application server.

2. The method according to claim 1, wherein, The step of obtaining the request parameters of the first request includes: Extract the request body parameters of the first request and encode the request body parameters to obtain the request parameters.

3. The method according to claim 2, wherein, The process of encoding the request body parameters to obtain the request parameters includes: Based on the request type of the first request, the target encoding method is determined from multiple candidate encoding methods; Based on the target encoding method, the request body parameters are encoded to obtain the request parameters.

4. The method according to any one of claims 1-3, wherein, The generation of a first request identifier code for identifying the first request includes: Based on the request type of the first request and the preset identifier generation method, a first request identifier code is generated to identify the first request.

5. The method according to any one of claims 1-4, wherein, The step of adding the first request identifier code to the first request to obtain the second request includes: When the request parameters have been stored in the native application processing end, the target splicing method is selected from multiple candidate splicing methods based on the request type of the first request. The second request is created based on the first request and the first request identifier using the target splicing method.

6. The method according to claim 5, wherein, The method further includes: Receive message data sent by the native application processing terminal; When the message data contains a target field, it is determined that the request parameters have been stored on the native application processing end.

7. The method according to any one of claims 1-6, wherein, The pre-installation plugin is deployed in the following manner: The pre-plugin is embedded into the web application, and the message sending method of the pre-plugin is registered on the native application processing end. The pre-plugin is initialized, and the initialized pre-plugin processes requests according to predetermined logic.

8. A method for loading web application content through a native application, applied to a native application processing end, wherein a pre-plugin is set for the native application processing end, the method comprising: The system receives and stores the request parameters and first request identifier code sent by the pre-plugin, wherein the request parameters are obtained by the pre-plugin from the first request when it receives the first request, and the first request identifier code is generated by the pre-plugin for the first request. The first request is used to characterize the native application requesting to load the web application content. Receive a second request sent by the pre-plugin, the second request including the first request and the first request identifier; Based on the first request identifier in the second request, locate the request parameters stored in association with the first request identifier; The first request in the second request is parsed to obtain the parsing result. The parsing result and the found request parameters are assembled to obtain the page loading request, and the page loading request is sent to the web application server.

9. The method according to claim 8, wherein, The step of parsing the first request in the second request to obtain the parsing result includes: Based on predetermined loading conditions, the target domain name resolution service is determined from multiple candidate domain name resolution services; Based on the target domain name resolution service, the first request in the second request is resolved to obtain the resolution result, wherein the resolution result is used to indicate the Internet Protocol address of the web application server that provides the web application content.

10. The method according to any one of claims 8-9, wherein, The step of assembling the parsing result and the found request parameters to obtain the page loading request includes: Perform object verification on the target object that initiated the first request; When the object verification passes, the page loading request is assembled based on the parsing result and the found request parameters.

11. The method according to claim 10, wherein, The object verification of the target object that initiated the first request includes: Determine the terminal address of the target object; The terminal address is compared with the candidate addresses of the authorized initiating objects for the first request; When a candidate address matches the terminal address, the object verification is deemed successful. If no candidate address matches the terminal address, the object verification is deemed unsuccessful.

12. The method according to any one of claims 8-11, wherein, The step of assembling the parsing result and the found request parameters to obtain the page loading request includes: The request parameters are de-encoded to obtain the request body parameters of the first request; The request body parameters are filled into a predetermined code template to obtain the target code segment; The target code segment and the Internet Protocol address in the parsing result are assembled to obtain the page loading request.

13. The method according to any one of claims 8-12, wherein, After sending the page load request to the web application server, the method further includes: Receive the target resource provided by the web application server based on the page loading request; The web application content is loaded based on the target resource.

14. An apparatus for loading web application content via a native application, applied to a pre-plugin configured for a native application processor, the apparatus comprising: The interception unit is configured to intercept a first request sent to the native application processing end, wherein the first request is used to indicate that the native application requests to load the web application content; The acquisition unit is configured to acquire the request parameters of the first request, generate a first request identifier code to identify the first request, and send the request parameters and the first request identifier code to the native application processing terminal for associated storage. The generation unit is configured to add the first request identifier code to the first request to obtain the second request; The sending unit is configured to send the second request to the native application processing terminal; wherein the second request is used by the native application processing terminal to perform the following processing: Based on the first request identifier in the second request, the request parameters associated with the first request identifier are located, the first request in the second request is parsed to obtain the parsing result, the parsing result and the found request parameters are assembled to obtain the page loading request, and the page loading request is sent to the web application server.

15. An apparatus for loading web application content via a native application, applied to a native application processing end, wherein a pre-plugin is provided for the native application processing end, the apparatus comprising: The first receiving unit is configured to receive and store the request parameters and the first request identifier code sent by the pre-plugin, wherein the request parameters are obtained by the pre-plugin from the first request when it receives the first request, the first request identifier code is generated by the pre-plugin for the first request, and the first request is used to characterize the native application requesting to load the web application content. The second receiving unit is configured to receive a second request sent by the pre-plugin, wherein the second request includes the first request and the first request identifier code; The lookup unit is configured to look up the request parameters stored in association with the first request identifier code based on the first request identifier code in the second request; The processing unit is configured to parse the first request in the second request, obtain the parsing result, assemble the parsing result and the found request parameters to obtain a page loading request, and send the page loading request to the web application server.

16. An electronic device comprising a memory and a processor, the memory storing a computer program, wherein the processor, when executing the computer program, implements the method for loading web application content via a native application as described in any one of claims 1 to 7, or the method for loading web application content via a native application as described in any one of claims 8 to 13.

17. A computer-readable storage medium storing a computer program that, when executed by a processor, implements the method for loading web application content via a native application as described in any one of claims 1 to 7, or the method for loading web application content via a native application as described in any one of claims 8 to 13.

18. A computer program product comprising a computer program that is read and executed by a processor of a computer device, causing the computer device to perform the method of loading web application content through a native application as described in any one of claims 1 to 7, or the method of loading web application content through a native application as described in any one of claims 8 to 13.

Images