A resource acquisition method and apparatus, an electronic device, and a computer readable medium

Abstract

The application discloses a resource acquisition method and device, electronic equipment and a computer readable medium, and relates to the technical field of computers. A specific embodiment comprises receiving a resource acquisition request, and then generating a corresponding timestamp anti-theft link based on the resource acquisition request. The target content distribution node is located based on the timestamp anti-theft link, so that the target content distribution node can verify the resource acquisition request based on the timestamp anti-theft link. In response to determining that the verification fails and that there is a resource package update, the target content distribution node is called to acquire the updated resource package. The updated resource package is parsed to acquire the target resource. Therefore, the latest resource can be quickly and accurately acquired.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a resource acquisition method, apparatus, electronic device, and computer-readable medium. Background Technology

[0002] Currently, the resource packages for the micro-application platform are stored on a Network Attached Storage (NAS) cluster. Before users can open a micro-application, they need to call a download interface. Large downloads consume significant internal network bandwidth, and the NAS experiences heavy input / output (I / O) pressure. With the increasing adoption of micro-applications, the number is estimated to reach 900-1000, making bandwidth and I / O the performance bottleneck for resource downloads.

[0003] In the process of developing this application, the inventors discovered at least the following problems in the prior art:

[0004] As the number of micro-applications increases, bandwidth and I / O become the performance bottlenecks for downloading micro-application resources. Summary of the Invention

[0005] In view of this, embodiments of this application provide a resource acquisition method, apparatus, electronic device, and computer-readable medium, which can solve the problem that bandwidth and I / O become the performance bottleneck for micro-application resource downloads when the number of existing micro-applications increases.

[0006] To achieve the above objectives, according to one aspect of the embodiments of this application, a resource acquisition method is provided, comprising:

[0007] Receive resource acquisition requests, and then generate corresponding timestamp anti-leeching based on the resource acquisition requests;

[0008] The target content distribution node is located based on timestamp-based anti-leeching, and the target content distribution node is invoked to verify the resource acquisition request based on timestamp-based anti-leeching.

[0009] In response to the determination that the verification failed and that a resource package update exists, the target content distribution node is invoked to obtain the updated resource package;

[0010] Parse the updated resource package to obtain the target resource.

[0011] Optionally, a timestamp-based anti-leeching mechanism is generated based on the resource acquisition request, including:

[0012] Determine the type of resource to be acquired based on the resource acquisition request;

[0013] Generate a corresponding timestamp-based anti-leeching mechanism based on the type of resource to be acquired.

[0014] Optionally, a corresponding timestamp-based anti-leeching mechanism is generated based on the type of resource to be acquired, including:

[0015] In response to the determination that the type of resource to be obtained is an image, the content delivery network acceleration domain name and resource storage file path corresponding to the resource acquisition request are obtained, and then the content delivery network acceleration domain name and resource storage file path are concatenated to generate a timestamp anti-hotlinking.

[0016] Optionally, a corresponding timestamp-based anti-leeching mechanism is generated based on the type of resource to be acquired, including:

[0017] In response to determining that the type of the resource to be acquired is a resource package, the system parameters of the content distribution service are obtained.

[0018] Based on the resource acquisition request, determine the corresponding resource acquisition encryption string;

[0019] The timestamp algorithm is invoked to generate the corresponding timestamp anti-leeching based on the encrypted string obtained from system parameters and resources.

[0020] Optionally, anti-leeching based on timestamps to locate target content distribution nodes includes:

[0021] Determine the file path for the resource storage in the timestamp-based hotlinking protection;

[0022] Based on the preset correspondence between paths and content distribution nodes, the content distribution node corresponding to the resource storage file path is determined, and then the determined content distribution node is identified as the target content distribution node.

[0023] Optionally, the resource acquisition request is validated, including:

[0024] Determine the preset expiration time in the timestamp-based hotlinking protection;

[0025] Upon determining that the preset expiration time has been reached, a verification failure message is returned.

[0026] Optionally, the resource acquisition request is validated, including:

[0027] Determine the preset expiration time and verification code in the timestamp-based hotlinking protection;

[0028] In response to the determination that the preset expiration time has not been reached and the verification code is incorrect, a verification failure message is returned.

[0029] Optionally, before receiving a resource acquisition request, the method further includes:

[0030] Receive the application startup request and obtain the latest version identifier of the application;

[0031] Determine the local version identifier corresponding to the locally cached resource package, and then compare the latest version identifier with the local version identifier;

[0032] In response to the determination that the latest version identifier is inconsistent with the local version identifier, a corresponding resource acquisition request is generated based on the latest version identifier.

[0033] Optionally, before obtaining the updated resource package, the method further includes:

[0034] Determine the on / off flag for the content distribution service, the download flag for the application to be launched, and the removal flag;

[0035] In response to the determination that the switch identifier is set to the first preset value, the download identifier is set to the second preset value, and the removal identifier is set to the third preset value, the resource package acquisition process is triggered.

[0036] Optionally, before obtaining the updated resource package, the method further includes:

[0037] Obtain the application whitelist. In response to determining that the application to be launched is in the whitelist, trigger the resource package acquisition process based on the content distribution service.

[0038] Optionally, before receiving a resource acquisition request, the method further includes:

[0039] Call a timer to preheat the updated resource package by calling the preheating interface.

[0040] In addition, this application also provides a resource acquisition device, including:

[0041] The receiving unit is configured to receive resource acquisition requests and then generate corresponding timestamp anti-leeching based on the resource acquisition requests;

[0042] The verification unit is configured to locate the target content distribution node based on timestamp anti-leeching, and call the target content distribution node to verify the resource acquisition request based on timestamp anti-leeching;

[0043] The resource package acquisition unit is configured to, in response to a determination of verification failure and the existence of a resource package update, call the target content distribution node to obtain the updated resource package;

[0044] The parsing unit is configured to parse updated resource packages to obtain the target resource.

[0045] Optionally, the receiving unit is further configured to:

[0046] Determine the type of resource to be acquired based on the resource acquisition request;

[0047] Generate a corresponding timestamp-based anti-leeching mechanism based on the type of resource to be acquired.

[0048] Optionally, the receiving unit is further configured to:

[0049] In response to the determination that the type of resource to be obtained is an image, the content delivery network acceleration domain name and resource storage file path corresponding to the resource acquisition request are obtained, and then the content delivery network acceleration domain name and resource storage file path are concatenated to generate a timestamp anti-hotlinking.

[0050] Optionally, the receiving unit is further configured to:

[0051] In response to determining that the type of the resource to be acquired is a resource package, the system parameters of the content distribution service are obtained.

[0052] Based on the resource acquisition request, determine the corresponding resource acquisition encryption string;

[0053] The timestamp algorithm is invoked to generate the corresponding timestamp anti-leeching based on the encrypted string obtained from system parameters and resources.

[0054] Optionally, the verification unit is further configured to:

[0055] Determine the file path for the resource storage in the timestamp-based hotlinking protection;

[0056] Based on the preset correspondence between paths and content distribution nodes, the content distribution node corresponding to the resource storage file path is determined, and then the determined content distribution node is identified as the target content distribution node.

[0057] Optionally, the verification unit is further configured to:

[0058] Determine the preset expiration time in the timestamp-based hotlinking protection;

[0059] Upon determining that the preset expiration time has been reached, a verification failure message is returned.

[0060] Optionally, the verification unit is further configured to:

[0061] Determine the preset expiration time and verification code in the timestamp-based hotlinking protection;

[0062] In response to the determination that the preset expiration time has not been reached and the verification code is incorrect, a verification failure message is returned.

[0063] Optionally, the resource acquisition apparatus further includes a request generation unit, configured to:

