Method for loading web application content by native application, related device and medium

Abstract

The present disclosure provides a method for loading web application content through a native application, related devices and media. The pre-inserted plug-in applied to the native application processing end includes: intercepting a first request; obtaining the request parameters of the first request, generating a first request identification code, and sending the request parameters and the first request identification code to the corresponding storage of the native application processing end; adding the first request identification code to the first request to generate a second request; sending the second request to the native application processing end, so that the native application processing end finds the corresponding storage request parameters based on the added first request identification code, parses the first request to obtain a parsing result, assembles the parsing result and the request parameters to obtain a page loading request, and sends the page loading request to a web application server. The present disclosure can reduce the loading failure when loading web application content through a native application. The present disclosure can be applied to various scenes such as big data, page display, cloud technology, etc.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of page display, and in particular, to a method for loading web application content through a native application, related devices and media. BACKGROUND

[0002] Currently, in a common web application, a content on a server is accessed according to a domain name address. The domain name address has the characteristic of being susceptible to domain name hijacking, but an IP address does not. Due to the existence of domain name hijacking, page loading failure often occurs.

[0003] In a hybrid development mode based on a web application and a native application (Native APP), the above problem can be solved. Specifically, in a hybrid application, a web application content (such as a video website application) can be loaded through a native application (such as a commonly used chat application). In the hybrid application, a business request for loading the web application content through the native application is intercepted at a native application processing end, and the domain name address of the business request is replaced with an IP address by the native application processing end through a domain name resolution service. At this time, the domain name hijacking is not susceptible to occur. At this time, an access request is sent to a server, and resources returned by the server are rendered into an H5 page through the web application, so that the risk of domain name hijacking is reduced.

[0004] However, in the above manner, the request parameters (such as a request to display a certain type of picture, text information, and the like) in the business request cannot be parsed by the native application (the corresponding protocol format is not supported) after the native application processing end receives the business request. These request parameters cannot be transmitted to the native application processing end, which will cause the final loading display to fail due to the lack of request parameters. SUMMARY

[0005] The present disclosure provides a method for loading web application content through a native application, related devices and media, which can reduce loading failure when loading web application content through a native application.

[0006] According to an aspect of the present disclosure, a method for loading web application content through a native application is provided, which is applied to a front plug-in before a native application processing end. The method comprises:

[0007] intercepting a first request, the first request being used to load the web application content through the native application;

[0008] obtaining request parameters of the first request from the first request, generating a first request identification code used to identify the first request, and sending the request parameters and the first request identification code to the native application processing end for storage;

[0009] increase the first request identification code on the basis of the first request to generate a second request;

[0010] send the second request to the native application processing end, so that the native application processing end finds the request parameter stored corresponding to the first request identification code based on the increased first request identification code, parses the first request to obtain a parsing result, assembles the parsing result and the request parameter to obtain a page loading request, and sends the page loading request to a web application server.

[0011] According to an aspect of the present disclosure, a method for loading web application content through a native application is provided, which is applied to a native application processing end and has a front plug-in before the native application processing end. The method comprises:

[0012] receiving and storing request parameters and a first request identification code sent by the front plug-in, wherein the request parameters are obtained by the front plug-in from a first request when the first request is received, and the first request identification code is generated by the front plug-in for the first request, and the first request is used to load the web application content through the native application;

[0013] receiving a second request sent by the front plug-in, the second request comprising the first request and the first request identification code;

[0014] finding the request parameter stored corresponding to the first request identification code based on the first request identification code in the second request;

[0015] parsing the first request to obtain a parsing result, assembling the parsing result and the request parameter to obtain a page loading request, and sending the page loading request to a web application server.

[0016] According to an aspect of the present disclosure, a device for loading web application content through a native application is provided, which is applied to a front plug-in before a native application processing end. The device comprises:

[0017] an intercepting unit configured to intercept a first request, the first request being used to load the web application content through the native application;

[0018] an obtaining unit configured to obtain request parameters of the first request from the first request, generate a first request identification code used to identify the first request, and send the request parameters and the first request identification code to the native application processing end for corresponding storage;

[0019] a generating unit configured to increase the first request identification code on the basis of the first request to generate a second request;

[0020] a sending unit, configured to send the second request to the native application processing end, so that the native application processing end finds the request parameter stored corresponding to the first request identification code based on the increased first request identification code, parses the first request to obtain a parsing result, assembles the parsing result and the request parameter to obtain a page loading request, and sends the page loading request to a web application server.

[0021] Optionally, the obtaining unit comprises:

[0022] an encoding module, configured to extract a request body parameter of the first request, and encode the request body parameter to obtain the request parameter.

[0023] a generating module, configured to generate the first request identification code of the first request based on a request type of the first request and a preset identification code generation rule.

[0024] Optionally, the encoding module is configured to:

[0025] determine a target encoding rule from a plurality of candidate encoding rules based on the request type of the first request.

[0026] encode the request body parameter based on the target encoding rule to obtain the request parameter.

[0027] Optionally, the second request is generated in the following manner:

[0028] if it is determined that the request parameter has been completely stored in the native application processing end, then a target splicing rule is selected from a plurality of candidate splicing rules based on the request type of the first request.

[0029] the second request is created based on the first request and the first request identification code by using the target splicing rule.

[0030] Optionally, the determination that the request parameter has been completely stored in the native application processing end comprises:

[0031] receiving message data sent by a target function of the native application processing end;

[0032] if it is determined that the message data contains a target field, then it is determined that the request parameter has been completely stored in the native application processing end.

[0033] Optionally, the front plug-in is deployed in the following manner:

[0034] 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.

[0035] The pre-plugin is initialized so that it processes requests according to a predetermined logic.

[0036] According to one aspect of this disclosure, an apparatus for loading web application content through a native application is provided, applied to a native application processing end, wherein the native application processing end has a pre-plugin, the apparatus comprising:

[0037] The first receiving unit is used to receive and store the request parameters and the first request identifier code sent by the pre-plugin. 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. The first request is used to load the web application content through the native application.

[0038] 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;

[0039] The lookup unit is used to look up the request parameters stored corresponding to the first request identifier code in the second request;

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

[0041] Optionally, the processing unit is used for:

[0042] Based on predetermined loading conditions, the target domain name resolution service is determined from multiple candidate domain name resolution services;

[0043] Based on the target domain name resolution service, the first request is resolved to obtain the resolution result, wherein the resolution result is used to indicate the IP address of the web application server that provides the web application content.

[0044] Optionally, the processing unit is used for:

[0045] Perform object verification on the target object that initiated the first request;

[0046] If the object verification is successful, the page loading request is assembled based on the parsing result and the request parameters.

[0047] Optionally, the object verification on the target object initiating the first request comprises:

[0048] determining an object terminal address of the target object;

[0049] comparing the object terminal address with candidate object addresses of objects having authority to initiate the first request;

[0050] if there is one of the candidate object addresses consistent with the object terminal, determining that the object verification is passed.

[0051] Optionally, the processing unit is configured to:

[0052] performing reverse coding processing on the request parameter to obtain a request body parameter of the first request;

[0053] filling the request body parameter into a predetermined code template to obtain a target code segment;

[0054] assembling the target code segment and an IP address in the resolution result to obtain the page loading request.

[0055] Optionally, the apparatus for loading web application content through a native application further comprises a resource processing unit, and the resource processing unit is configured to:

[0056] receiving a target resource provided by the web application server according to the page loading request;

[0057] loading the web application content based on the target resource.

[0058] Optionally, the web application server provides the target resource according to the following manner:

[0059] a verification module configured to perform first verification on the page loading request;

[0060] a determination module configured to, if the first verification is passed, determine a target resource for loading the web application content from a plurality of candidate resources based on the page loading request;

[0061] a feedback module configured to provide the target resource based on a response to the page loading request.

[0062] Optionally, the verification module comprises:

[0063] a determination sub-module configured to determine an initiating object, a request timestamp, and a request content of the page loading request;

[0064] a first verification sub-module configured to perform first sub-verification on the page loading request based on the initiating object and the request timestamp.

[0065] a second verification submodule, configured to perform a second sub-verification on the page loading request based on the request content of the page loading request.

[0066] Optionally, the first verification submodule is configured to:

[0067] perform object verification on the page loading request based on a comparison between the initiating object and each authorized initiating object in a preset address mapping table;

[0068] if the object verification is passed, perform time validity verification on the page loading request based on a time difference between the request timestamp and a current time.

[0069] Optionally, the second verification submodule is configured to:

[0070] obtain an object public key of an initiating object initiating the page loading request;

[0071] perform un-signing on the request content based on the object public key to obtain an un-signing result;

[0072] perform the second sub-verification on the page loading request based on a comparison between the un-signing result and the request content of the first request.

[0073] According to an aspect of the present disclosure, an electronic device is provided, which includes a memory and a processor, the memory stores a computer program, and the processor implements the method for loading web application content through a native application as described above when executing the computer program.

[0074] According to an aspect of the present disclosure, a computer readable storage medium is provided, which stores a computer program, and the computer program is executed by a processor to implement the method for loading web application content through a native application as described above.

[0075] According to an aspect of the present disclosure, a computer program product is provided, which includes a computer program, the computer program is read and executed by a processor of a computer device, so that the computer device performs the method for loading web application content through a native application as described above.

[0076] In the embodiments of the present disclosure, since the native application processing end cannot parse the request parameters in the service request after receiving the service request, a front plug-in is arranged in front of the native application processing end. After receiving the first request for loading the web application content through the native application, the front plug-in intercepts the first request, obtains the request parameters of the first request, generates a first request identification code for identifying the target request, and sends the request parameters and the first request identification code to the corresponding storage of the native application processing end. Since the front plug-in can identify the format of the first request and obtain the request parameters, and the transmission between the front plug-in and the native application processing end is ordinary transmission and is not limited by the protocol, the native application processing end can receive the request parameters and store the first request identification code correspondingly. When the front plug-in forwards the first request to the native application processing end, the first request identification code is correspondingly forwarded. In this way, the native application processing end can find the corresponding stored request parameters according to the first request identification code, and integrate the request parameters and the parsing result of the first request into a page loading request. Compared with the page loading request sent to the web application server in the prior art, the page loading request at this time contains the request parameters in addition to the parsing result, so that the final loading and display will not fail due to the lack of request parameters.

[0077] Other features and advantages of the present disclosure will be set forth in the following description, and in part will become apparent from the description, or can be learned by practice of the present disclosure. The objects and other advantages of the present disclosure can be achieved and obtained by the structures specifically pointed out in the description, claims and drawings. BRIEF DESCRIPTION OF DRAWINGS

[0078] The accompanying drawings are intended to provide a further understanding of the technical solutions of the present disclosure and constitute a part of the specification, and are used together with the embodiments of the present disclosure to explain the technical solutions of the present disclosure, and do not constitute a limitation on the technical solutions of the present disclosure.

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

[0080] FIG. 2A shows a schematic diagram of a method for loading web application content through a native application in a page loading scene according to the related art;

[0081] FIG. 2B shows a schematic diagram of a method for loading web application content through a native application in a page loading scene according to an embodiment of the present disclosure;

[0082] FIG. 3 is a flowchart of a method for loading web application content through a native application executed by a front plug-in according to an embodiment of the present disclosure;

[0083] FIG. 4 is a flowchart of acquiring request parameters of a first request and generating a first request identification code according to one embodiment of the present disclosure;

[0084] FIG. 5 is a simple schematic diagram of a predetermined database storing request parameters and a first request identification code according to one embodiment of the present disclosure;