[0064] Receive the application startup request and obtain the latest version identifier of the application;

[0065] Determine the local version identifier corresponding to the locally cached resource package, and then compare the latest version identifier with the local version identifier;

[0066] In response to the determination that the latest version identifier is inconsistent with the local version identifier, a corresponding resource acquisition request is generated based on the latest version identifier.

[0067] Optionally, the resource package acquisition unit is further configured to:

[0068] Determine the on / off flag for the content distribution service, the download flag for the application to be launched, and the removal flag;

[0069] In response to the determination that the switch identifier is set to the first preset value, the download identifier is set to the second preset value, and the removal identifier is set to the third preset value, the resource package acquisition process is triggered.

[0070] Optionally, the resource package acquisition unit is further configured to:

[0071] Obtain the application whitelist. In response to determining that the application to be launched is in the whitelist, trigger the resource package acquisition process based on the content distribution service.

[0072] Optionally, the resource package acquisition unit is further configured to:

[0073] Call a timer to preheat the updated resource package by calling the preheating interface.

[0074] In addition, this application also provides a resource acquisition electronic device, including: one or more processors; and a storage device for storing one or more programs, which, when executed by one or more processors, enable the one or more processors to implement the resource acquisition method as described above.

[0075] In addition, this application also provides a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the resource acquisition method as described above.

[0076] One embodiment of the above invention has the following advantages or beneficial effects: This application receives a resource acquisition request and then generates a corresponding timestamp anti-leeching chain based on the resource acquisition request; it locates the target content distribution node based on the timestamp anti-leeching chain, and calls the target content distribution node to verify the resource acquisition request based on the timestamp anti-leeching chain; in response to determining that the verification fails and that there is a resource package update, it calls the target content distribution node to obtain the updated resource package; and it parses the updated resource package to obtain the target resource. This ensures that the latest resources can be obtained quickly and accurately.

[0077] The further effects of the aforementioned unconventional alternative methods will be explained below in conjunction with specific implementation methods. Attached Figure Description

[0078] The accompanying drawings are provided to better understand this application and do not constitute an undue limitation thereof. Wherein:

[0079] Figure 1 This is a schematic diagram of the main flow of the resource acquisition method according to the first embodiment of this application;

[0080] Figure 2 This is a schematic diagram of the main flow of the resource acquisition method according to the second embodiment of this application;

[0081] Figure 3 This is a schematic diagram illustrating an application scenario of the resource acquisition method according to the third embodiment of this application;

[0082] Figure 4 This is a schematic diagram of the main units of a resource acquisition device according to an embodiment of this application;

[0083] Figure 5 This is an exemplary system architecture diagram to which embodiments of this application can be applied;

[0084] Figure 6 This is a schematic diagram of the structure of a computer system suitable for implementing terminal devices or servers in the embodiments of this application. Detailed Implementation

[0085] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of this application, including various details to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0086] Figure 1 This is a schematic diagram of the main flow of the resource acquisition method according to the first embodiment of this application, as shown below. Figure 1 As shown, the resource acquisition methods include:

[0087] Step S101: Receive resource acquisition request, and then generate corresponding timestamp anti-leeching based on the resource acquisition request.

[0088] In this embodiment, the entity executing the resource acquisition method (e.g., a system integrating a client, a service server AP, an origin server, a CDN node, a NAS, a service server, and a management terminal) can receive resource acquisition requests via wired or wireless connections. The service server AP in the execution entity refers to the micro-application server that communicates with the software development kit (SDK) in the client. Network Attached Storage (NAS) is defined as a special type of dedicated data storage server, including storage devices such as disk arrays, CD / DVD drives, tape drives, or removable storage media. A business server refers to an internally managed back-end operation server. The management terminal is used to upload new version resource packages. Resource acquisition requests can be requests for micro-application resource packages. A micro-application is a cross-platform front-end development framework. Businesses developed based on this framework are commonly deployed in mobile banking, such as "Travel," "Convenience Services," and "Finance" within the mobile banking app. Resources are the building blocks developed based on the micro-application framework, and can be categorized into public beta packages and internal beta packages. Application resources officially released to users are called public beta packages; those released to customers during internal trial operations, before conditions are mature, are called internal beta packages.

[0089] The executing entity can obtain parameters related to generating timestamp anti-hotlinking from the resource acquisition request, such as file path / file name: FileDir / FileName (e.g., / test.dat), MD5 (expiration time-file path-custom key) 32-bit: md5hash (e.g., a pre-defined string), expiration time, the expiration time of the link used to generate anti-hotlinking, and timestamp, hexadecimal: expireTimestamp (e.g., 20130615).

[0090] For example, the template for a resource acquisition request can be (specifically, "xxx" in the template for the resource acquisition request below can represent any character, and this application embodiment does not limit the specific character represented by "xxx"):

[0091] https: / / mb1.mp.xxx.com / mp / statics / cdn / md5(FileDir) / FileName? wsSe cret=md5hash&wsTime=expireTimestamp

[0092] For example, a resource retrieval request can be:

[0093] https: / / mb1.mp.xxx.com / mp / statics / cdn / 01 / 39405cb09f8cbaa5224655ffe8b5d25b / 1618301804404.zip?key1=0ec538308937f0952e764042109ae869&key2=60755EEC

[0094] For example, timestamp-based hotlinking prevention can be:

[0095] http: / / cdn.example.com / test.dat?wsSecret=d41d8cd98f00b204e9800998ecf8427e&wsTime=20130615

[0096] Alternatively, it can also be:

[0097] http: / / cdn.example.com / d41d8cd98f00b204e9800998ecf8427e / 20130615 / test.dat

[0098] Where test.dat is the file path. <path>June 15, 2013 is the expiration date. <endtime>;d41d8cd98f00b204e9800998ecf8427e is the original encrypted string.

[0099] Specifically, before receiving a resource acquisition request, the resource acquisition method also includes:

[0100] The system receives an application startup request and obtains the latest version identifier for the application. It then determines the local version identifier corresponding to the locally cached resource package and compares it with the latest version identifier. In response to a discrepancy between the latest version identifier and the local version identifier, it generates a corresponding resource acquisition request based on the latest version identifier. In other words, before acquiring the resource package, the executing entity verifies the version of the acquired resource package to determine if it is the latest version. If it is not the latest version, it generates a resource acquisition request for the latest version (e.g., version serial number, example: version 8.0.9) resource package based on the latest version identifier (e.g., version serial number, example: version 8.0.9).

[0101] Specifically, before receiving a resource acquisition request, the method also includes:

[0102] A timer is invoked to call the preheating interface to preheat the updated resource package. Preheating can involve the executing entity calling the CDN provider's preheating API to request the CDN node to perform an origin pull (an operation where the CDN node fails to retrieve the requested resource or the cached resource has expired) to fetch the public test package (which could be an updated public test package). This package is cached on the CDN node before the user accesses it, enabling faster downloads. For example, after detecting a new resource package release, the executing entity can determine whether to allow retrieval of the new resource package through a Content Delivery Network (CDN) node. If the executing entity determines that retrieval of the new resource package through the CDN node is permitted, it actively calls the CDN provider's CDN preheating interface to preheat the new resource package and determines whether the preheating was successful. If successful, a preheating success message is returned to the executing entity; otherwise, an exception message is returned.

[0103] Specifically, the anti-leeching mechanism generates corresponding timestamps based on resource acquisition requests, including:

[0104] The type of resource to be acquired is determined based on the resource acquisition request; a corresponding timestamp anti-leeching mechanism is generated based on the type of resource to be acquired.