[0085] FIG. 6 is a flowchart of encoding request body parameters according to one embodiment of the present disclosure;

[0086] FIG. 7 is a schematic diagram of an implementation process of encoding request body parameters according to one embodiment of the present disclosure;

[0087] FIG. 8 is a flowchart of generating a second request according to one embodiment of the present disclosure;

[0088] FIG. 9 is a flowchart of determining that request parameters have been stored at a native application processing end according to one embodiment of the present disclosure;

[0089] FIG. 10 is a flowchart of deploying a front-end plug-in according to one embodiment of the present disclosure;

[0090] FIG. 11 is a whole execution flowchart of a front-end plug-in according to one embodiment of the present disclosure;

[0091] FIG. 12 is a flowchart of a method of loading web application content through a native application executed by a native application processing end according to one embodiment of the present disclosure;

[0092] FIG. 13 is a flowchart of parsing a first request according to one embodiment of the present disclosure;

[0093] FIG. 14 is a flowchart of assembling a page loading request according to another embodiment of the present disclosure;

[0094] FIG. 15 is a flowchart of object verification according to one embodiment of the present disclosure;

[0095] FIG. 16 is a simple schematic diagram of a list of objects with authority to initiate according to one embodiment of the present disclosure;

[0096] FIG. 17 is a specific flowchart of assembling a page loading request according to one embodiment of the present disclosure;

[0097] FIG. 18is a flowchart of loading web application content according to one embodiment of the present disclosure;

[0098] FIG. 19 is a flowchart of a web application server providing a target resource according to one embodiment of the present disclosure;

[0099] FIG. 20 is a flowchart of first verification according to one embodiment of the present disclosure;

[0100] FIG. 21 is a flowchart of first sub-verification according to one embodiment of the present disclosure;

[0101] FIG. 22 is a flowchart of second sub-verification according to one embodiment of the present disclosure;

[0102] FIG. 23 is an embodiment details diagram of a method of loading web application content through a native application according to one embodiment of the present disclosure;

[0103] FIG. 24A-FIG. 24B is an experimental time comparison diagram between an embodiment of the present disclosure and a prior art method of loading web application content through a native application;

[0104] FIG. 25 is a module diagram of an apparatus for loading web application content through a native application according to one embodiment of the present disclosure;

[0105] FIG. 26 is a module diagram of an apparatus for loading web application content through a native application according to another embodiment of the present disclosure;

[0106] FIG. 27 is a terminal structure diagram of a method of loading web application content through a native application according to one embodiment of the present disclosure;

[0107] FIG. 28 is a server structure diagram of a method of loading web application content through a native application according to one embodiment of the present disclosure. DETAILED DESCRIPTION

[0108] In order to make the objectives, technical solutions and advantages of the present disclosure clearer, the present disclosure will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present disclosure and do not limit the present disclosure.

[0109] The related data collection and processing in the embodiments of the present application should strictly obtain the informed consent or separate consent of the personal information subject according to the requirements of relevant laws and regulations, and carry out subsequent data use and processing within the scope of authorization of laws and regulations and the personal information subject.

[0110] Before the embodiments of the present disclosure are further described in detail, terms and names involved in the embodiments of the present disclosure are explained, and the terms and names involved in the embodiments of the present disclosure are applicable to the following explanations:

[0111] Artificial Intelligence (AI) is the use of digital computers or machines controlled by digital computers to simulate, extend and expand human intelligence, perceive the environment, acquire knowledge and use the knowledge to obtain the best results. In other words, artificial intelligence is a comprehensive technology of computer science, which attempts to understand the essence of intelligence and produce a new intelligent machine that can react in a similar way to human intelligence. Artificial intelligence is the design principle and implementation method of various intelligent machines, so that the machine has the functions of perception, reasoning and decision-making. Artificial intelligence technology is a comprehensive discipline, involving a wide range of fields, both hardware and software technologies. Artificial intelligence basic technologies generally include sensors, special artificial intelligence chips, cloud computing, distributed storage, big data processing technology, pre-training model technology, operation / interaction system, mechatronics, etc. Among them, the pre-training model is also called large model, basic model, which can be widely applied to downstream tasks in various directions of artificial intelligence after fine-tuning. Artificial intelligence software technology mainly includes computer vision technology, speech processing technology, natural language processing technology, and machine learning / deep learning, etc. With the research and progress of artificial intelligence technology, artificial intelligence technology is researched and applied in many fields, such as common smart home, smart wearable devices, virtual assistants, smart speakers, smart marketing, unmanned vehicles, autonomous vehicles, drones, robots, smart medical care, smart customer service, etc. It is believed that with the development of technology, artificial intelligence technology will be applied in more fields and play an increasingly important role.

[0112] Domain name hijacking: Domain name hijacking is a way of Internet attack, by attacking the domain name resolution server (DNS), or by forging the domain name resolution server (DNS) method, resolving the target website domain name to the wrong IP address, so as to achieve the purpose that users cannot access the target website or deliberately or maliciously require users to access the specified IP address (website).

[0113] HTTPDNS refers to a DNS server cluster based on HTTP protocol, which is a domain name resolution service for multi-end applications (mobile APP, PC client application), with the characteristics of domain name anti-hijacking, precise scheduling, real-time resolution and effectiveness. It is usually suitable for mobile application software (APP), to prevent malicious hijacking or for applications with high requirements for access speed.

[0114] Hybrid Application (Hybrid App): is a software application that combines elements of both native applications and web applications. A hybrid app is essentially a web app with a native app shell. Once the user downloads the app and installs it locally, the shell connects to any functionality provided by the mobile platform through a browser embedded in the app. The browser and its plugins run in the background and are invisible to the end user.

[0115] Native App refers to the native program, generally rely on the operating system, strong interaction, is a complete App, scalability, need to download and install the user. In short, the native application is developed for a certain operating system, such as iOS, Android, etc., they are running on the mobile device). The mode is usually composed of "cloud server data + APP application client" two parts, APP application all UI elements, data content, logic framework are installed on the mobile terminal. In addition, the native application is different from the web application, Web application is a web application that needs to run in the browser, while the native application can directly call the device interface (Device API) of the mobile operating system.

[0116] System architecture and scenario description to which embodiments of the present disclosure apply

[0117] FIG. 1 is a system architecture diagram applied by the method of loading web application content through native application according to the embodiments of the present disclosure. It includes object terminal 140, Internet 130, gateway 120, native application server 110, web application server 160, and database 150, etc.

[0118] The object terminal 140 includes desktop computers, laptops, PDAs (personal digital assistants), mobile phones, car terminals, home theater terminals, special terminals, and various forms. In addition, it can be a single device, or a collection of multiple devices. The object terminal 140 can communicate with the Internet 130 in a wired or wireless manner to exchange data. Among them, the object terminal 140 has a hybrid APP composed of a web application containing a pre-inserted plug-in and a native application, and the hybrid APP can realize the loading of web application content in the native application.

[0119] The native application server 110 and the web application server 160 refer to computer systems capable of providing certain services to the object terminal 140. Compared with the ordinary object terminal 140, the native application server 110 and the web application server 160 have higher requirements in stability, security, performance, and the like. The native application server 110 and the web application server 160 can be a high-performance computer in a network platform, a cluster of multiple high-performance computers, a portion (for example, a virtual machine) of a high-performance computer, a combination of portions (for example, virtual machines) of multiple high-performance computers, or the like. The native application server 110 and the web application server 160 include multiple types of services, and the implementation of each service of the native application server 110 and the web application server 160 is often associated with some intermediate databases or storage media, and the like. The native application server 110 is configured to respond to a service request sent by a target object on a web application of a hybrid APP, receive request parameters and the like sent by a front plug-in, and initiate an IP direct connection request to the web application server according to the service request and the request parameters, so as to load web application content on the hybrid APP of the object terminal. The database 150 is configured to store request parameters and the like obtained from the front plug-in.

[0120] The gateway 120 is also referred to as an inter-network connector or a protocol converter. The gateway implements network interconnection at the transport layer and is a computer system or device acting as a conversion function. The gateway is a translator between two systems using different communication protocols, data formats or languages, or even having completely different architectures. Meanwhile, the gateway can also provide filtering and security functions. The messages sent by the object terminal 140 to the native application server 110 and the web application server 160 are sent to the corresponding native application server 110 and the web application server 160 through the gateway 120. The messages sent by the native application server 110 and the web application server 160 to the object terminal 140 are also sent to the corresponding object terminal 140 through the gateway 120.

[0121] As shown in FIG. 1, the native application server 110 and the web application server 160 are connected to the gateway 120, and the gateway 120 is connected to the object terminal 140. The native application server 110 and the web application server 160 are connected to the database 150. FIG. 2A As shown in FIG. 2, it is a specific schematic diagram of related technologies for loading web application content in a page loading scenario. Specifically, when a request (POST request) with data is initiated to the server in the ordinary web application (web application / web browser), the domain name address in the request is “https: / / www.xxx.com”, and the request parameter is “body: a=1&b=1”. At this time, the request is likely to be hijacked, and the domain name address is often replaced by other domain name addresses, so that the network resources provided by the web application server are not the required network resources, and the required web application content cannot be displayed on the browser.

[0122] Based on this, in order to reduce the risk of domain hijacking, the related technology further proposes another implementation. When a web application (web application / webview) in a hybrid application initiates a request (POST request) with data to a server, the domain name address in the request is "https: / / www.xxx.com", and the request parameter is "body: a=1&b=1". At this time, the hybrid application can access the domain name resolution service to convert the domain name address in the initiated request into an IP address "https: / / 1.2.3.4", so that the original request is changed into the form of IP address+request parameter, which can reduce the risk of domain hijacking. However, the request parameter "body: a=1&b=1" in the POST request cannot be verified by the certificate, and the request parameter cannot be parsed to be sent to the web application server, so the web application server does not know what the specific request parameter is, and therefore cannot load the required web application content.

[0123] The embodiments of the present disclosure can be applied in various scenarios, for example FIG. 2B The page loading scenario shown in the figure, etc.

[0124] For example FIG. 2BAs shown, it is a specific schematic diagram of loading web application content in the page loading scenario according to the embodiment of the present disclosure. A front plug-in (JSBridge) is set between the web application and the native application of the hybrid application as a bridge for data transmission. Specifically, when the web application in the hybrid application requests to load web application content from the web application server, first, when a request (POST request) with data is initiated from the web application (web application / webview) in the hybrid application to the server, the domain name address in the request is "https: / / www.xxx.com", and the request parameter is "body: a=1&b=1". At this time, the front plug-in (JSBridge) in the hybrid application intercepts the POST request, generates a unique identification code AA124 of the POST request and acquires the request parameter, and sends the request parameter and the unique identification code to the native application. Then, the native application saves the correspondence between the identification code and the request parameter (a=1&b=1, AA124), and informs the front plug-in that the storage of the identification code and the request parameter is completed, and the request can continue to be sent. Further, the POST request with the identification code (httpsdns: / / www.xxx.com?identifier=AA124) is continuously sent to the native application. Then, the native application uses HTTPDNS to parse the request, resolves the domain name address "https: / / www.xxx.com" into an IP address "https: / / 1.2.3.4", acquires the request parameter by searching for the identification code of the intercepted POST request with the identification code, and assembles a new request, wherein the new request has the IP address "https: / / 1.2.3.4" and the request parameter "body: a=1&b=1", and sends the new request to the web application server. Based on this, the web application server returns the request data through the native application, and loads the web application content through the web application.

[0125] Compared with the prior art, the embodiment of the present disclosure can effectively prevent domain name hijacking, and can also successfully send the request parameter in the request to the native application and the web application server, thereby improving the content loading success rate.

[0126] General description of embodiments of the present disclosure

[0127] According to one embodiment of the present disclosure, a method for loading web application content by a native application is provided.

[0128] The method for loading web application content by a native application is generally applied to a business scenario in which the hybrid application program needs to quickly and accurately load content, for example FIG. 2BThe page loading scenario is shown. The embodiment of the present disclosure provides a scheme of setting a front plug-in between a web application and a native application to realize data transmission, which can reduce loading failure when loading web application content through a native application.

[0129] As shown in the figure, the method for loading web application content through a native application according to one embodiment of the present disclosure is applied to a front plug-in before a native application processing end. FIG. 3

[0130] The native application processing end refers to the server processing part of the native application.

[0131] The front plug-in refers to a functional plug-in in a hybrid application that plays a bridge role between a native application and a web application. The front plug-in can realize message transmission between the native application and the web application.

[0132] In the embodiment of the present disclosure, the front plug-in can be a JavaScript SDK (JSSDK) interface, and the JSSDK is a set of API interfaces. The JSSDK can use the JSBridge principle (JSBridge is a technology that allows JavaScript code and native applications to interact) to establish a communication bridge between a web application running in a webview and a native application, and realize bidirectional communication between the web application and the native application.

[0133] Specifically, the method for loading web application content through a native application can include:

[0134] Step 310, intercepting a first request;

[0135] Step 320, obtaining request parameters of the first request from the first request, generating a first request identification code for identifying the first request, and sending the request parameters and the first request identification code to the native application processing end corresponding storage;

[0136] Step 330, adding the first request identification code on the basis of the first request to generate a second request;

[0137] Step 340, sending the second request to the native application processing end, so that the native application processing end finds the request parameters stored corresponding to the first request identification code based on the added first request identification code, parses the first request to obtain a parsing result, assembles the parsing result and the request parameters to obtain a page loading request, and sends the page loading request to a web application server.

[0138] The steps 310-340 are described in detail below.

[0139] In step 310, the first request is intercepted.

[0140] ​The first request is used to load the web application content through the native application.

[0141] The first request usually includes a domain name address of a web application server where a resource corresponding to the web application content to be loaded is located, and a request parameter used to identify the resource corresponding to the web application content to be loaded.

[0142] In the embodiment, when the web application content is to be loaded through the native application, the target object first initiates the first request to the native application through the web application of the hybrid application, so as to obtain the resource for loading the web application content from the web application server through the native application. At this time, the front plug-in intercepts the first request, so that the first request is not temporarily sent to the native application processing end.

[0143] In step 320, the request parameter of the first request is obtained from the first request, a first request identification code used to identify the first request is generated, and the request parameter and the first request identification code are sent to the storage corresponding to the native application processing end.

[0144] The request parameter is used to indicate the parameter in the request body in the first request to be sent to the web application server. The request body refers to the part of the first request in the HTTP protocol used to transmit the data sent by the web end to the web application server. The request parameter can also be referred to as the body parameter.

[0145] The first request identification code is used to identify the first request, so as to distinguish the first request from other requests. The first request identification code of the first request has uniqueness.

[0146] In the embodiment, first, the request content of the first request is parsed, the parameter of the request body part in the first request is obtained, and the request parameter is obtained. Then, a unique identification code is generated for the first request by using a random number algorithm or other algorithm, as the first request identification code of the first request. Further, the mapping relationship between the first request identification code and the request parameter is determined, the request parameter and the first request identification code are sent to the native application processing end according to the mapping relationship, the native application processing end stores the request parameter and the first request identification code according to the mapping relationship, so as to ensure that one first request identification code uniquely corresponds to one request parameter.

[0147] In step 330, the first request identification code is added to the first request to generate a second request.

[0148] The second request is a url request spliced based on the first request and the first request identification code.

[0149] Since the url request often has the characteristics of identifying an address of a resource in the Internet and indicating how to locate the resource, the second request of the embodiment of the present disclosure can locate the specific location of the resource corresponding to the web application content to be loaded and indicate how to locate the resource.

[0150] In the implementation of the embodiment, first, the splicing manner of the first request and the first request identification code is determined. Then, according to the splicing manner, the first request and the first request identification code are spliced by the pre-insert plug-in to obtain the second request.

[0151] It should be noted that, in order to make the second request meet the protocol transmission requirements, the pre-insert plug-in generally does not modify the content and format of the first request when splicing the first request and the first request identification code, but simply appends the first request identification code to the first request.

[0152] In step 340, the second request is sent to the native application processing end, so that the native application processing end, based on the added first request identification code, finds the request parameters stored corresponding to the first request identification code, parses the first request to obtain a parsing result, assembles the parsing result and the request parameters to obtain a page loading request, and sends the page loading request to the web application server.

[0153] The parsing result is used to indicate the IP address of the web application server providing the web application content.

[0154] The page loading request is a request sent by the native application processing end to the web application server for loading the web application content. The page loading request includes the IP address of the web application server (resolved from the domain name address) and the request parameters described above.

[0155] The web application server refers to a server that can provide various service ends for rendering different content resources.

[0156] In the implementation of the embodiment, in order to obtain resources for loading web application content from the web application server, the pre-insert plug-in sends the second request to the native application processing end according to the protocol requirements, so that the native application processing end creates an IP direct connection request (page loading request) with an IP address and request parameters according to the second request, thereby making a resource acquisition request to the web application server in the IP direct connection manner, so that the web application server provides resources according to the request to realize loading of the web application content through the native application.

[0157] To save space, the specific process of the native application processing end to find the request parameters stored corresponding to the first request identification code, the specific process of analyzing the first request, and the specific process of assembling the analysis result and the request parameters into a page loading request and sending it to the web application server will be described in detail when the execution process of the native application processing end is described below. This time, no repetition.

[0158] Through the above steps 310-340, the embodiment of the disclosure, since the native application processing end cannot parse the request parameters in the service request after receiving it, a front-end plug-in is set in front of the native application processing end. After receiving the first request for loading web application content through the native application, the front-end plug-in intercepts it, obtains the request parameters of the first request from it, generates a first request identification code for identifying the target request, and sends the request parameters and the first request identification code to the native application processing end for corresponding storage. Since the front-end plug-in can identify the format of the first request and obtain the request parameters, and it is a normal transmission between the front-end plug-in and the native application processing end, which is not limited by the protocol, the native application processing end can receive the request parameters and store them corresponding to the first request identification code. When the front-end plug-in forwards the first request to the native application processing end, it also forwards the first request identification code corresponding to it. In this way, the native application processing end can find the corresponding stored request parameters according to the first request identification code, and integrate them with the analysis result of the first request to form a page loading request. Compared with the page loading request sent to the web application server in the prior art, which only contains the analysis result, the page loading request at this time contains not only the analysis result but also the request parameters, so that the final loading and display will not fail due to the absence of request parameters.

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

[0160] Detailed description of step 320

[0161] In step 320, the request parameters of the first request are obtained from the first request, a first request identification code for identifying the first request is generated, and the request parameters and the first request identification code are sent to the native application processing end for corresponding storage.

[0162] Please refer to FIG. 4 In one embodiment, the specific process of obtaining the request parameters of the first request and generating the first request identification code for identifying the first request can include but is not limited to the following steps 410-420:

[0163] Step 410, extracting the request body parameters of the first request, and encoding the request body parameters to obtain the request parameters;

[0164] Step 420, generating the first request identification code of the first request based on the request type of the first request and the preset identification code generation rule.

[0165] The steps 410-420 are described in detail as follows.

[0166] In step 410, the request body parameter of the first request is extracted, and the request body parameter is encoded to obtain the request parameter.

[0167] The request body parameter refers to the parameter in the request body of the first request to be sent to the web application server. Common formats of the request body parameter include JSON, XML, form data, etc.

[0168] In the embodiment, first, the parameter loaded in the request body of the first request is extracted to obtain the request body parameter of the first request under the condition of authorized permission. Then, since the data transmission between the web application and the native application can only transmit strings through the front plug-in, the request body parameter is not limited to strings, but can also be image data, form data, etc. Based on this, the request body parameter is encoded to convert the request body parameter into a string form to obtain the request parameter.

[0169] In step 420, the first request identification code of the first request is generated based on the request type of the first request and the preset identification code generation rule.

[0170] The request type is used to indicate the operation to be implemented in the web application by the first request.

[0171] For example, the request type includes but is not limited to: a POST request for creating a new resource, a PUT request for updating the representation of a specified resource on the server or creating a new resource on the server, a DELETE request for deleting a specified resource from the server, and a PATCH request for providing a field or a field value to be updated to update the resource on the server, etc.

[0172] The preset identification code generation rule is used to indicate the specific method and specific process of identification code generation.

[0173] In the embodiment, since the format of the request body parameter is often different under different request types, first, the request type of the first request is determined according to the request body parameter of the first request. Then, according to the request type, the identification code generation rule suitable for this request type is found in the preset identification code generation rule. Finally, the found identification code generation rule generates a unique first request identification code for the first request.

[0174] Specifically, the first request identification code can be in the form of letters + numbers. Different letters correspond to different request types, and the identification code generation rule corresponding to the request type of the first request will specify the letter to be used, and according to the numbers used before the current time according to the form of increasing numbers, set the number used before the current time as 1, as the number to be used by the first request identification code. For example, the first request identification code of a certain first request is AA19.

[0175] In addition, in order to improve the efficiency of identification code generation, the identification code bit number of the first request identification code generated by the first request type can also be constrained by the preset identification code generation rule. Then, a random number that meets the identification code bit number and is unique is generated by using a random number generation algorithm, and the generated random number is used as the first request identification code.

[0176] Further, after obtaining the request parameter and generating the first request identification code, the front plug-in will first determine the message sending method suitable for the native application processing end. Then, based on this message sending method, the request parameter and the first request identification code are sent to the native application processing end, and the native application processing end stores the first request identification code and the request parameter correspondingly.

[0177] Wherein, when storing the first request identification code and the request parameter correspondingly, the first request identification code can be used as the key for searching, the request parameter can be used as the value to be searched, and the first request identification code and the request parameter can be stored in the form of key-value pair, so as to improve the convenience of searching the request parameter.

[0178] As shown in FIG. 5 is the space database in which the native application processing end stores the first request identification code and the request parameter correspondingly. In the predetermined database, the first request identification code and the request parameter are stored in the form of key-value pair. Specifically, the request parameter corresponding to the first request identification code KK14 is request parameter 1; the request parameter corresponding to the first request identification code AA13 is request parameter 2; the request parameter corresponding to the first request identification code B894a is request parameter 3; the request parameter corresponding to the first request identification code KK007 is request parameter 4; the request parameter corresponding to the first request identification code AA147 is request parameter 5; the request parameter corresponding to the first request identification code B8143 is request parameter 6; and the request parameter corresponding to the first request identification code MK0187 is request parameter 7.

[0179] The embodiment has the advantages that the problem that only strings can be transmitted when data is transmitted between the web application and the native application through the front plug-in is considered, the request body parameter is encoded into a string form request parameter after the request body parameter of the first request is extracted, the first request is allocated a unique first request identification code, the mapped request parameter and the first request identification code are transmitted to the native application processing end corresponding storage, the problem that the request parameter of the first request cannot be parsed by the native application and thus the request parameter cannot be obtained is solved, and the native application can conveniently and quickly obtain the request parameter of the first request.

[0180] Please refer to FIG. 6 In one embodiment, step 410 can specifically include but is not limited to steps 610-620.