[0105] In this embodiment, when generating timestamp-based anti-leeching links, the executing entity can adopt different strategies for different types of micro-application resources. This is because different types of micro-application resources have different security level requirements; for example, images have lower sensitivity, while resource packages have higher sensitivity. When the resource type to be obtained is an image, the generated timestamp-based anti-leeching link does not include parameters related to URL validity. When the resource type to be obtained is a resource package, the generated timestamp-based anti-leeching link must include parameters related to URL validity verification. The executing entity can generate corresponding timestamp-based anti-leeching links for images or resource packages based on whether the resource type to be obtained is an image or a resource package.

[0106] Specifically, based on the type of resource to be acquired, a corresponding timestamp-based anti-leeching mechanism is generated, including:

[0107] In response to the determination that the type of resource to be retrieved is an image, the system retrieves the content delivery network (CDN) acceleration domain (the domain that provides acceleration for resource download [mb1.mp.xxx.com]) and the resource file path corresponding to the resource retrieval request. Then, it concatenates the CDN acceleration domain and the resource file path to generate a timestamp-based anti-hotlinking mechanism. For example, if the type of resource to be retrieved is an image, the client concatenates the image resource download URL. Specifically, the client stores the CDN acceleration domain, and the server interface returns partial path information of the resource. Concatenating these two information yields a valid image resource download URL, which corresponds to the timestamp-based anti-hotlinking mechanism for the image resource.

[0108] Specifically, based on the type of resource to be acquired, a corresponding timestamp-based anti-leeching mechanism is generated, including:

[0109] In response to the determination that the type of resource to be acquired is a resource package, the system parameters of the content distribution service are obtained (i.e., file path, encrypted data, and expiration time). Based on the resource acquisition request, the corresponding resource acquisition encryption string (i.e., the original encryption string in the disclosure document) is determined. A timestamp algorithm is invoked to generate the corresponding timestamp-based anti-hotlinking mechanism based on the system parameters and the resource acquisition encryption string. For example, if the type of resource to be acquired is a resource package, the server uniformly invokes the timestamp algorithm to generate the URL for downloading the resource package, i.e., the timestamp-based anti-hotlinking mechanism for the corresponding resource package, based on the parameters in the resource acquisition request. Simultaneously, the executing entity can call the CDN node configuration to verify the validity of the URL of the resource package to be acquired, while the URL of the image resource to be acquired is not verified.

[0110] Step S102: Locate the target content distribution node based on timestamp-based anti-leeching, and call the target content distribution node to verify the resource acquisition request based on timestamp-based anti-leeching.

[0111] Specifically, the resource acquisition request is validated, including:

[0112] Determine the preset expiration time in the timestamp anti-hotlinking mechanism; in response to the determination that the preset expiration time has arrived, return a verification failure message. That is, when the preset expiration time is determined to have arrived, for example, setting a cache resource retention period of 10 minutes, if 10 minutes have elapsed since the resource was saved, return a message that the verification of the resource retrieval request has failed.

[0113] Specifically, the resource acquisition request is validated, including:

[0114] The system determines the preset expiration time and verification code in the timestamp-based hotlinking mechanism. In response to the determination that the preset expiration time has not arrived and the verification code is incorrect, it returns a verification failure message. Specifically, when verifying a request, the CDN node, in addition to verifying the expiration time, also verifies whether the MD5 value matches the preset value. For mismatched MD5 values, service will be blocked even if the request has not expired. The validity period for each resource retrieval request is set to 10 minutes. The purpose of the timestamp-based hotlinking mechanism in the micro-application public beta package is to verify that the URL of each resource retrieval request has a certain "timeliness".

[0115] In step S103, in response to determining that the verification failed and that a resource package update exists, the target content distribution node is invoked to obtain the updated resource package.

[0116] Specifically, before obtaining the updated resource package, the method also includes:

[0117] The application determines the following: a switch identifier for the content distribution service (i.e., whether the CDN master switch is on; the switch identifier corresponding to the CDN master switch being on can be "1", and the switch identifier corresponding to the CDN master switch being off can be "0". This application does not limit the specific value of the switch identifier or the meaning of the specific value); a download identifier for the application to be launched (i.e., whether CDN download is enabled; if CDN download is enabled, the corresponding download identifier can be "1", and if CDN download is not enabled, the corresponding download identifier can be "0". This application does not limit the specific value of the download identifier or the meaning of the specific value); and a removal identifier (whether the application has been removed; the removal identifier corresponding to removal can be "1", and the removal identifier corresponding to not removal can be "0". This application does not limit the specific value of the removal identifier or the meaning of the specific value).

[0118] In response to the determination that the switch flag is set to a first preset value (e.g., 1), the download flag is set to a second preset value (e.g., 1), and the removal flag is set to a third preset value (e.g., 0), it indicates that the CDN master switch is turned on, individual micro-applications are available for CDN download, and the micro-applications have not been removed from the platform. This triggers the resource package acquisition process.

[0119] Specifically, before obtaining the updated resource package, the method also includes:

[0120] The process of obtaining the application whitelist, in response to confirming that the application to be launched is on the whitelist, triggers the resource package acquisition process based on the content distribution service. This means that for certain micro-applications, a whitelist approach is used to allow some whitelisted users to obtain resources through CDN nodes, conducting a gray-scale test of CDN acceleration. After verifying the effectiveness, CDN resource acquisition permissions are uniformly opened. Gray-scale testing involves selecting a specific group of people to try out a product or application before its official release, gradually expanding the number of testers to promptly identify and correct any problems, moving from "gray" to "black."

[0121] Step S104: Parse the updated resource package to obtain the target resource.

[0122] The updated resource package is decompressed and decrypted to obtain the decompressed and decrypted micro-application resources, i.e., the target resources.

[0123] This embodiment receives a resource acquisition request and then generates a corresponding timestamp-based anti-leeching mechanism. Based on the timestamp-based anti-leeching mechanism, it locates the target content distribution node and invokes the target content distribution node to verify the resource acquisition request using the timestamp-based anti-leeching mechanism. In response to a failure to verify the request and the discovery of a resource package update, it invokes the target content distribution node to obtain the updated resource package. Finally, it parses the updated resource package to obtain the target resource. This ensures that the latest resources can be obtained quickly and accurately.

[0124] Figure 2 This is a schematic diagram of the main flow of the resource acquisition method according to the second embodiment of this application, as follows: Figure 2 As shown, the resource acquisition methods include:

[0125] Step S201: Receive a resource acquisition request, and then generate a corresponding timestamp anti-leeching mechanism based on the resource acquisition request.

[0126] Step S202: Locate the target content distribution node based on timestamp-based anti-leeching, and call the target content distribution node to verify the resource acquisition request based on timestamp-based anti-leeching.

[0127] The principles of steps S201 to S202 are similar to those of steps S101 to S102, and will not be repeated here.

[0128] Specifically, step S202 can also be achieved through steps S2021 to S2022:

[0129] Step S2021: Determine the resource storage file path in the timestamp anti-hotlinking.

[0130] For example, timestamp-based hotlinking prevention can be:

[0131] http: / / cdn.example.com / test.dat?wsSecret=d41d8cd98f00b204e9800998ecf8427e&wsTime=20130615

[0132] Where test.dat is the path to the resource save file. <path>.

[0133] Step S2022: Based on the preset correspondence between paths and content distribution nodes, determine the content distribution node corresponding to the resource storage file path, and then designate the determined content distribution node as the target content distribution node. This allows for quick and accurate location of CDN nodes that can acquire the resources to be acquired, improving resource acquisition efficiency.

[0134] In step S203, in response to determining that the verification failed and that a resource package update exists, the target content distribution node is invoked to obtain the updated resource package.

[0135] Step S204: Parse the updated resource package to obtain the target resource.