[0181] Step 610, determining a target encoding rule from a plurality of candidate encoding rules based on the request type of the first request;

[0182] Step 620, encoding the request body parameter based on the target encoding rule to obtain the request parameter.

[0183] Steps 610-620 are described in detail below.

[0184] In step 610, a target encoding rule is determined from a plurality of candidate encoding rules based on the request type of the first request.

[0185] The candidate encoding rule is used to indicate the specific encoding mode of the request body parameter of the request meeting a certain request type.

[0186] In the implementation of the embodiment, the format of the request body parameter under different request types is often different. Different encoding modes are suitable for different formats of the request body parameter, and different encoding rules suitable for different request types can be set. Based on this, first, the mapping table of each candidate request type and each candidate encoding rule is called in the case of permission. Then, the candidate request type same as the request type of the first request is found in the mapping table. Finally, the candidate encoding rule corresponding to the candidate request type same as the request type of the first request in the mapping table is determined as the target encoding rule.

[0187] In step 620, the request body parameter is encoded based on the target encoding rule to obtain the request parameter.

[0188] In the implementation of the embodiment, the request body parameter is encoded according to the ordering of the request body parameter in the first request based on the target encoding rule, and all the request body parameters are converted into a string form, thereby obtaining the request parameter.

[0189] As shown in FIG. 7 corresponding relationship between different request types and candidate encoding rules. Specifically, when the request body parameter indicated by the request type is a data type of binary data (ArrayBuffer type), or a large object of binary type such as image, sound or multimedia file (Blob type), or a general file type (File type), Base64 encoding is taken as the target encoding rule, and Base64 encoding is used for the request body parameter of Array Buffer type, File type, and Blob type. When the request body parameter indicated by the request type is a utility type for processing URL query strings (URLSearchParams type), the key-value pair concatenation string encoding is taken as the target encoding rule, and the encoding method of the key-value pair concatenation string is used for the request body parameter of URLSearchParams type. When the request body parameter indicated by the request type is a serialized table and form format data (FormData type), the traversal concatenation into a subdivided field file type (Multipart type) or a form type supporting uploaded files (form-data type) is taken as the target encoding rule, and the encoding method of Multipart type or form-data type is used for the request body parameter of FormData type.

[0190] The advantage of this embodiment is that the format difference of the request body parameter carried by the request of different request types is considered, and the encoding rule matched with the request body parameter of each request type is used for parameter encoding, so that the request body parameters of different formats are all converted into string form, the request parameters are successfully transmitted to the native application processing end by using the pre-insert plug-in, and the success rate of loading web application content by the native application is improved.

[0191] Detailed description of step 330

[0192] In step 330, a first request identification code is added to the first request to generate a second request.

[0193] Please refer to FIG. 8 In one embodiment, the specific process of generating the second request can include but is not limited to the following steps 810-820:

[0194] Step 810, if it is determined that the request parameter has been stored in the native application processing end, then based on the request type of the first request, a target concatenation rule is selected from a plurality of candidate concatenation rules;

[0195] Step 820, based on the first request and the first request identification code, a second request is created by using the target concatenation rule.

[0196] Steps 810-820 are described in detail as follows.

[0197] In step 810, if it is determined that the request parameters have been stored at the native application processing end, a target splicing rule is selected from a plurality of candidate splicing rules based on the request type of the first request.

[0198] The candidate splicing rule is used to indicate how to splice the first request and the first request identification code into an integral whole without changing the specific content and original format of the first request.

[0199] In the embodiment, first, if it is determined that the request parameters have been stored at the native application processing end, a mapping table of candidate request types and candidate splicing rules is called in the case of permission. Then, a candidate request type identical to the request type of the first request is searched in the mapping table. Finally, the candidate splicing rule corresponding to the candidate request type identical to the request type of the first request in the mapping table is determined as the target splicing rule.

[0200] In step 820, a second request is created based on the first request and the first request identification code by using the target splicing rule.

[0201] In the embodiment, the first request and the first request identification code are spliced into an integral whole according to the target splicing rule, so as to obtain the second request.

[0202] For example, if the request body parameter indicated by the request type is serialized table and form data (FormData type), the candidate splicing rule is set to add the first request identification code at the front of the first request; if the request body parameter indicated by the request type is a utility tool type (URLSearchParams type) for processing URL query strings, the candidate splicing rule is set to add the first request identification code at the end of the first request.

[0203] The embodiment has the advantage that the new second request is created only after the first request and the first request identification code are determined to be stored, and the second request is continued to be initiated, which can reduce the risk that the first request and the first request identification code are not stored successfully, but the second request is sent and the request parameters cannot be found. Since the front plug-in only prefixes the first request identification code before the first request or appends the first request identification code after the first request, without changing the specific form and specific content of the first request, the native application processing end can receive a request that is almost the same as the first request initiated on the web application, and the request accuracy is improved.

[0204] Please refer to FIG. 9In one embodiment, the specific process of determining that the request parameter has been stored in the native application processing end can include, but is not limited to, the following steps 910-920:

[0205] Step 910, receiving the message data sent by the target function in the native application processing end;

[0206] Step 920, if it is determined that the message data contains the target field, it is determined that the request parameter has been stored in the native application processing end.

[0207] The steps 910-920 are described in detail as follows.

[0208] In step 910, the message data sent by the target function in the native application processing end is received.

[0209] The target function refers to a callback function that passes a function as a parameter to another function, and the target function is used to be called after the native application processing end completes the storage of the first request identification code and the request parameter.

[0210] The message data is used to inform the front plug-in that the first request identification code and the request parameter have been stored.

[0211] In the implementation of this embodiment, after the native application processing end completes the storage of the first request identification code and the request parameter, the native application processing end will call the predetermined JavaScript callback function (target function) to send the message data to the web application to inform the web application that the storage of the first request identification code and the request parameter has been completed. Based on this, the front plug-in will receive the message data sent by the target function in the native application processing end.

[0212] In step 920, if it is determined that the message data contains the target field, it is determined that the request parameter has been stored in the native application processing end.

[0213] The target field refers to a field used to identify that the storage of the first request identification code and the request parameter is completed.

[0214] In the implementation of this embodiment, first, the message data is parsed to identify the code, field, etc. contained in the message data. Then, if it is determined that the message data has the target field used to identify that the storage of the first request identification code and the request parameter is completed, it is determined that the request parameter has been stored in the native application processing end; if it is determined that the message data does not have the target field used to identify that the storage of the first request identification code and the request parameter is completed, it is determined that the request parameter has not been stored in the native application processing end.

[0215] The embodiment has the advantage that the message data sent by the target function and the determination of whether the request parameter is stored by the native application processing end according to whether the target field exists in the message data can improve the identification accuracy of parameter storage, so that the native application processing end can successfully assemble a new request corresponding to the first request, thereby reducing the failure of loading web application content through the native application.

[0216] Next, the deployment and initialization process of the front plug-in are described in detail.

[0217] Please refer to FIG. 10 In one embodiment, the specific process of deploying the front plug-in can include but is not limited to the following steps 1010-1020:

[0218] Step 1010, embed the front plug-in into the web application, and register the message sending method of the front plug-in at the native application processing end;

[0219] Step 1020, initialize the front plug-in to make the front plug-in process the request according to the predetermined logic.

[0220] The steps 1010-1020 are described in detail below.

[0221] In step 1010, the front plug-in is embedded into the web application, and the message sending method of the front plug-in is registered at the native application processing end.

[0222] The web application refers to the web application in the hybrid application, and the web application in the hybrid application is often represented by a control (webview) for displaying web pages.

[0223] The message sending method is used to indicate the sending process of the request message, the message format, etc.

[0224] In the implementation of this embodiment, first, the front plug-in is embedded into the web application under the condition of authorized permission, so that the web application realizes data interaction with the native application processing end through the API provided by the front plug-in. Then, the message sending method of the front plug-in is registered at the native application processing end, so that the data interaction between the native application processing end and the front plug-in meets the protocol requirements.

[0225] In step 1020, the front plug-in is initialized to make the front plug-in process the request according to the predetermined logic.

[0226] The predetermined logic is used to indicate the receiving process and sending process of the request message of the front plug-in, and is also used to indicate the protocol format and request form compatible between the front plug-in and the web application and the native application, etc.

[0227] 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.

[0228] The advantage of this embodiment is that by embedding the pre-plugin into the web application, the pre-plugin can be set up before the native application processing end, which can quickly and easily build a data transmission bridge between the web application and the native application, and improve the transmission efficiency and comprehensiveness of request messages, etc.

[0229] like FIG. 11 The diagram illustrates the overall workflow of the pre-plugin preceding the native application processor. Specifically, firstly, the pre-plugin JSSDK is imported into the H5 page of the web application. The message passing method of the pre-plugin is registered on the native application processor (APP native), and the pre-plugin is initialized, a process similar to steps 1010-1020 above. Next, the pre-plugin intercepts the first request initiated by the object in the web application, generates a first request identifier code, and generates a second request URL, a process similar to steps 410-420 and 810-820 above. Further, the pre-plugin sends the first request identifier code and request parameters to the native application processor, which stores these information, a process similar to step 320 above. Finally, once the native application processor has stored the corresponding first request identifier code and request parameters, it notifies the pre-plugin to continue initiating requests. The pre-plugin then sends a second request to the native application processor, a process similar to steps 910-920 above. Finally, the native application processor intercepts the second request, finds and writes the request parameters, generates and sends a page loading request to the web application server, and the specific process is similar to step 340 above. To save space, it will not be described in detail.

[0230] General description of specific execution method of native application processing end of embodiments of the present disclosure

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

[0232] like FIG. 12 As shown, a method for loading web application content through a native application according to an embodiment of this disclosure is applied to a native application processing end.

[0233] Specifically, the method of loading web application content through native applications may include:

[0234] Step 1210, receiving the request parameter and the first request identification code sent by the front plug-in and storing them correspondingly;

[0235] Step 1220, receiving the second request sent by the front plug-in;

[0236] Step 1230, based on the first request identification code in the second request, searching for the request parameter stored correspondingly with the first request identification code;

[0237] Step 1240, parsing the first request to obtain a parsing result, assembling the parsing result and the request parameter to obtain a page loading request, and sending the page loading request to the web application server.

[0238] The steps 1210-1240 are described in detail below.

[0239] In step 1210, the request parameter and the first request identification code sent by the front plug-in are received and stored correspondingly.

[0240] The request parameter is obtained from the first request by the front plug-in when the first request is received. The first request identification code is generated by the front plug-in for the first request.

[0241] The first request is used to load the web application content through the native application.

[0242] In the implementation of this embodiment, after the front plug-in obtains the request parameter and generates the first request identification code, the front plug-in sends the request parameter and the first request identification code to the native application processing end. Based on this, the native application processing end receives the request parameter and the first request identification code sent by the front plug-in, so as to make up for the defect that the request parameter cannot be parsed from the business request sent by the web application.

[0243] Further, since the first request identification code uniquely identifies the first request, in order to distinguish the request parameters of different requests, the native application processing end also stores the request parameter of the first request and the first request identification code correspondingly, so that the first request identification code and the request parameter correspond one by one.

[0244] In step 1220, the second request sent by the front plug-in is received.

[0245] The second request includes the first request and the first request identification code.

[0246] In the implementation of this embodiment, after the front plug-in generates the second request, the front plug-in sends the second request to the native application processing end after determining that the native application processing end has stored the first request identification code and the request parameter. Based on this, the native application processing end receives the second request sent by the front plug-in.

[0247] It should be noted that the second request is completely the same as the first request except the first request identifier. Therefore, the native application processing end obtains the first request and the first request identifier from the second request. The native application processing end still cannot directly analyze the request parameters when analyzing the first request in the second request.

[0248] In step 1230, the request parameters corresponding to the first request identifier are searched based on the first request identifier in the second request.

[0249] In the implementation of the embodiment, since the native application processing end stores a plurality of request identifiers and the request parameters corresponding to the request identifiers in the predetermined database. Based on this, in the case of authorized permission, the predetermined database is called, wherein the predetermined database has a plurality of candidate request identifiers and the candidate request parameters corresponding to each candidate request identifier, and each candidate request parameter is possessed in a request initiated in the web application. Then, the first request identifier in the second request is compared with each candidate request identifier, and the candidate request parameter corresponding to the candidate request identifier identical to the first request identifier is taken as the searched request parameter corresponding to the first request identifier.

[0250] In step 1240, the first request is analyzed to obtain an analysis result, the analysis result and the request parameters are assembled to obtain a page loading request, and the page loading request is sent to the web application server.

[0251] In order to save space, the specific process of analyzing the first request and the specific process of assembling the analysis result and the request parameters of the embodiment of the present disclosure will be described in detail below, and will not be described here.

[0252] Through the steps 1210-1240, the preposed plug-in is set before the native application processing end in the embodiment of the present disclosure. After receiving the first request for loading the web application content through the native application, the preposed plug-in intercepts the first request, obtains the request parameters of the first request, generates a first request identification code for identifying the target request, and sends the request parameters and the first request identification code to the corresponding storage of the native application processing end. Since the preposed plug-in can identify the format of the first request and obtain the request parameters, and the preposed plug-in and the native application processing end are in ordinary transmission and are not limited by the protocol, the native application processing end can receive the request parameters and store the first request identification code correspondingly. When the preposed plug-in forwards the first request to the native application processing end, the first request identification code is correspondingly forwarded. In this way, the native application processing end can find the corresponding request parameters according to the first request identification code, and integrate the request parameters and the parsing result of the first request into a page loading request. Compared with the page loading request sent to the web application server in the prior art, the page loading request contains the request parameters in addition to the parsing result, so that the final loading and display will not fail due to the lack of request parameters.

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

[0254] Detailed description of step 1240

[0255] In step 1240, the first request is parsed to obtain a parsing result, the parsing result and the request parameters are assembled to obtain a page loading request, and the page loading request is sent to the web application server.

[0256] Please refer to FIG. 13 In one embodiment, the specific process of parsing the first request can include but is not limited to the following steps 1310-1320:

[0257] Step 1310, determining a target domain name resolution service from a plurality of candidate domain name resolution services based on a predetermined loading condition;

[0258] Step 1320, performing domain name resolution on the first request based on the target domain name resolution service to obtain a parsing result.

[0259] The steps 1310-1320 will be described in detail below.

[0260] In step 1310, a target domain name resolution service is determined from a plurality of candidate domain name resolution services based on a predetermined loading condition.

[0261] The predetermined loading condition is used to define a time delay range for loading the webpage application content for the first request, or to define a degree of preventing domain name hijacking to be met by the domain name resolution service for the first request.

[0262] The candidate domain name resolution service is used to indicate domain name resolution services of different sources. For example, the candidate domain name resolution service includes, but is not limited to, an HttpDNS domain name resolution service, a LocalDNS domain name resolution service, and various domain name resolution services distinguished according to network locations. The candidate domain name resolution service also includes various domain name resolution services distinguished according to different operators.

[0263] In the embodiment, since the domain name resolution of each candidate domain name resolution service causes different time delay sizes and different degrees of preventing domain name hijacking, first, a time delay score and a hijacking prevention score of each candidate domain name resolution service are determined. The time delay score is obtained by averaging time delay data of the candidate domain name resolution service before the current time and inputting the average value into a first function. The first function is a decreasing function with the time delay data as the independent variable and the time delay score as the dependent variable. The hijacking prevention score is determined according to an un-hijacked rate of the candidate domain name resolution service before the current time. The un-hijacked rate is a proportion of requests that do not cause domain name hijacking in all requests processed by the candidate domain name resolution service. The un-hijacked rate is input into a second function to obtain the hijacking prevention score. The second function is an increasing function with the un-hijacked rate as the independent variable and the hijacking prevention score as the dependent variable.

[0264] Further, the candidate domain name resolution services are filtered to obtain intermediate domain name resolution services that meet the predetermined loading condition in terms of the hijacking prevention score and the time delay score. Finally, one of the intermediate domain name resolution services is randomly selected as the target domain name resolution service.

[0265] It should be noted that, through trial comparison, in the embodiment, the HttpDNS can be preferentially selected as the target domain name resolution service.

[0266] In step 1320, the domain name resolution of the first request is performed based on the target domain name resolution service to obtain a resolution result.

[0267] In the embodiment, when the domain name resolution of the first request is performed, the native application processing end directly accesses an interface of the target domain name resolution service using a protocol supported by the target domain name resolution service, and sends a domain name address in the first request to the target domain name resolution service. Then, the target domain name resolution service finds an IP address of a server with the minimum access delay according to the domain name address provided by the native application processing end, and returns the IP address to the native application processing end. Finally, the native application processing end obtains the IP address as the resolution result.

[0268] The embodiment has the advantages that the target domain name resolution service most suitable for requirements is screened out from multiple candidate domain name resolution services according to the predetermined loading condition, and the target domain name resolution service is used for domain name resolution of the first request, so that the security of domain name resolution is improved, and the time delay of request transmission and the risk of domain name hijacking are reduced.

[0269] Please refer to FIG. 14 In one embodiment, the specific process of assembling the resolution result and the request parameter to obtain the page loading request can include but is not limited to the following steps 1410-1420.

[0270] Step 1410, object verification is performed on the target object initiating the first request.

[0271] Step 1420, if it is determined that the object verification is passed, a page loading request is assembled based on the resolution result and the request parameter.

[0272] The steps 1410-1420 are described in detail below.

[0273] In step 1410, object verification is performed on the target object initiating the first request.

[0274] The target object refers to a user initiating a request for loading web application content in a web application (Web page) in a hybrid application.

[0275] The object verification is used to verify whether the target object has the permission to send a request corresponding to a request type to which the first request belongs.

[0276] For the sake of brevity, the specific process of object verification performed on the target object initiating the first request in the embodiment of the present disclosure will be described in detail below. No further description is given here.

[0277] In step 1420, if it is determined that the object verification is passed, a page loading request is assembled based on the resolution result and the request parameter.

[0278] In the specific implementation of the embodiment, if it is determined that the object verification is passed, it indicates that the target object initiating the first request is legal and has the permission to send the first request, and is allowed to load corresponding web application content according to the request of the target object. Based on this, a page loading request is assembled based on the resolution result and the request parameter, and the specific process of assembling the page loading request based on the resolution result and the request parameter is similar to the following steps 1710-1730. For the sake of brevity, no further description is given here.

[0279] The embodiment has the advantage 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, and when the target object does not have the permission to send the first request, the page loading request is not assembled, thereby reducing resource consumption caused by an error request.

[0280] Please refer to FIG. 15 In one embodiment, the specific process of object verification on the target object initiating the first request can include, but is not limited to, the following steps 1510-1530:

[0281] Step 1510, determining the object terminal address of the target object;

[0282] Step 1520, comparing the object terminal address with the candidate object address of the object having the permission to initiate the first request;

[0283] Step 1530, if there is a candidate object address consistent with the object terminal, determining that the object verification is passed.

[0284] The steps 1510-1530 are described in detail below.

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

[0286] The object terminal address is the terminal address of the object terminal used by the target object.

[0287] In step 1520, the candidate object address is the terminal address of the object terminal used by the object having the permission to initiate the first request.

[0288] In the implementation of this embodiment, the object terminal address is compared with the candidate object address of the object having the permission to initiate the first request to determine whether the target object is one of the objects having the permission to initiate.

[0289] In step 1530, if there is a candidate object address consistent with the object terminal, it indicates that the target object is one of the objects having the permission to initiate, and it is determined that the object verification is passed; if there is no candidate object address consistent with the object terminal, it indicates that the target object is not the object having the permission to initiate, and it is determined that the object verification is not passed, and the first request is rejected.

[0290] As FIG. 16As shown, it is a list of objects having the authority to initiate the first request. Specifically, there are 7 objects having the authority to initiate the first request. The 7 objects are, in order, object 1 with candidate object address Qeda1, object 2 with candidate object address dqaq414, object 3 with candidate object address dmqe89, object 4 with candidate object address cnad14, object 5 with candidate object address quncqo51, object 6 with candidate object address foqnfa87, and object 7 with candidate object address cmqfiqw09.

[0291] The advantage of this embodiment is that comparing the object terminal address of the target object with the candidate object addresses of the objects having the authority to initiate the first request can determine whether the target object is an object having the authority to initiate the first request in a relatively fast manner, thereby improving the efficiency and accuracy of object verification.

[0292] Please refer to FIG. 17 In one embodiment, the specific process of assembling the parsing result and the request parameter to obtain the page loading request can include, but is not limited to, the following steps 1710-1730:

[0293] Step 1710, performing decoding processing on the request parameter to obtain the request body parameter of the first request;

[0294] Step 1720, filling the request body parameter into a predetermined code template to obtain a target code segment;

[0295] Step 1730, assembling the target code segment and the IP address in the parsing result to obtain the page loading request.

[0296] The steps 1710-1730 are described in detail below.

[0297] In step 1710, the request parameter is decoded to obtain the request body parameter of the first request.

[0298] The decoding processing refers to restoring the request parameter in the form of a string into the request body parameter.

[0299] In the implementation of this embodiment, first, the target encoding rule used in encoding is determined according to the request type of the first request. Then, the request parameter conforming to the target encoding rule is decoded into the request body parameter in the parameter format corresponding to the request type according to the request type of the first request, so as to restore the request parameter in the form of a string into the request body parameter, and enable the native application processing end to obtain the request body parameter of the first request.

[0300] In step 1720, the request body parameter is filled into a predetermined code template to obtain a target code segment.

[0301] The predetermined code template refers to a template used to fill the request body parameter, and is a template used by the request body of the first request.

[0302] The target code segment is used to indicate the code formed by the request body part in the first request.

[0303] In the embodiment, first, the position to be filled by the request body parameter in the predetermined code template is determined, wherein the predetermined code template has a dictionary container request_header; then, the request body parameter is filled into the dictionary container request_header in the predetermined code template to form the target code segment.

[0304] In step 1730, the target code segment and the IP address in the parsing result are assembled to obtain the page loading request.

[0305] In the embodiment, the target code segment and the IP address in the parsing result are assembled according to the protocol format to obtain a request that can be received by the web application server, thereby obtaining the page loading request.

[0306] The embodiment has the advantage that the request parameter is decoded in the native application processing end to obtain the request body parameter loaded in the request body of the first request, the request body parameter is filled into the predetermined code template to obtain the target code segment, and the target code segment and the IP address are assembled to obtain the page loading request, so that the native application processing end can initiate the IP direct connection to the web application server by using the page loading request, the request can be successfully sent to the web application server in the case of preventing domain name hijacking, and the loading success rate of loading the web application content by the native application is improved.

[0307] Please refer to FIG. 18 In one embodiment, after the page loading request is sent to the web application server, the method for loading the web application content by the native application can further include but is not limited to the following steps 1810-1820:

[0308] Step 1810, receiving the target resource provided by the web application server according to the page loading request;