[0136] The principles of steps S203 to S204 are similar to those of steps S103 to S104, and will not be repeated here.

[0137] Figure 3 This is a schematic diagram illustrating an application scenario of the resource acquisition method according to the third embodiment of this application. The resource acquisition method of this embodiment is applied to a scenario where resource packages corresponding to micro-applications are downloaded before opening a large number of micro-applications. For example... Figure 3 As shown, the business server (AP) refers to the micro-application server that communicates with the micro-application software development kit (SDK) in the client. After resources are deployed to Network Attached Storage (NAS) (NAS is defined as a special type of dedicated data storage server, including storage devices such as disk arrays, CD / DVD drives, tape drives, or removable storage media) and embedded system software, providing cross-platform file sharing capabilities, the business server records the resource path information in a database. Before opening the micro-application, the client needs to obtain the CDN accelerated URL from the business server (AP). The business server retrieves the saved path information from the database and constructs the CDN URL. The client uses the CDN URL to retrieve content from the CDN secondary node. If the content exists, it is returned; otherwise, it continues to retrieve content from the CDN primary node. If the content exists, it is returned; otherwise, the primary node retrieves the resource from the origin server (the public IP address corresponding to the CDN node's file-pulling server address [mb1.mp.xxx.com]) and returns it to the client. The origin server needs to read the initially saved resource from the NAS. The business server refers to the internally managed backend operation server.

[0138] Before downloading the resource package, the management terminal can upload the new version of the resource package to the business server. The micro-application resource version package release timer executes the update, and the management terminal uploads the new version of the resource package (the business server handles the logic processing, receiving the binary stream of the resource package, processing it, and saving it to the NAS file server). NAS encrypts and saves the file to the CDN directory: It checks if each micro-application has a key; if not, it generates a key (for example, a random key can be generated using a random algorithm from the Java platform) for AES encryption of the resource package. After encryption, the resource package is saved to the NAS, and an MD5 symbolic link is generated based on the save path (the MD5 symbolic link is used to hide the actual path of the resource on the NAS). NAS saves file path and other information to the micro-application CDN version table: A new record is added to the CDN version information table to store the symbolic link information. Pre-warming can be achieved by calling the CDN vendor's prefetch API interface, and then the CDN node performs a back-to-origin access to pull the resource package (in this application, for example, a public beta package). The package is cached on the CDN node before the user accesses it, achieving the goal of fast download for the user. After a new package is released for a micro-application resource, in addition to users actively accessing the resource, the business server can use a timer to scan the CDN table and call the CDN preheating interface in the CDN table to actively preheat the public beta package. This improves the user experience by allowing them to quickly open the resource package downloaded directly from the CDN node on their first access to the micro-application. For the preheating interface design, the executing entity can call the micro-application platform to query the CDN anti-leeching URL and transaction code dwn001, providing this information to the client to obtain the CDN node corresponding to each micro-application resource and the download address of the micro-application resource. This allows the CDN node to be called to actively preheat the public beta package based on the download address of the micro-application resource.

[0139] For example, when a client requests the CDN download path for the public beta package of a mini-program (i.e., an application) from the server, the corresponding interface details are as follows:

[0140] Request method: HTTP, POST

[0141] Request URL: This request is only available for the V2 version interface.

[0142] V2 request address: http: / / [ip:port] / mbsmps / V2 / download?txcode=dwn001 Request parameters:

[0143] Field (appid), Description (Mini-application ID), Type (String), Required (Yes)

[0144] Field (sys_version), Description (timestamp), Type (String), Required (No)

[0145] Field (app_type), Description (Initial download type: 0 Closed Beta, 1 Public Beta), Type (String), Required (No)

[0146] Example of request parameters:

[0147] {

[0148] "appid":"app2019091800000003",

[0149] "sys_version":"1568816385278",

[0150] "app_type":""

[0151] }

[0152] Return result:

[0153] Field name (data), Field meaning (none), Data type (Map), Required (yes)

[0154] Field name (cdn_full_url), Field meaning (full CDN download path), Data type (String), Required (No)

[0155] Field Name (cdn_md5), Field Meaning (CDN resource package MD5 (before encryption)), Data Type (String), Required (No)

[0156] Field name (appid), Field meaning (Application ID), Data type (String), Required (Yes)

[0157] Field name (app_version), field meaning (application version number), data type (String), required (No)

[0158] Field name (sys_version), field meaning (timestamp), data type (String), required (No)

[0159] Field name (app_secret_key), Field meaning (application encryption key), Data type (String), Required (No)

[0160] Field name (firsturl), field meaning (redirect path), data type (String), required (No)

[0161] Example of returned results:

[0162]

[0163]

[0164] For example, for micro-application platform preheating and refresh transactions, the transaction code is scdn001. This provides preheating and refresh for version update resources.

[0165] Specifically, examples are as follows:

[0166] Request method: HTTP, POST

[0167] Request URL: http: / / [ip:port] / mbsmps / txCtrl?txcode=scdn001

[0168] Request parameters:

[0169] Field (urlType), Description (url type, yure (preheat), shuaxin (refresh)), Type (String), Required (Yes)

[0170] Field (performType), Description (Execution Type: 1 Manual, 2 Timer), Type (String), Required (No)

[0171] Field (cdnVersions), Description (list of CDNs requiring preheating), Type (List), Required (No)

[0172] Field (pushType), Description (Push type: logo, zip), Type (String), Required (None)

[0173] Example of request parameters:

[0174]

[0175]

[0176] Return result:

[0177] Field name (code), field meaning (status code), data type (int), required (yes)

[0178] Field name (msg), Field meaning (description), Data type (String), Required (Yes)

[0179] Example of returned results:

[0180]

[0181] The above applies to other transactions / interfaces, and will not be listed one by one.

[0182] The business server can set the resource package cache time to 7 days by modifying the `max-age` field in the response header returned by the origin server. The CDN vendor's console can be configured to remove question mark caching, ignoring the parameters after the question mark in the request path to prevent URLs with anti-hotlinking parameters from being cached by the CDN, thus always requiring a return to the origin server. Asynchronous thread preheating of resource packages: For example, a preheating timer runs every 10 minutes, querying the CDN version information table for records that haven't been preheated and have less than 5 preheating attempts. If a resource package has been preheated more than 5 times, it will not be preheated again, even if it hasn't successfully preheated. Different vendors' preheating API interfaces are called based on the CDN vendor's system parameters. Successful preheating sets the preheating field to 1, while failed preheating increases the preheating count. API calls are recorded in a call log table (which records the preheating result, time, and number of preheating attempts). A small switch in the CDN control table determines whether to call the preheating API.

[0183] After the resource package is warmed up in the asynchronous thread, users can open a micro-application by clicking on it in the mobile banking app. Specifically, the micro-application can be a mini-program. For example, users can click on the "Travel" micro-application under "Micro-applications" in the mobile banking app to use its functions. Similarly, users can click on the "Convenience" micro-application under "Micro-applications" in the mobile banking app to use its functions. This application does not limit the specific type of micro-application. Then, the client can perform a resource package update check: specifically, it can compare the version number of the micro-application resource package cached locally on the client with the version number returned by the management terminal. If it is an older version, a resource package update call is made to / v2 / download? dwn001: the client / SDK initiates transaction dwn001 to the server-side business server AP. The execution entity can perform a resource package download check: specifically, the execution entity can call business logic to determine whether the CDN master switch is enabled, whether a single micro-application is open for CDN download, and whether it has been removed from the app store, etc. If the CDN master switch is not enabled (e.g., the CDN master switch flag is detected as 0; this application does not specifically limit this flag), the original transaction method is used for resource download. If the CDN master switch is enabled, the execution entity generates a CDN download link based on the anti-hotlinking algorithm: the anti-hotlinking download URL is generated according to the CDN acceleration service provider's system parameters, and is dynamically generated by the business server when the client requests it. Then, the execution entity can return the CDN timestamp anti-hotlinking to the client. After receiving the CDN timestamp anti-hotlinking, the client can use the CDN timestamp anti-hotlinking to redirect to the CDN via secure data transmission HTTPS: the client uses the OkHttp network framework to initiate a resource retrieval request, and performs anti-hotlinking authentication based on the timestamp to determine whether the resource retrieval request has expired. If the resource retrieval request has not expired, the updated micro-application resource package is obtained through the CDN (Content Delivery Network) node obtained through redirection. Specifically, retrieving the resource package (File Name): When the CDN receives the resource retrieval request, if the resource does not exist on the secondary node, it is pulled from the primary node; if the resource does not exist on the primary node, it is further pulled from the origin server. Resource packages from different paths are unique resources. Reading the resource package: The origin server mb1 reads the resource package from the underlying NAS infrastructure. Returning the resource package: The NAS returns the resource package to the origin server. Returning the resource package, setting max-age: The content cache time is set to 7 days. Returning the micro-application resource package: The CDN node returns the resource package to the client. The client can then decompress and decrypt the resource package: At startup, the client initializes and obtains the keys for all micro-applications from the server, uses these keys for AES decryption, and writes the anti-hotlinking expiration time to the local library. Then, the client enters the homepage: The SDK renders the resource package content, completes the homepage opening, and enters the micro-application homepage.Then, before the anti-leeching expires, when the client initiates a resource retrieval request, it can directly connect to the designated CDN node and perform anti-leeching authentication based on the anti-leeching timestamp to determine if the resource retrieval request has expired, i.e., whether the relevant resources can be obtained based on the request. If the request has not expired, it calls the CDN node determined by the anti-leeching to retrieve the corresponding micro-application resource package and returns it to the client. The client can then decompress and decrypt the resource package: at startup, the client initializes and obtains the keys for all micro-applications from the server, uses these keys for AES decryption, and writes the anti-leeching expiration time to the local library. Then, the client enters the homepage: the SDK renders the resource package content, completes the homepage opening, and enters the micro-application homepage.

[0184] CDN stands for Content Delivery Network. A CDN is an intelligent virtual network built on top of existing networks. Relying on edge servers deployed in various locations, it uses a central platform's load balancing, content distribution, and scheduling modules to allow users to access content from the nearest location, reducing network congestion and improving user access response speed. After a micro-application resource is published, an additional copy of the data needs to be saved to the corresponding CDN directory (the resource package saved before CDN hosting is unencrypted; the additional copy is encrypted). The CDN business logic can use different names for each new release of the same resource package to ensure that the resource package obtained from the CDN is the latest version. The name can be set to {sys_version}.zip, where sys_version is the system version number of the current resource package, which represents the server's current timestamp when the resource package was uploaded. For example: 1593413892.zip. After the server successfully uploads a new version of the resource package, it simultaneously saves the resource package's path, version, and MD5 value to the micro-application CDN version table in the database. The CDN cleanup timer deletes historical version resource packages from the CDN directory, retaining only the five most recently released version packages. In this embodiment, CDN management functions may include: providing preheating and refresh functions for each micro-application's public beta package on the management end; providing preheating and refresh functions for each micro-application's logo icon on the management end; and displaying the preheating and refresh status return code and task submission time (the time the task is submitted to the CDN vendor's API interface, which can be understood as the start time) for each micro-application. This time has a 5-10 minute delay from the network-wide refresh effective time (the network-wide effective time is the time difference between submission and CDN node fetching and caching of the resource package). Resource refresh [purge] / preheating [fetch] is implemented by calling the CDN vendor's API interface. To prevent accidental operation, it operates not by directory but only by the resource URL of the public beta package, and there is a limit to the number of refreshes. After assessing the average daily call volume, the vendor will be contacted to modify the upper limit of the number of refreshes. For example, the number of refreshes is: Micro-application A (5000 URLs / 500 directories per day), Micro-application B (2000 URLs / 100 directories). Preheating limits are: Micro-application A (20000 refreshes / 200GB size per day), Micro-application B (2000 URLs / directory preheating not supported). Client download: Clients can access the old or new resource package download interface based on whether the interface returns APPID_CDN_FULL_URL. That is, the client will download the resource package via CDN or the original file stream based on the returned identifier. While retaining the original resource package download method, the client adds support for CDN download addresses. To avoid frequent client access to the new download interface / V2 / download, the expiration time for the anti-hotlinking cache returned by the local cache server is set to 30-1=29 minutes.If the client encounters an exception other than authentication when downloading using the new interface, switch back to the old interface to download the transaction. The micro-application logo is non-sensitive information and does not include anti-leeching information. The CDN download address is generated by the client (the client stores the CDN accelerated domain name, and the server interface returns partial path information of the resource; the two are concatenated to obtain a valid URL). For some micro-applications that do not require anti-leeching, the client can concatenate the download address; this is configurable. For database design, an example is provided:

[0185] In this application, XXX_MINI_CDN_CONTROL (a micro-application CDN control table used to store the configuration of whether each micro-application opens the CDN download link. It is used for canary release of micro-application resource packages to the CDN to ensure the controllability of micro-application access to the CDN. Here, "XXX" can represent any character, and the specific character represented by "XXX" is not limited in the embodiments of this application).

[0186] Example:

[0187] Field name (APP_ID), field description (application ID), type (varchar2(50)), whether it is null (Notnull), remarks (none);

[0188] Field name (IS_ALLOW_FROM_CDN), field description (whether to allow downloading resources from CDN (0-not allowed, 1-allowed)), type (number(1)), whether to be null (Not null), remarks (0);

[0189] Field name (IS_CLIENT_CDN_URL), field description (whether the client generates CDN_URL (0-no 1-yes, Logo and some micro-applications that do not require anti-hotlinking can configure this value to 1)), type (number(1)), whether it is empty (Notnull), remarks (0);

[0190] Field name (CREATE_TIME), field description (creation time), type (date), nullable (none), remarks (none);

[0191] Field name (CREATE_USER), field description (creator), type (varchar2(64)), whether null (none), remarks (none);

[0192] Field name (UPDATE_TIME), field description (update time), type (date), nullable (none), remarks (none);

[0193] Field name (UPDATE_USER), field description (updator), type (varchar2(64)), whether null (none), remarks (none);

[0194] Field name (IS_COVER_BY_ORIGINAL), Field description (whether to cover (whether to disallow downloading resources from mns003), 0-no, 1-yes), Type (number(1)), Whether to be empty (none), Remarks (default value: 1);

[0195] Field name (CDN_WHITEKEY), field description (whitelist keyword), type (varchar2(200)), whether it is null (none), remarks (none).

[0196] In this application, XXX_MINI_CDN_VERSION (micro-application CDN version table; information needs to be saved to the micro-application CDN version table each time a micro-application public beta package is released).

[0197] Example:

[0198] Field name (APP_ID), field description (application ID), type (varchar2(50)), whether it is null (Notnull), remarks (none);

[0199] Field name (CDN_VERSION), field description (CDN resource version number), type (varchar2(30)), whether it is null (Not null), remarks (none);

[0200] Field name (CDN_RES_URL), field description (CDN resource file path), type (varchar2(150)), whether null (none), remarks (none);

[0201] Field name (CDN_MD5), field description (resource MD5), type (varchar2(128)), whether null (none), remarks (none);

[0202] Field name (REMARK1), field description (alternate field 1), type (varchar2(200)), whether nullable (none), remarks (none);