[0309] Step 1820, loading the web application content based on the target resource.

[0310] The steps 1810-1820 are described in detail below.

[0311] In step 1810, the target resource provided by the web application server according to the page loading request is received.

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

[0313] In the embodiment, after the native application processing end sends the page loading request to the web application server, the web application server determines how the web application content to be loaded according to the page loading request, finds the corresponding target resource according to the web application content to be loaded, and sends the target resource to the native application processing end. Based on this, the native application processing end receives the target resource provided by the web application server according to the page loading request.

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

[0315] In the embodiment, the native application processing end uses the web view engine of the web application to load the web application content into a visual page for display, thereby realizing loading of the web application content through the native application.

[0316] The embodiment has the advantages that after the page loading request is sent to the web application server, the web application content is loaded by using the web view engine to render the target resource provided by the web application server, the web application content can be loaded through the native application, the page loading demand of the first request of different request types can be met, and the loading success rate of the web application content loaded through the native application is improved.

[0317] Detailed description of web application server providing target resource of embodiments of the present disclosure

[0318] Since the security levels of different resources in the web application server are different, if the resources are directly provided according to the page loading request, the security of the resources is often low. Based on this, the embodiment of the disclosure provides a resource output scheme based on request verification, which can improve the security of the resources provided by the web application server to the native application.

[0319] Please refer to FIG. 19 In one embodiment, the web application server provides the target resource according to the following manner:

[0320] Step 1910, first verifying the page loading request;

[0321] Step 1920, if the first verification is passed, determining the target resource for loading the web application content from a plurality of candidate resources based on the page loading request;

[0322] Step 1930, providing the target resource based on the response to the page loading request.

[0323] The steps 1910-1930 are described in detail below.

[0324] In step 1910, the first verification is performed on the page loading request.

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

[0326] For the sake of brevity, the specific process of the first verification of the embodiment of the present disclosure will be described in detail hereinafter. No further description is given here.

[0327] In step 1920, if the first verification is passed, the target resource for loading the web application content is determined from the plurality of candidate resources based on the page loading request.

[0328] The candidate resource refers to the resource for rendering different pages. The web pages rendered by different candidate resources are generally different.

[0329] In the implementation of the embodiment, if the first verification is passed, the request body parameters in the page loading request are first extracted. Then, the candidate resources indicated by the request body parameters are filtered from the plurality of candidate resources based on the request body parameters in the page loading request. Finally, all the filtered candidate resources are integrated into the target resource.

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

[0331] In the implementation of the embodiment, when the page loading request is responded, the target resource is added to the response, so as to provide the target resource when the response to the page loading request is provided.

[0332] The advantage of the embodiment is that the resource output is based on the request verification, and the verification link of the page loading request is introduced. Only when the first verification of the page loading request is determined to be successful, the target resource for loading the web application content is provided to the native application. This way can improve the security and reliability of the web application server providing the resource to the native application.

[0333] For more details, please refer to FIG. 20 In one embodiment, the specific process of the first verification on the page loading request can include but is not limited to the following steps 2010-2030:

[0334] Step 2010, determining the initiator, request timestamp, and request content of the page loading request;

[0335] Step 2020, performing the first sub-verification on the page loading request based on the initiator and request timestamp;

[0336] Step 2030, performing the second sub-verification on the page loading request based on the request content of the page loading request.

[0337] The steps 2010-2030 are described in detail as follows.

[0338] In step 2010, the initiating object, request timestamp, and request content of the page loading request are determined.

[0339] The initiating object refers to the object that triggers the generation of the page loading request through the first request, which is equivalent to the object that initiates the first request.

[0340] The request timestamp is used to indicate the creation time of the page loading request.

[0341] In the implementation of this embodiment, the request parsing of the page loading request is performed to obtain the initiating object, request timestamp, and request content of the page loading request under the condition of authorized permission.

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

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

[0344] For the sake of brevity, the specific process of the first sub-verification of the embodiment of the present disclosure will be described in detail hereinafter. No further description is given here.

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

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

[0347] For the sake of brevity, the specific process of the second verification of the embodiment of the present disclosure will be described in detail hereinafter. No further description is given here.

[0348] Please refer to FIG. 21 In one embodiment, the specific process of the first sub-verification can include but is not limited to the following steps 2110-2120:

[0349] Step 2110, performing object verification of the page loading request based on the initiating object and comparison of each authorized initiating object of the preset address mapping table;

[0350] Step 2120, if the object verification is passed, performing time validity verification of the page loading request based on the time difference between the request timestamp and the current time.

[0351] The steps 2110-2120 are described in detail as follows.

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

[0353] The preset address mapping table is configured to store terminal addresses of each authorized initiating object.

[0354] In the implementation of the embodiment, the specific process of step 2110 is similar to steps 1510-1530 described above. The difference is that the execution subject of steps 1510-1530 described above is the native application processing end, and the execution subject of step 2110 is the web application server. For the sake of brevity, no further description is given.

[0355] In step 2120, if the object verification is passed, the time validity verification is performed on the page loading request based on a time difference between the request timestamp and the current time.

[0356] In the implementation of the embodiment, if the object verification is passed, it indicates that the initiating object has the initiating right. Based on this, first, the time difference between the request timestamp and the current time is calculated. Then, the time difference is compared with a predetermined time threshold, wherein the predetermined time threshold is configured 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 it is determined that the validity verification of the page loading request is passed, and the first sub-verification is passed. If the time difference is greater than the predetermined time threshold, it indicates that the page loading request has been invalid in the time dimension, and it is determined that the validity verification of the page loading request is not passed, and the first sub-verification is not passed.

[0357] The advantage of the embodiment is that the time validity and the source legitimacy of the page loading request are considered for verification. By using the serial verification manner, the source legitimacy of the page loading request is verified first, and then the timeliness of the page loading request is verified in the case that the source legitimacy of the page loading request is determined to be legitimate, which can improve the verification efficiency of the page loading request, thereby reducing the risk of being unable to load the web application content through the native application and improving the loading success rate.

[0358] Please refer to FIG. 22 In one embodiment, the specific process of the second sub-verification can include but is not limited to steps 2210-2230:

[0359] Step 2210, obtaining an object public key of an initiating object initiating the page loading request;

[0360] Step 2220, performing the un-signing on the request content based on the object public key to obtain an un-signing result;

[0361] Step 2230, performing second sub-verification on the page loading request based on comparison between the un-sign result and the request content of the first request.

[0362] Steps 2210-2230 are described in detail as follows.

[0363] In step 2210, an object public key of an initiating object initiating the page loading request is acquired.

[0364] The object public key refers to a key publicly disclosed by the initiating object initiating the page loading request, and the object public key is used to decrypt data encrypted by the object private key corresponding to the object public key by the initiating object.

[0365] In the embodiment, the object public key publicly disclosed by the initiating object initiating the page loading request can be acquired from the initiating object initiating the page loading request or a trusted third-party platform.

[0366] In step 2220, the request content is un-signed based on the object public key to obtain an un-sign result.

[0367] The un-sign result is used to indicate what the unencrypted content of the page loading request is.

[0368] In the embodiment, the request content is decrypted by using the object public key to realize un-signing of the request content, and the result after decryption is taken as the un-sign result.

[0369] In step 2230, the second sub-verification on the page loading request is performed based on comparison between the un-sign result and the request content of the first request.

[0370] In the embodiment, first, the un-sign result is compared with the request content of the first request. Then, if the un-sign result is consistent with the request content of the first request, it is determined that the request content of the page loading request is correct, and it is determined that the second sub-verification on the page loading request is passed. Otherwise, if the un-sign result is inconsistent with the request content of the first request, it is determined that the request content of the page loading request is incorrect, and it is determined that the second sub-verification on the page loading request is not passed.

[0371] The embodiment has the advantage that the correctness of the request content of the page loading request is considered, the correctness of the request content is determined according to consistency between the un-sign result and the request content of the first request, the accuracy of the page loading request is improved, the risk that the web application content cannot be loaded by the native application is reduced, and the loading success rate is improved.

[0372] Detailed description of method of loading web application content through native application of embodiments of the present disclosure

[0373] The following refers to FIG. 23 , FIG. 24A-FIG. 24B, detailed exemplary description of the embodiment of the present disclosure method of loading web application content through the native application implementation details.

[0374] As shown in FIG. 23 , is the overall process of loading web application content through the native application in hybrid application. Specifically, first, the web application initiates a first request through the webview, and injects a custom request script in the front-end plug-in to make the front-end plug-in initialize, and after initialization, the request parameters are obtained, the first request identification code is generated and sent to the native application processing end (APP Naitve), the specific process is similar to the above steps 310-320. Further, the native application processing end receives and saves the request parameters and the first request identification code, and notifies the web application to continue to request, at this time, the object sends a second request to the native application processing end through the web application, the webview will intercept the second request, and send the second request to the native application processing end through the front-end plug-in, the specific implementation process is similar to the above step 330. Further, the native application processing end will perform domain name resolution on the second second request, specifically, calling the target domain name resolution service (HTTPDNS SDK) for resolution, obtaining the resolution result, and the resolution result has an IP address. Next, using the IP address, the request parameters found based on the first request identification code are assembled to form a page loading request, the specific process is similar to the above steps 1230-1240. Finally, the native application processing end initiates a page loading request (IP direct connection request) to the web application server (business server); the web application server will process the page loading request and return an answer to the native application processing end, providing resources for loading the web application content, so that the native application processing end can use the web application to respond to the resources based on the resources, load and display the web application content, the specific process is similar to the above steps 1810-1820. To save space, no longer tedious.

[0375] As shown in FIG. 24AThe diagram illustrates a comparison of latency for 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 embodiments of this disclosure. Specifically, 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 disclosure, which introduces a pre-plugin and httpdns service, does not differ significantly in latency from other schemes, but can meet the content loading requirements of any request, thereby reducing loading failures when loading web application content through native applications.

[0376] like FIG. 24B The diagram 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 embodiments of this disclosure. Specifically, 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 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 disclosure, which introduces a pre-plugin and httpdns service, does not differ significantly in latency from other schemes, but can meet the content loading requirements of any request, thereby reducing loading failures when loading web application content through native applications.

[0377] Device and equipment description of embodiments of the present disclosure

[0378] It can be understood that, although each step in each of the above flowcharts is shown in sequence according to the representation of the arrow, these steps are not necessarily executed in the order represented by the arrow. Unless otherwise specified in the embodiments, the execution of these steps is not strictly limited in sequence, and these steps can be executed in other orders. Moreover, at least part of the steps in the above flowcharts can include multiple steps or multiple stages, which are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily sequential, but can be alternately executed with at least part of other steps or steps or stages in other steps.

[0379] It should be noted that, in each specific embodiment of the present application, when it is necessary to perform relevant processing according to the target object attribute information or attribute information set and other data related to the characteristics of the target object, the permission or consent of the target object is obtained first, and the collection, use and processing of these data comply with relevant laws, regulations and standards. In addition, when the embodiments of the present application need to obtain target object attribute information, the separate permission or separate consent of the target object is obtained through a pop-up window or by jumping to a confirmation page, and after obtaining the separate permission or separate consent of the target object, the necessary target object related data for enabling the embodiments of the present application to normally run is obtained.

[0380] FIG. 25 A structural schematic diagram of a device 2500 for loading web application content through a native application provided by the embodiments of the present disclosure is provided. The device 2500 for loading web application content through a native application is applied to a front-end plug-in before a native application processing end, and the device 2500 for loading web application content through a native application includes:

[0381] An intercepting unit 2510 is configured to intercept a first request, the first request being used to load web application content through a native application;