[0203] Field name (REMARK2), field description (alternate field 2), type (varchar2(200)), nullability (none), remarks (none);

[0204] Field name (REMARK3), field description (alternate field 3), type (varchar2(200)), nullability (none), remarks (none);

[0205] Field name (CREATE_TIME), field description (creation time), type (date), nullable (none), remarks (none);

[0206] Field name (CREATE_USER), field description (creator), type (varchar2(64)), whether null (none), remarks (none);

[0207] Field name (UPDATE_TIME), field description (update time), type (date), nullable (none), remarks (none);

[0208] Field name (UPDATE_USER), field description (updator), type (varchar2(64)), whether null (none), remarks (none);

[0209] Field name (AES_ID), field description (id of micro-application zip key table), type (number(20)), whether empty (none), remarks (none);

[0210] Field name (IS_TIMER_FETCH), field description (whether it has been preheated 0 no 1 yes default no), type (number(1)), whether it is empty (none), remarks (default value: 0);

[0211] Field name (TIMER_FETCH_COUNT), field description (number of preheating cycles), type (number(5)), whether null (none), remarks (default value: 0);

[0212] Field name (IS_CDN_DELETE), Field description (whether to delete, 0-no, 1-yes), Type (number(1)), Whether empty (none), Remarks (default value: 0).

[0213] In this application, XXX_MINI_CDN_LOGO (a micro-application CDN LOGO table used to store the logo information of micro-applications).

[0214] Example:

[0215] Field name (APP_ID), field description (application ID), type (varchar2(50)), whether it is null (Notnull), remarks (none);

[0216] Field name (CDN_VERSION), field description (CDN resource version number), type (varchar2(30)), whether it is null (Not null), remarks (none);

[0217] Field name (CDN_LOGO_URL), field description (CDN application logo path), type (varchar2(150)), whether null (none), remarks (none);

[0218] Field name (REMARK1), field description (alternate field 1), type (varchar2(200)), whether nullable (none), remarks (none);

[0219] Field name (REMARK2), field description (alternate field 2), type (varchar2(200)), nullability (none), remarks (none);

[0220] Field name (REMARK3), field description (alternate field 3), type (varchar2(200)), whether nullable (none), remarks (none);

[0221] Field name (CREATE_TIME), field description (creation time), type (date), nullable (none), remarks (none);

[0222] Field name (CREATE_USER), field description (creator), type (varchar2(64)), whether null (none), remarks (none);

[0223] Field name (UPDATE_TIME), field description (update time), type (date), nullable (none), remarks (none);

[0224] Field name (UPDATE_USER), field description (updator), type (varchar2(64)), whether null (none), remarks (none).

[0225] In this application, XXX_MINI_SECURITY_APPLY is a CDN encrypted resource package AES_KEY storage table. The resource package is encrypted, and AES encryption and decryption key information is stored according to different versions.

[0226] Example:

[0227] Field name (ID), field description (primary key id), type (number(20)), whether it is null (Not null), remarks (none);

[0228] Field name (APP_ID), field description (micro-application number), type (varchar2(50)), whether it is null (none), remarks (none);

[0229] Field name (APP_SECRET_KEY), Field description (AES algorithm key used for encryption of micro application resource package), Type (varchar2(64)), Whether it is empty (none), Remarks (none);

[0230] Field name (KEY_VERSION), field description (version of the first resource package using this key), type (varchar2(30)), whether it is null (none), remarks (none);

[0231] Field name (KEY_VERSION), field description (version of the first resource package using this key), type (varchar2(30)), whether it is null (none), remarks (none);

[0232] Field name (CREATE_TIME), field description (creation time), type (date), nullable (none), remarks (none);

[0233] Field name (UPDATE_TIME), field description (update time), type (date), nullable (none), remarks (none);

[0234] Field name (REMARK1), field description (alternate field 1), type (varchar2(200)), whether nullable (none), remarks (none);

[0235] Field name (REMARK2), field description (alternate field 2), type (varchar2(200)), nullability (none), remarks (none);

[0236] Field name (REMARK3), Field description (alternate field 3), Type (varchar2(200)), Whether null (none), Remarks (none).

[0237] In this application, XXX_MINI_CDN_CALL_RECORD is the CDN service provider interface call record table.

[0238] Example:

[0239] Field name (ID), field description (primary key id), type (number(20)), whether it is null (Not null), remarks (none);

[0240] Field name (CODE), field description (CDN return status code), type (varchar2(64)), whether it is null (none), remarks (none);

[0241] Field name (MESSAGE), field description (CDN returned message), type (varchar2(1000)), whether nullable (none), remarks (none);

[0242] Field name (CREATE_TIME), field description (creation time), type (date), nullable (none), remarks (none);

[0243] Field name (PUSH_TYPE), field description (request URL type (yure, shuaxin)), type (varchar2(50)), whether empty (none), remarks (none);

[0244] Field name (URL_TYPE), field description (push type (zip, logo)), type (varchar2(50)), whether empty (none), remarks (none);

[0245] Field name (CDN_SERVICE_PROVIDER), field description (accelerated domain name service provider), type (varchar2(50)), whether it is empty (none), remarks (none);

[0246] Field name (APP_ID), field description (micro-application ID), type (varchar2(50)), whether it is null (none), remarks (none);

[0247] Field name (REMARK1), field description (alternate field 1), type (varchar2(200)), whether nullable (none), remarks (none);

[0248] Field name (REMARK2), field description (alternate field 2), type (varchar2(200)), nullability (none), remarks (none);

[0249] Field name (REMARK3), Field description (alternate field 3), Type (varchar2(200)), Whether null (none), Remarks (none).

[0250] For the usability design of this application, an example is:

[0251] This application embodiment takes into account that the resource package is downloaded from the CDN vendor node, which creates a dependency on a third party. Although the failure probability of CDN is very low, once the third-party system is unstable, it will directly affect the business and affect the system availability. Therefore, the availability goal is achieved from the perspectives of CDN availability detection, CDN emergency switch, client download backup, and primary / backup switching.

[0252] CDN emergency switch:

[0253] Add a server-side configuration parameter: a global switch for CDN downloads. In extremely urgent situations, modifying this global switch will prevent the server interface from returning CDN-related download information. This forces clients to download resources via the transaction interface instead of the CDN. The resulting impact on the bandwidth consumption of micro-application systems is significant.

[0254] Client download backup:

[0255] If downloading from the CDN fails or authentication fails, the client will not download from the transaction interface. If the error is caused by a non-CDN authentication failure, the client will re-download from the transaction interface.

[0256] Primary / backup failover (using only one accelerated domain):

[0257] For example, the implementing entity officially deploys resources to H based on market share principles, with K serving as a backup. Resource releases are pushed to both vendors simultaneously to prevent excessive backhaul traffic. Client access traffic primarily goes through A, with B acting as a resource backup. If a resource download failure is detected or received at A, a switchover process is required. If the failure is resolved, no switchover occurs.

[0258] Before the switch, the execution entity will proactively warm up all micro-applications. Warm-up will be done in batches, with no more than 100 applications at a time. The reason for proactive warm-up is that although the public beta package (i.e., resource package) undergoes dual-vendor warm-up for each release, resources that have exceeded the cache time and have no access will automatically expire, preventing excessive back-to-origin traffic after the switch.

[0259] During the switchover process, the network will manually switch the accelerated domain name mb1.mp.xxx.com from ACNAME to BCNAME. The encrypted string https: / / mb1.mp.xxx.com / mp / statics / resourcepack.zip?sign=xxxxx will be parsed and globally load balanced by B.