[0382] An obtaining unit 2520 is configured to obtain a request parameter of the first request from the first request, generate a first request identification code used to identify the first request, and send the request parameter and the first request identification code to a native application processing end corresponding storage;

[0383] A generating unit 2530 is configured to increase the first request identification code on the basis of the first request to generate a second request;

[0384] The sending unit 2540 is configured to send the second request to the native application processing end, so that the native application processing end finds the request parameter stored corresponding to the first request identification code based on the increased first request identification code, parses the first request to obtain a parsing result, assembles the parsing result and the request parameter to obtain a page loading request, and sends the page loading request to the web application server.

[0385] Optionally, the obtaining unit 2520 includes:

[0386] The encoding module (not shown) is configured to extract the request body parameter of the first request, and encode the request body parameter to obtain the request parameter.

[0387] The generating module (not shown) is configured to generate the first request identification code of the first request based on the request type of the first request and a preset identification code generation rule.

[0388] Optionally, the encoding module (not shown) is configured to:

[0389] Determine the target encoding rule from a plurality of candidate encoding rules based on the request type of the first request.

[0390] Encode the request body parameter based on the target encoding rule to obtain the request parameter.

[0391] Optionally, the second request is generated in the following manner:

[0392] If it is determined that the request parameter has been completely stored in the native application processing end, a target splicing rule is selected from a plurality of candidate splicing rules based on the request type of the first request.

[0393] Create the second request based on the first request and the first request identification code by using the target splicing rule.

[0394] Optionally, determining that the request parameter has been completely stored in the native application processing end includes:

[0395] Receive the message data sent by the native application processing end through the target function.

[0396] If it is determined that the message data contains the target field, it is determined that the request parameter has been completely stored in the native application processing end.

[0397] Optionally, the front-end plug-in is deployed in the following manner:

[0398] Embed the front-end plug-in into the web application, and register the message sending method of the front-end plug-in in the native application processing end.

[0399] Perform an initialization operation on the front-end plug-in, so that the front-end plug-in processes the request according to the predetermined logic.

[0400] FIG. 26 A structural schematic diagram of the device 2600 for loading web application content through a native application is provided for embodiments of the present disclosure. The device for loading web application content through a native application is applied to a native application processing end. The device 2600 for loading web application content through a native application comprises:

[0401] The first receiving unit 2610 is configured to receive and store, in correspondence, the request parameter and the first request identification code sent by the front plug-in, wherein the request parameter is obtained by the front plug-in from a first request when the first request is received, and the first request identification code is generated by the front plug-in for the first request, and the first request is used to load web application content through a native application;

[0402] The second receiving unit 2620 is configured to receive the second request sent by the front plug-in, and the second request comprises the first request and the first request identification code;

[0403] The finding unit 2630 is configured to find the request parameter stored in correspondence with the first request identification code based on the first request identification code in the second request;

[0404] The processing unit 2640 is configured to parse the first request to obtain a parsing result, assemble the parsing result and the request parameter to obtain a page loading request, and send the page loading request to a web application server.

[0405] Optionally, the processing unit 2640 is configured to:

[0406] determine a target domain name resolution service from a plurality of candidate domain name resolution services based on a predetermined loading condition;

[0407] perform domain name resolution on the first request based on the target domain name resolution service to obtain a parsing result, wherein the parsing result is used to indicate an IP address of a web application server providing web application content.

[0408] Optionally, the processing unit 2640 is configured to:

[0409] perform object verification on a target object initiating the first request;

[0410] if it is determined that the object verification is passed, assemble a page loading request based on the parsing result and the request parameter.

[0411] Optionally, the object verification on the target object initiating the first request comprises:

[0412] determining an object terminal address of the target object;

[0413] comparing the object terminal address with a candidate object address of an authorized object initiating the first request;

[0414] If there is a candidate object address consistent with the object terminal, it is determined that the object verification is passed.

[0415] Optionally, the processing unit 2640 is configured to:

[0416] perform a reverse coding process on the request parameter to obtain a request body parameter of the first request;

[0417] fill the request body parameter into a predetermined code template to obtain a target code segment;

[0418] assemble the target code segment and the IP address in the parsing result to obtain a page loading request.

[0419] Optionally, the apparatus 2600 for loading web application content through a native application further comprises a resource processing unit (not shown), which is configured to:

[0420] receive a target resource provided by a web application server according to the page loading request;

[0421] load the web application content based on the target resource.

[0422] Optionally, the web application server provides the target resource in the following manner:

[0423] a verification module (not shown) configured to perform a first verification on the page loading request;

[0424] a determination module (not shown) configured to, if the first verification is passed, determine a target resource for loading the web application content from a plurality of candidate resources based on the page loading request;

[0425] a feedback module (not shown) configured to provide the target resource based on a response to the page loading request.

[0426] Optionally, the verification module (not shown) comprises:

[0427] a determination sub-module (not shown) configured to determine an initiating object, a request timestamp, and a request content of the page loading request;

[0428] a first verification sub-module (not shown) configured to perform a first sub-verification on the page loading request based on the initiating object and the request timestamp;

[0429] a second verification sub-module (not shown) configured to perform a second sub-verification on the page loading request based on the request content of the page loading request.

[0430] Optionally, the first verification sub-module (not shown) is configured to:

[0431] The object verification is performed on the page loading request based on a comparison of the initiating object and each authorized initiating object in a preset address mapping table.

[0432] If the object verification is passed, the time validity verification is performed on the page loading request based on a time difference between a request timestamp and a current time.

[0433] Optionally, a second verification submodule (not shown) is configured to:

[0434] Obtain an object public key of the initiating object initiating the page loading request;

[0435] Unsign the request content based on the object public key to obtain an un-sign result;

[0436] Perform a second sub-verification on the page loading request based on a comparison of the un-sign result and the request content of the first request.

[0437] Referring to FIG. 27 , FIG. 27 A structure block diagram of a terminal for implementing a part of the method for loading web application content through a native application according to the embodiments 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, and the like. Those skilled in the art can understand that the terminal structure shown does not constitute a limitation on a mobile phone or a computer, and can include more or fewer components than shown, or combine certain components, or different component arrangements. FIG. 27 The terminal structure shown does not constitute a limitation on a mobile phone or a computer, and can include more or fewer components than shown, or combine certain components, or different component arrangements.

[0438] The RF circuit 2710 can be used for receiving and sending signals in the process of receiving or calling, in particular, receiving the downlink information of the base station and processing it by the processor 2780; in addition, sending the uplink data to the base station.

[0439] The memory 2715 can be used for storing software programs and modules, and the processor 2780 executes various function applications and data processing of the object terminal by running the software programs and modules stored in the memory 2715.

[0440] The input unit 2730 can be used for receiving input digital or character information, and generating key signal input related to the setting and function control of the object terminal. Specifically, the input unit 2730 can include a touch panel 2731 and other input devices 2732.

[0441] The display unit 2740 can be used to display input information or provided information and various menus of the object terminal. The display unit 2740 can include a display panel 2741.

[0442] The audio circuit 2760, the speaker 2761, and the microphone 2762 can provide an audio interface.

[0443] In the present embodiment, the processor 2780 included in the terminal can execute the method for loading web application content through a native application of the foregoing embodiments.

[0444] The terminal of the embodiments of the present disclosure includes but is not limited to a mobile phone, a computer, a smart voice interactive device, a smart home appliance, a vehicle-mounted terminal, an aircraft, etc. The embodiments of the present disclosure can be applied to various scenarios, including but not limited to data security, blockchain, data storage, information technology, etc.

[0445] FIG. 28 FIG. 28 A structural block diagram of a server for implementing part of the method for loading web application content through a native application of the embodiments of the present disclosure. The server can have relatively large differences due to different configurations or performances, and can include one or more central processing units (CPUs) 2822 (for example, one or more processors) and a memory 2832, one or more storage media 2830 (for example, one or more mass storage devices) storing application programs 2842 or data 2844. Among them, the memory 2832 and the storage medium 2830 can be temporary storage or persistent storage. The programs stored in the storage medium 2830 can include one or more modules (not shown in the figure), each of which can include a series of instruction operations in the server. Further, the central processing unit 2822 can be configured to communicate with the storage medium 2830 and execute a series of instruction operations in the storage medium 2830 on the server.

[0446] The server can 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 ServerTM, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM, etc.

[0447] The central processing unit 2822 in the server can be used to execute the method for loading web application content through a native application of the embodiments of the present disclosure.

[0448] The embodiment of the present disclosure further provides a computer readable storage medium for storing program codes, the program codes being used to execute the method for loading web application content through a native application according to the foregoing various embodiments.

[0449] The embodiment of the present disclosure further provides a computer program product, which comprises a computer program. A processor of a computer device reads the computer program and executes, so that the computer device executes the method for loading web application content through a native application.

[0450] The terms "first", "second", "third", "fourth" and the like in the description of the present disclosure and the above drawings, if any, are used to distinguish similar objects, and are not necessarily used to describe a particular order or sequence. It should be understood that the data thus used can be interchanged under appropriate circumstances, so that the embodiments of the present disclosure described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "comprise" and "include" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device that includes a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but can include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0451] It should be understood that in the present disclosure, "at least one" means one or more, and "multiple" means two or more. "And / or" is used to describe the association relationship of the associated objects, which means that there can be three relationships, for example, "A and / or B" can represent three cases of only A, only B and A and B existing at the same time, where A and B can be singular or plural. The character " / " generally represents an "or" relationship between the associated objects before and after it. "At least one of the following" or similar expressions means any combination of these items, including any combination of single or multiple 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.

[0452] It should be understood that in the description of the embodiments of the present disclosure, the meaning of multiple (or multiple items) is more than two, greater than, less than, more than, etc. are not included in the number, above, below, etc. are understood to include the number.

[0453] In several embodiments provided in the present disclosure, it should be understood that the disclosed system, device and method can be implemented in other manners. For example, the described device embodiments are merely schematic. For example, the division of the units is merely logical function division. There can be another division manner for the actual implementation. For example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections can be indirect couplings or communication connections through some interfaces, devices or units, and can be in electrical, mechanical or other forms.

[0454] The units described as separated components can or can not be physically separated, and the components displayed as units can or can not be physical units, i.e., can be located in one place, or can be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purposes of the embodiments.

[0455] In addition, each functional unit in the various embodiments of the present disclosure can be integrated in one processing unit, or each unit can exist physically as a separate unit, or two or more units can be integrated in one unit. The integrated unit can be implemented in the form of hardware, or in the form of software functional units.

[0456] When the integrated unit is implemented in the form of software functional units and sold or used as an independent product, it can be stored in a computer readable storage medium. Based on such an understanding, the technical solutions of the present disclosure essentially, or the part that contributes to the prior art, or all or a part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium, and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods in the various embodiments of the present disclosure. The foregoing storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk, and various media that can store program codes.

[0457] It should also be understood that the various embodiments provided by the present disclosure can be combined in any manner to achieve different technical effects.

[0458] The above is a specific explanation of the embodiments of the present disclosure, but the present disclosure is not limited to the above-described embodiments, and those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present disclosure, and these equivalent modifications or substitutions are included in the scope defined by the claims of the present disclosure.

Claims