[0260] During the switchover, the configuration parameter (update cycle) was adjusted from 30 minutes to 90 minutes to ensure that client micro-applications use local versions as much as possible. At the same time, the configuration parameter (CDN global switch) was switched back from 1 to 0, temporarily closing the CDN download channel and resuming resource downloads.

[0261] After the primary / standby switchover, the configuration parameters were adjusted to 30 minutes and the CDN switch was turned on again.

[0262] To maintain compatibility with older client versions, the server needs to retain the original transactions related to the downloaded resource packages, and the relevant resource packages still need to be saved in the original storage directory.

[0263] The beneficial effects of this application's embodiments are as follows: Improved user access speed for micro-applications: After using CDN, the average access speed nationwide is 5.76MB / s; before using CDN, the average download speed nationwide was 590KB / s. Reduced bandwidth costs: While ensuring optimal access performance, using CDN minimizes bandwidth and manpower maintenance costs. Hiding the origin server and enhancing its anti-attack capabilities: Due to the CDN's ability to hide the origin server's real IP address and its inherent anti-attack capabilities, the security of the origin server is significantly improved after using CDN. Reduced origin server pressure: After using CDN, a large site with a peak bandwidth of around 100Gbps only needs to maintain an origin server with a peak bandwidth of around 1-2Gbps.

[0264] This application embodiment utilizes CDN access for micro-application resource downloads: Micro-application resource packages from mobile banking channels are switched from the internal NAS to an internet CDN, and can be switched back to the original transaction mode for download via a global CDN switch. Anti-leeching employs different strategies for different types of micro-application resources: because different types of micro-application resources have different security level requirements—for example, images have lower sensitivity while resource packages have higher sensitivity—the client constructs the download URL for images, while the server generates and returns the download URL for resource packages based on a timestamp algorithm. Simultaneously, the vendor's nodes are configured to verify the URL validity of resource packages, but not for image types. High availability of primary and backup CDNs: By using system-wide parameters configured by the CDN provider to control various business logic points, a means is provided to switch to a backup CDN after a primary CDN failure. Furthermore, during the transition period, the original transaction mode (i.e., the resource acquisition (download) mode without CDN nodes) ensures the download availability of micro-applications. Timer-based proactive preheating of new micro-application versions: The business logic for releasing a new version of a mobile micro-application remains unchanged. The preheating logic is decoupled into a timer, which uniformly calls the server's external preheating interface. This connects the online AP in the open zone to the DMZ Apache configured with `resolve.conf`, enabling access to Alibaba Cloud or Wangsu's RESTful interfaces. This resolves the issue of excessive bandwidth pressure on the first access back to the origin server. Dual-stack support for origin server access: Modifications have been made based on both IPv4 and IPv6 networks, allowing customers to access the micro-application via CDN acceleration in both stacked environments. Whitelist-controlled CDN acceleration: A whitelist approach is used for certain micro-applications, allowing some whitelisted users to use CDN, while other users use the original transaction. CDN acceleration is tested in a phased manner, and then fully implemented after verification. Soft link mode and real path mode for downloading and accessing URLs: Using real path download access exposes the resource storage path on the NAS, leaving a vulnerability for malicious actors. MD5 encryption is applied to the CDN path information, and soft links are created to make the download access URL more secure.

[0265] Figure 4 This is a schematic diagram of the main units of a resource acquisition device according to an embodiment of this application. Figure 4 As shown, the resource acquisition device includes a receiving unit 401, a verification unit 402, a resource packet acquisition unit 403, and a parsing unit 404.

[0266] The receiving unit 401 is configured to receive resource acquisition requests and then generate corresponding timestamp anti-leeching based on the resource acquisition requests.

[0267] Verification unit 402 is configured to locate the target content distribution node based on timestamp anti-leeching, and to call the target content distribution node to verify the resource acquisition request based on timestamp anti-leeching;

[0268] Resource package acquisition unit 403 is configured to, in response to determining that verification has failed and that a resource package update exists, call the target content distribution node to obtain the updated resource package;

[0269] Parsing unit 404 is configured to parse the updated resource package to obtain the target resource.

[0270] In some embodiments, the receiving unit is further configured to: determine the type of resource to be acquired based on the resource acquisition request; and generate a corresponding timestamp anti-leeching mechanism based on the type of resource to be acquired.

[0271] In some embodiments, the receiving unit 401 is further configured to: in response to determining that the type of the resource to be acquired is an image, acquire the content delivery network acceleration domain name and the resource storage file path corresponding to the resource acquisition request, and then concatenate the content delivery network acceleration domain name and the resource storage file path to generate a timestamp anti-leeching mechanism.

[0272] In some embodiments, the receiving unit 401 is further configured to: in response to determining that the type of the resource to be acquired is a resource package, acquire system parameters of the content distribution service; determine the corresponding resource acquisition encryption string based on the resource acquisition request; and invoke a timestamp algorithm to generate a corresponding timestamp anti-leeching based on the system parameters and the resource acquisition encryption string.

[0273] In some embodiments, the verification unit 402 is further configured to: determine the resource storage file path in the timestamp anti-leeching chain; determine the content distribution node corresponding to the resource storage file path based on the preset correspondence between the path and the content distribution node, and then determine the determined content distribution node as the target content distribution node.

[0274] In some embodiments, the verification unit 402 is further configured to: determine a preset expiration time in the timestamp anti-leeching chain; and return verification failure information in response to determining that the preset expiration time has arrived.

[0275] In some embodiments, the verification unit 402 is further configured to: determine the preset expiration time and verification code in the timestamp anti-leeching chain; and return verification failure information in response to determining that the preset expiration time has not been reached and the verification code is incorrect.

[0276] In some embodiments, the resource acquisition device further includes Figure 4 The request generation unit (not shown) is configured to: receive an application startup request and obtain the latest version identifier corresponding to the application; determine the local version identifier corresponding to the locally cached resource package, and then compare the latest version identifier with the local version identifier; in response to determining that the latest version identifier and the local version identifier are inconsistent, generate a corresponding resource acquisition request based on the latest version identifier.

[0277] In some embodiments, the resource package acquisition unit 403 is further configured to: determine the switch identifier of the content distribution service, the download identifier of the application to be opened, and the removal identifier; and trigger the resource package acquisition process in response to determining that the switch identifier is a first preset value, the download identifier is a second preset value, and the removal identifier is a third preset value.

[0278] In some embodiments, the resource package acquisition unit 403 is further configured to: acquire an application whitelist, and in response to determining that the application to be opened is in the whitelist, trigger a resource package acquisition process based on the content distribution service.

[0279] In some embodiments, the resource package acquisition unit 403 is further configured to: invoke a timer to invoke a preheating interface to preheat the updated resource package.

[0280] It should be noted that the resource acquisition method and resource acquisition device in this application are related in terms of specific implementation, so repeated content will not be described again.

[0281] Figure 5 An exemplary system architecture 500 is shown that can be applied to the resource acquisition method or resource acquisition apparatus of the embodiments of this application.

[0282] like Figure 5 As shown, system architecture 500 may include terminal devices 501, 502, and 503, a network 504, and a server 505. Network 504 serves as the medium for providing communication links between terminal devices 501, 502, and 503 and server 505. Network 504 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0283] Users can use terminal devices 501, 502, and 503 to interact with server 505 via network 504 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 501, 502, and 503, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0284] Terminal devices 501, 502, and 503 can be various electronic devices with resource acquisition and processing screens that support web browsing, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0285] Server 505 can be a server providing various services, such as a backend management server supporting resource acquisition requests submitted by users using terminal devices 501, 502, and 503 (for example only). The backend management server can receive resource acquisition requests and generate corresponding timestamp-based anti-leeching mechanisms; locate the target content distribution node based on the timestamp-based anti-leeching mechanism, and call the target content distribution node to verify the resource acquisition request based on the timestamp-based anti-leeching mechanism; in response to determining that verification fails and that a resource package has been updated, call the target content distribution node to obtain the updated resource package; and parse the updated resource package to obtain the target resource. This ensures that the latest resources can be obtained quickly and accurately.