1. A method for loading web application content by a native application, characterized in that, A front plug-in applied before a native application processing end, the front plug-in being a set of API interface for realizing bidirectional communication between a web application and a native application, the method comprising: intercepting a first request for loading the web application content through the native application; extracting a request body parameter of the first request from the first request, and calling a mapping table of each candidate request type and each candidate encoding rule, the mapping table at least including: using Base64 encoding for the request body parameter of an Array Buffer type, a File type and a Blob type; using key-value pair splicing string encoding for the request body parameter of a URLSearchParams type; using multipart type or form-data type encoding for the request body parameter of a FormData type; determining the candidate encoding rule corresponding to the candidate request type in the mapping table as a target encoding rule, encoding the request body parameter based on the target encoding rule to obtain a request parameter, finding an identification code generation rule applicable to the request type based on the request type under a preset identification code generation rule, generating a first request identification code of the first request according to the found identification code generation rule, and sending the request parameter and the first request identification code to the native application processing end for storage; wherein the request type is used to indicate an operation to be implemented in the web application by the first request; generating a second request by adding the first request identification code to the first request; sending the second request to the native application processing end, so that the native application processing end finds the request parameter stored corresponding to the first request identification code based on the added first request identification code, parses the first request to obtain a parsing result, which is used for object verification of a target object initiating the first request by the native application processing end, if it is determined that the object verification is passed, performs reverse encoding processing on the request parameter to obtain the request body parameter of the first request; fills the request body parameter into a predetermined code template to obtain a target code segment; assembles the target code segment and an IP address in the parsing result to obtain a page loading request, and sends the page loading request to a web application server; the second request is generated by: receiving message data sent by the native application processing end through a target function, the target function being used to be called after the native application processing end completes storage of the first request identification code and the request parameter; If it is determined that the message data contains a target field, it is determined that the request parameter has been stored in the native application processing end, and a target splicing rule is selected from a plurality of candidate splicing rules based on the request type; based on the first request and the first request identification code, the second request is created using the target splicing rule, wherein the candidate splicing rule at least includes: when the request type indicates that the request body parameter is of the FormData type, the first request identification code is added to the front of the first request; when the request type indicates that the request body parameter is of the URLSearchParams type, the first request identification code is added to the end of the first request; and only when the message data contains a target field indicating that the first request identification code and the request parameter are stored, the second request is created and sent.

2. The method of claim 1, wherein, The front plug-in is deployed by: Embedding the front plug-in into the web application and registering the message sending method of the front plug-in in the native application processing end; Performing initialization operation on the front plug-in to make the front plug-in process the request according to the predetermined logic.

3. A method for loading web application content by a native application, characterized in that, Applied to the native application processing end, the native application processing end has a front plug-in, the front plug-in is a set of API interface for realizing the bidirectional communication between the web application and the native application, and the method comprises: Receiving and storing the request parameter and the first request identification code sent by the front plug-in, wherein the request parameter is extracted from the request body parameter of the first request by the front plug-in when receiving the first request, and is obtained by encoding the request body parameter based on a target encoding rule, the first request identification code is generated based on the request type of the first request by the front plug-in, and the identification code generation rule suitable for the request type is found in the preset identification code generation rule, and the first request identification code is generated according to the found identification code generation rule, the first request is used to load the web application content through the native application; wherein the request type is used to indicate the operation to be implemented in the web application by the first request, and the target encoding rule is a mapping table of each candidate request type and each candidate encoding rule, and the candidate encoding rule corresponding to the candidate request type identical with the request type of the first request in the mapping table; Receiving the second request sent by the front plug-in, the second request comprising the first request and the first request identification code; Based on the first request identification code in the second request, the request parameter stored corresponding to the first request identification code is found; Based on the first request identification code in the second request, the request parameter stored corresponding to the first request identification code is found; The first request is parsed to obtain a parsing result, a target object initiating the first request is subjected to object verification, if it is determined that the object verification is passed, the request parameter is subjected to reverse coding processing to obtain a request body parameter of the first request; the request body parameter is filled into a predetermined code template to obtain a target code segment; the target code segment and an IP address in the parsing result are assembled to obtain a page loading request, and the page loading request is sent to a web application server; The second request is generated in the following manner: The message data sent by the native application processing end through a target function is received, and the target function is used to be called only after the native application processing end completes storage of the first request identifier code and the request parameter; If it is determined that the message data contains a target field, it is determined that the request parameter has been stored in the native application processing end, and a target splicing rule is selected from a plurality of candidate splicing rules based on the request type; the second request is created based on the first request and the first request identifier code by using the target splicing rule, wherein the candidate splicing rules at least include: when the request body parameter indicated by the request type is of a FormData type, the first request identifier code is added to the front of the first request; when the request body parameter indicated by the request type is of a URLSearchParams type, the first request identifier code is added to the end of the first request, and only when the message data contains a target field for indicating that the storage of the first request identifier code and the request parameter is completed, the second request is created and sent.

4. The method of claim 3, wherein, The parsing of the first request to obtain a parsing result comprises: Based on a predetermined loading condition, a target domain name resolution service is determined from a plurality of candidate domain name resolution services; Based on the target domain name resolution service, the first request is subjected to domain name resolution to obtain the parsing result, wherein the parsing result is used to indicate an IP address of the web application server providing the web application content.

5. The method of claim 3, wherein, The object verification of the target object initiating the first request comprises: Determining an object terminal address of the target object; Comparing the object terminal address with candidate object addresses of objects having authority to initiate the first request; If one of the candidate object addresses is consistent with the object terminal, it is determined that the object verification is passed.

6. The method of claim 3, wherein, After the page loading request is sent to the web application server, the method further comprises: Receiving a target resource provided by the web application server according to the page loading request; Loading the web application content based on the target resource.

7. An apparatus for loading web application content by a native application, the apparatus comprising: a native application; a web application; and a web application content loader configured to load the web application content into the native application. A front plug-in applied before a native application processing end, the front plug-in is a set of API interfaces for realizing bidirectional communication between a web application and a native application, and the device comprises: An intercepting unit configured to intercept a first request, the first request being used to load web application content by the native application; The acquisition unit is configured to extract the request body parameter of the first request from the first request, and call a mapping table of each candidate request type and each candidate encoding rule, the mapping table at least including: using Base64 encoding for the request body parameter of Array Buffer type, File type and Blob type; using key-value pair splicing string encoding for the request body parameter of URLSearchParams type; using multipart type or form-data type encoding for the request body parameter of FormData type; determining the candidate encoding rule corresponding to the candidate request type same as the request type of the first request in the mapping table as a target encoding rule, encoding the request body parameter based on the target encoding rule to obtain a request parameter, finding an identification code generation rule applicable to the request type based on the request type in a preset identification code generation rule, generating a first request identification code of the first request according to the found identification code generation rule, and sending the request parameter and the first request identification code to the native application processing end corresponding storage; wherein the request type is used to indicate the operation to be implemented in the web application by the first request; The generation unit is configured to generate a second request by adding the first request identification code to the first request; The sending unit is configured to send the second request to the native application processing end, so that the native application processing end finds the request parameter stored corresponding to the first request identification code based on the added first request identification code, analyzes the first request to obtain an analysis result, which is used for object verification of a target object initiating the first request by the native application processing end, if it is determined that the object verification is passed, performs reverse encoding processing on the request parameter to obtain the request body parameter of the first request; fills the request body parameter into a predetermined code template to obtain a target code segment; assembles the target code segment and the IP address in the analysis result to obtain a page loading request, and sends the page loading request to a web application server; The second request is generated by: receiving message data sent by a target function of the native application processing end, the target function being configured to be called only after the storage of the first request identification code and the request parameter by the native application processing end is completed; If it is determined that the message data contains a target field, it is determined that the request parameter has been stored in the native application processing end, and a target splicing rule is selected from a plurality of candidate splicing rules based on the request type; based on the first request and the first request identification code, the second request is created using the target splicing rule, wherein the candidate splicing rule at least includes: when the request type indicates that the request body parameter is of the FormData type, the first request identification code is added to the front of the first request; when the request type indicates that the request body parameter is of the URLSearchParams type, the first request identification code is added to the end of the first request, and only when the message data contains a target field indicating that the first request identification code and the request parameter are stored, the second request is created and sent.

8. The apparatus of claim 7, wherein, The front plug-in is deployed by: Embedding the front plug-in into the web application, and registering the message sending method of the front plug-in in the native application processing end; The front plug-in is initialized to make the front plug-in process requests according to the predetermined logic.

9. An apparatus for loading web application content by a native application, the apparatus comprising: a native application; a web application; and a web application content loader configured to load the web application content into the native application. Applied to the native application processing end, the native application processing end has a front plug-in, the front plug-in is a set of API interfaces for realizing the bidirectional communication between the web application and the native application, and the device comprises: A first receiving unit for receiving and storing the request parameter and the first request identification code sent by the front plug-in, wherein the request parameter is extracted from the request body parameter of the first request by the front plug-in when receiving the first request, and is obtained by encoding the request body parameter based on a target encoding rule, the first request identification code is generated based on the request type of the first request by the front plug-in, and the identification code generation rule suitable for the request type is found in a preset identification code generation rule, and the first request identification code is generated according to the found identification code generation rule, the first request is used to load the web application content through the native application; wherein the request type is used to indicate the operation to be implemented in the web application by the first request, and the target encoding rule is a mapping table of each candidate request type and each candidate encoding rule, and the candidate encoding rule corresponding to the candidate request type identical to the request type of the first request in the mapping table; A second receiving unit for receiving the second request sent by the front plug-in, the second request comprising the first request and the first request identification code; A finding unit for finding the request parameter stored corresponding to the first request identification code based on the first request identification code in the second request; A finding unit for finding the request parameter stored corresponding to the first request identification code based on the first request identification code in the second request; The processing unit is configured to: parse the first request to obtain a parsing result, perform object verification on a target object initiating the first request, perform reverse coding processing on the request parameter if the object verification is passed, and obtain a request body parameter of the first request; fill the request body parameter into a predetermined code template to obtain a target code segment; assemble the target code segment and an IP address in the parsing result to obtain a page loading request, and send the page loading request to a web application server; The second request is generated by the following method: The processing unit is configured to: receive message data sent by the target function of the native application processing end, and the target function is configured to be called only after the native application processing end completes storage of the first request identifier and the request parameter; If it is determined that the message data contains a target field, it is determined that the request parameter has been stored in the native application processing end, and a target splicing rule is selected from a plurality of candidate splicing rules based on the request type; the second request is created based on the first request and the first request identifier using the target splicing rule, wherein the candidate splicing rules at least include: when the request body parameter indicated by the request type is of the FormData type, the first request identifier is added at the front of the first request; when the request body parameter indicated by the request type is of the URLSearchParams type, the first request identifier is added at the end of the first request, and the second request is created and sent only when the message data contains a target field indicating that the storage of the first request identifier and the request parameter is completed.

10. The apparatus of claim 9, wherein, The processing unit is configured to: Determine a target domain name resolution service from a plurality of candidate domain name resolution services based on a predetermined loading condition; Perform domain name resolution on the first request based on the target domain name resolution service to obtain the parsing result, wherein the parsing result is used to indicate the IP address of the web application server providing the web application content. 11.An electronic device comprising a memory and a processor, the memory storing a computer program, wherein, The processor executes the computer program to implement the method for loading web application content by a native application according to any one of claims 1 to 2, or the method for loading web application content by a native application according to any one of claims 3 to 6.

12. A computer readable storage medium, the storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the method for loading web application content by a native application according to any one of claims 1 to 2, or the method for loading web application content by a native application according to any one of claims 3 to 6.

13. A computer program product comprising a computer program, the computer program being read and executed by a processor of a computer device, so that the computer device executes the method for loading web application content by a native application according to any one of claims 1 to 2, or the method for loading web application content by a native application according to any one of claims 3 to 6.

Images