[0286] It should be noted that the resource acquisition method provided in this application embodiment is generally executed by server 505, and correspondingly, the resource acquisition device is generally set in server 505.

[0287] It should be understood that Figure 5 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0288] The following is for reference. Figure 6 It shows a schematic diagram of the structure of a computer system 600 suitable for implementing a terminal device according to the embodiments of this application. Figure 6 The terminal device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0289] like Figure 6 As shown, the computer system 600 includes a central processing unit (CPU) 601, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 602 or programs loaded from storage section 608 into random access memory (RAM) 603. The RAM 603 also stores various programs and data required for the operation of the computer system 600. The CPU 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0290] The following components are connected to I / O interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to I / O interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 610 as needed so that computer programs read from it can be installed into storage section 608 as needed.

[0291] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 609, and / or installed from removable medium 611. When the computer program is executed by central processing unit (CPU) 601, it performs the functions defined above in the system of this application.

[0292] It should be noted that the computer-readable medium shown in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. Computer-readable storage media can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0293] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0294] The units described in the embodiments of this application can be implemented in software or hardware. The described units can also be housed in a processor; for example, a processor can be described as including a receiving unit, a verification unit, a resource packet acquisition unit, and a parsing unit. The names of these units do not necessarily limit the specific unit itself.

[0295] In another aspect, this application also provides a computer-readable medium, which may be included in the device described in the above embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more programs that, when executed by the device, cause the device to receive a resource acquisition request, generate a corresponding timestamp-based anti-leeching chain based on the resource acquisition request; locate a target content distribution node based on the timestamp-based anti-leeching chain, and invoke the target content distribution node to verify the resource acquisition request based on the timestamp-based anti-leeching chain; in response to determining that the verification failed and that a resource package update exists, invoke the target content distribution node to obtain the updated resource package; and parse the updated resource package to obtain the target resource.

[0296] According to the technical solution of the embodiments of this application, it is possible to ensure that the latest resources can be obtained quickly and accurately.

[0297] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.< / path> < / endtime> < / path>

Claims

1. A method for acquiring resources, characterized in that, include: A timer is invoked to preheat the updated resource package by calling the preheating interface. The version information table is queried to find resource packages whose preheating count is less than a preset count. If the preheating is successful, the preheating field corresponding to the corresponding resource package is set to the preset value. If the preheating fails, the preheating count corresponding to the corresponding resource package is increased. If the preheating count exceeds the preset count, the corresponding resource package is no longer preheated. A resource acquisition request is received, and a corresponding timestamp anti-hotlinking is generated based on the resource acquisition request. The step of generating a corresponding timestamp anti-leeching link based on the resource acquisition request includes: determining the type of the resource to be acquired based on the resource acquisition request; generating a corresponding timestamp anti-leeching link based on the type of the resource to be acquired; when the type of the resource to be acquired is an image, the generated timestamp anti-leeching link does not contain parameters related to URL validity verification; when the type of the resource to be acquired is a resource package, the generated timestamp anti-leeching link contains parameters related to URL validity verification. Based on the timestamp anti-leeching, the target content distribution node is located, and the target content distribution node is invoked to verify the resource acquisition request based on the timestamp anti-leeching. In response to the determination that the verification failed and that a resource package update exists, the target content distribution node is invoked to obtain the updated resource package; Parse the updated resource package to obtain the target resource.

2. The method according to claim 1, characterized in that, The step of generating a corresponding timestamp anti-leeching mechanism based on the type of the resource to be acquired includes: In response to determining that the type of the resource to be acquired is an image, the content delivery network acceleration domain name and the resource storage file path corresponding to the resource acquisition request are obtained, and then the content delivery network acceleration domain name and the resource storage file path are concatenated to generate a timestamp anti-hotlinking.

3. The method according to claim 1, characterized in that, The process of generating a corresponding timestamp-based anti-leeching mechanism based on the type of the resource to be acquired includes: In response to determining that the type of the resource to be acquired is a resource package, the system parameters of the content distribution service are obtained; Based on the resource acquisition request, determine the corresponding resource acquisition encryption string; The timestamp algorithm is invoked to generate a corresponding timestamp-based anti-leeching algorithm based on the encrypted string obtained from the system parameters and the resources.

4. The method according to claim 1, characterized in that, The method for locating the target content distribution node based on the timestamp anti-leeching includes: Determine the resource storage file path in the timestamp anti-leeching mechanism; Based on the preset correspondence between paths and content distribution nodes, the content distribution node corresponding to the resource storage file path is determined, and then the determined content distribution node is identified as the target content distribution node.

5. The method according to claim 1, characterized in that, The verification of the resource acquisition request includes: Determine the preset expiration time in the timestamp anti-leeching mechanism; Upon determining that the preset expiration time has been reached, a verification failure message is returned.

6. The method according to claim 1, characterized in that, The verification of the resource acquisition request includes: Determine the preset expiration time and verification code in the timestamp anti-leeching mechanism; In response to determining that the preset expiration time has not been reached and the verification code is incorrect, a verification failure message is returned.

7. The method according to claim 1, characterized in that, Before receiving the resource acquisition request, the method further includes: Receive the application startup request and obtain the latest version identifier of the application; Determine the local version identifier corresponding to the locally cached resource package, and then compare the latest version identifier with the local version identifier; In response to the determination that the latest version identifier is inconsistent with the local version identifier, a corresponding resource acquisition request is generated based on the latest version identifier.

8. The method according to claim 1, characterized in that, Before obtaining the updated resource package, the method further includes: Determine the on / off flag for the content distribution service, the download flag for the application to be launched, and the removal flag; In response to determining that the switch identifier is a first preset value, the download identifier is a second preset value, and the removal identifier is a third preset value, the resource package acquisition process is triggered.

9. The method according to claim 1, characterized in that, Before obtaining the updated resource package, the method further includes: Obtain the application whitelist. In response to determining that the application to be launched is in the whitelist, trigger the resource package acquisition process based on the content distribution service.

10. A resource acquisition device, characterized in that, include: The receiving unit is configured to invoke a timer to call a preheating interface to preheat updated resource packages. It queries a version information table for resource packages with a preheating count less than a preset count and preheats them. If preheating is successful, the preheating field corresponding to the resource package is set to a preset value. If preheating fails, the preheating count for the corresponding resource package is increased. If the preheating count exceeds the preset count, preheating of the corresponding resource package is stopped. The receiving unit receives resource acquisition requests and generates corresponding timestamp-based anti-leeching measures based on the resource acquisition requests. The receiving unit is further configured to determine the type of resource to be acquired based on the resource acquisition request. A corresponding timestamp-based anti-leeching link is generated based on the type of the resource to be acquired. When the type of the resource to be acquired is an image, the generated timestamp-based anti-leeching link does not contain parameters related to URL validity verification. When the type of the resource to be acquired is a resource package, the generated timestamp-based anti-leeching link contains parameters related to URL validity verification. The verification unit is configured to locate the target content distribution node based on the timestamp anti-leeching, and to call the target content distribution node to verify the resource acquisition request based on the timestamp anti-leeching. The resource package acquisition unit is configured to, in response to determining that the verification failed and that a resource package update exists, invoke the target content distribution node to obtain the updated resource package; The parsing unit is configured to parse the updated resource package to obtain the target resource.

11. A resource acquisition electronic device, characterized in that, include: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-9.

12. A computer-readable medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-9.

Images