WO2021228143A1 - 小程序启动方法、签名方法、装置、服务器及介质 - Google Patents

小程序启动方法、签名方法、装置、服务器及介质 Download PDF

Info

Publication number
WO2021228143A1
WO2021228143A1 PCT/CN2021/093358 CN2021093358W WO2021228143A1 WO 2021228143 A1 WO2021228143 A1 WO 2021228143A1 CN 2021093358 W CN2021093358 W CN 2021093358W WO 2021228143 A1 WO2021228143 A1 WO 2021228143A1
Authority
WO
WIPO (PCT)
Prior art keywords
target
package
applet
offline
signature
Prior art date
Application number
PCT/CN2021/093358
Other languages
English (en)
French (fr)
Inventor
祝威
Original Assignee
支付宝(杭州)信息技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 支付宝(杭州)信息技术有限公司 filed Critical 支付宝(杭州)信息技术有限公司
Publication of WO2021228143A1 publication Critical patent/WO2021228143A1/zh

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12Protecting executable software
    • G06F21/121Restricting unauthorised execution of programs
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/445Program loading or initiating
    • G06F9/44568Immediately runnable code

Definitions

  • the embodiments of this specification relate to the field of computer technology, and in particular to a method for starting an applet, a method for signing, a device, a server, and a medium.
  • Mini programs as an application that can be used without installation, have been widely used. Users can open the application by scanning or searching for the mini program without installing and uninstalling, which greatly meets the needs of users.
  • the embodiments of this specification provide a method for starting an applet, a method for signing, a device, a server, and a medium.
  • an embodiment of this specification provides a method for starting an applet, including: when an operation to start a target applet is detected, requesting an applet server to download an offline package of the target applet, in the offline package Including the signature file corresponding to the target applet and the data package of the target applet; obtaining the public key corresponding to the target applet; verifying the signature file based on the public key and the data package When the verification result is passed, the offline package is loaded to start the target applet.
  • the embodiment of this specification provides a method for signing an offline package of an applet, which is applied to an applet server, including: when a signature request for an offline package of a target applet is received, determining the target applet corresponding to the target applet A private key; based on the private key, a signature file corresponding to the target applet is generated; upon receiving a download request for the offline package of the target applet sent by the terminal device, the offline package is sent to the For the terminal device, the offline package includes the signature file and the data package of the target applet.
  • the embodiment of this specification provides an apparatus for launching an applet, which is applied to a terminal device.
  • the apparatus includes: a first acquisition module for requesting the applet server when an operation to start the target applet is detected Download the offline package of the target applet, the offline package includes the signature file corresponding to the target applet and the data package of the target applet; the second acquisition module is used to acquire the corresponding target applet
  • the signature verification module is used to verify the signature file based on the public key and the data packet to obtain the verification result; the activation module is used to verify the signature when the verification result is passed When, load the offline package to start the target applet.
  • an embodiment of this specification provides an offline package signing device for an applet, which is applied to an applet server, and includes: an acquisition module, which is used to determine when a signature request for an offline package of a target applet is received. The private key corresponding to the target applet; the signature module, which is used to generate a signature file corresponding to the target applet based on the private key; the offline package sending module, which is used to receive the target applet sent by the terminal device Sending the offline package to the terminal device when requesting the download of the offline package, and the offline package includes the signature file and the data package of the target applet.
  • an embodiment of the present specification provides an electronic device including a memory, a processor, and a computer program stored in the memory and capable of running on the processor, and the processor executes the steps of the above-mentioned small program startup method.
  • an embodiment of this specification provides a server, including a memory, a processor, and a computer program stored on the memory and capable of running on the processor, and the processor executes the steps of the above-mentioned mini program offline package signing method.
  • the embodiments of this specification provide a computer-readable storage medium on which a computer program is stored, and when the program is executed by a processor, the steps of any one of the above-mentioned methods are implemented.
  • the method provided in the embodiments of this specification downloads the offline package of the target applet on the applet server when the operation of starting the target applet is detected, and the offline package includes the corresponding target applet
  • the offline package includes the corresponding target applet
  • the public key of the target applet is obtained, and the signature file is verified based on the public key and the data package.
  • the offline package is loaded to start the target applet.
  • FIG. 1 is a flowchart of a method for starting a small program according to the first aspect of the embodiments of this specification;
  • Figure 2 is an interaction diagram of a method for starting a small program provided by an embodiment of the specification
  • FIG. 3 is a flowchart of a method for signing offline packages of small programs provided by the second aspect of the embodiments of this specification;
  • FIG. 5 is a schematic diagram of an offline package signing device for small programs provided by the fourth aspect of the embodiments of this specification.
  • Fig. 6 is a schematic diagram of a server provided by the sixth aspect of the embodiments of this specification.
  • the development, release, and use of the applet involves interactions between multiple platforms and devices, including but not limited to the applet development platform, the applet server, and user terminal devices.
  • the applet development platform is used by applet developers to develop the applet and generate the offline package of the applet. After the applet development is completed, the applet development platform uploads the offline package of the developed applet to the applet On the server side, when the user runs the applet in the terminal device, the startup and function realization of the applet can be completed through the interaction between the terminal device and the applet server.
  • the embodiments of this specification provide a method for starting a small program, which is applied to terminal devices, such as user's mobile phones, tablet computers, and other electronic devices.
  • terminal devices such as user's mobile phones, tablet computers, and other electronic devices.
  • Fig. 1 it is a flowchart of a method for starting an applet provided by an embodiment of this specification.
  • the method includes the following steps: Step S12: When an operation to start a target applet is detected, request a download from the applet server
  • the offline package of the target applet the offline package includes the signature file corresponding to the target applet and the data packet of the target applet
  • Step S14 Obtain the public key corresponding to the target applet
  • Step S16 Based on the public key and the data packet, The signature file is verified to obtain a verification result
  • Step S18 When the verification result is that the verification is passed, the offline package is loaded to start the target applet.
  • the target application is installed in the user's terminal device, and the applet can be connected to the target application. That is, when the user starts the applet, first open the target application, and then use the scan function and search function of the target application , Or click the icon of the applet on the target application to start the applet.
  • the target applet can be any applet that is connected to the target application.
  • the target operation can be any of the above operations of starting the applet.
  • the terminal device After detecting the target operation, the terminal device sends an offline package download request to the applet server. After receiving the offline package download request for the target applet sent by the terminal device, the program server returns the offline package of the target applet to the terminal device.
  • the offline package is the complete package of the mini program.
  • the code and resources of the applet can be subpackaged to construct a main package and N subpackages, where N is a positive integer.
  • the data in the main package includes the default startup page, TabBar page, public resources that all sub-packages need, JS scripts, etc.
  • the sub-packages can be divided according to the developer’s configuration, or according to the applet server. The rules of program subcontracting are divided.
  • the terminal device when the offline package of the applet has a sub-package structure, the terminal device will first request the applet server to download the main package and start the page in the main package. When the user needs to enter a page of the sub-package , The terminal device will request to download the corresponding subpackage, and display the page after the download is complete.
  • the signature file of the target applet is generated.
  • a signature file can be generated.
  • the main package and each sub-package generate corresponding signature files.
  • the data signature file may be obtained by signing the digest information of the binary stream data of the offline package of the target applet through the private key.
  • the offline package also includes data package, version information and other data.
  • the data package contains compressed corresponding page data.
  • the version information can be the version information of the target application accessed by the applet, and the target application of different versions .
  • the types of offline packages that support loading can be different. For example, the old version of the target application supports the loading of the complete package, and the new version of the target application supports the loading of the main package and sub-packages.
  • the offline package can be regarded as the product of compressing the compressed package, version information and signature file of the online page of the applet into a zip package.
  • the terminal device After downloading the offline package of the target applet, the terminal device verifies the signature file in the offline package according to the obtained public key.
  • the public key may be obtained by the terminal device upon request from the applet server, or it may be obtained by integrating the public key into the target application that accesses the target applet, and it is not limited here.
  • the signature file is verified according to the public key and the data package.
  • the offline package is decompressed and the decompressed data is loaded and rendered, and the startup page contained in the data package is displayed to achieve the goal The startup process of the applet.
  • the solution in the embodiment of this specification can effectively ensure the security of the offline package by verifying the signature file of the offline package, and prevent others from tampering with the offline package.
  • the offline package of the sub-package structure to start the applet . Since only the main package needs to be downloaded at startup, the size of the offline resource package of the applet is greatly reduced, the download speed has been improved, and the success rate of the download is improved, and the effect of the applet’s startup interface can be opened in seconds.
  • step S12 can be implemented in the following way: receiving the public key sent by the target site corresponding to the target applet, the public key is that when the target site enters the applet server, the applet server assigns the target site Public-private key pair, and the public key in the public-private key pair is sent to the target site.
  • the target application that accesses the target applet there may be a corresponding site.
  • the target application as payment application A as an example, if payment application A can be used in multiple countries, for each country, Both can be set with a site corresponding to payment application A, for example, for payment application A in the China region, there is a corresponding Chinese site, and for payment application A in the Indian region, there is a corresponding Indian site.
  • the Chinese site corresponds to the applet server of the Chinese region
  • the Indian site corresponds to the applet server of the Indian region.
  • the sites can also correspond to the same applet server, which is not limited here.
  • the applet server When the site is hosted on the corresponding applet server, the applet server allocates a set of public and private key pairs for the site. The public key is fed back to the site, and the private key is saved on the applet server for subsequent use The generation of the signature file. It should be understood that for applets that access the target application, the public key allocated by the applet server for the site can be used for signing. Of course, for different applets, the applet server can also be Each applet is assigned its own public and private key pair, so that each applet can sign according to its own public key, which is not limited here.
  • the applet server Take the applet server to assign a public-private key pair to the target site corresponding to the target applet as an example.
  • the public key can be integrated into the target application.
  • the terminal device downloads the target application, the user opens the target When the application runs the target applet, the public key can be obtained through the target application.
  • the target site sends the public key to the target application on the terminal device, so that the target applet uses the public key for signature verification during the running process.
  • the terminal device uses the public key to verify the offline package of the target applet.
  • the verification process can be implemented in the following way: signing based on the public key
  • the file is decrypted to obtain the first summary information;
  • the binary stream data of the offline package is obtained according to the path of the data packet;
  • the binary stream data of the offline package is abstracted based on the digest extraction method corresponding to the signature file to obtain the second summary information ;
  • the verification result is determined by comparing the first summary information with the second summary information, wherein, when the first summary information is the same as the second summary information, the verification result is the verification passed.
  • the verification result is that the verification fails. At this time, you can request to download the offline package again, or do nothing, and return risk information such as the offline package being tampered with.
  • the offline package of the target applet contains at least a signature file and a data packet.
  • the signature file is generated, the binary stream data of the offline package of the target applet is first extracted, such as through SHA-1 (Secure Hash Algorithm 1, Secure Hash Algorithm 1) Calculate the digest information, and then use the private key to sign the digest information to generate a signature file.
  • SHA-1 Secure Hash Algorithm 1, Secure Hash Algorithm 1
  • this description says that in the embodiment, after the offline package is obtained, the signature file is decrypted with the public key to obtain the first summary information, and then the data package is read through the storage path The binary stream data of the offline package is extracted and the binary stream data of the offline package is digested by the digest extraction method used in the signing process to obtain the second summary information. If the first summary information is the same as the second summary information, the verification is passed, indicating that the offline package is safe and has not been tampered with. If the first summary information is different from the second summary information, the signature verification fails, indicating that the offline package has been tampered with and is insecure.
  • the signature file in order to ensure the integrity of the content of the signature file during the transmission process, after the signature file is generated by the private key, the signature file can be encoded according to a preset encoding method, for example, the encoding is performed by the Base64 encoding method.
  • the latter signature file is packaged into the offline package as the final signature file in the offline package. Therefore, in the embodiments of this specification, when verifying the offline package of the target applet, the verification can be performed according to the following method: according to the decoding method corresponding to the preset encoding method, the signature file is decoded to obtain the decoded Signature file; based on the public key and data packet, the decoded signature file is verified and the verification result is obtained.
  • the signature file is extracted from the offline package, and then the signature file is decrypted.
  • the signature file is a file obtained through Base64 encoding
  • the signature file is Perform Base64 decoding to obtain the decoded and decoded signature file, and then use the public key to verify the decoded signature file.
  • the offline package of the target applet may be constructed in the form of a main package plus sub-packages. Specifically, divide all the code and resources of the target applet into different packages. Among them, the main package contains the default startup page, TabBar page, public resources and JS scripts that all sub-packages need to use, and sub-packages Divide according to the configuration of the developer, or according to the rules for subcontracting the applet by the applet server.
  • the main package When starting the target applet, the main package will be downloaded first, and the page in the main package will be loaded. When entering a page in the sub-package, the corresponding sub-package will be downloaded and displayed.
  • the following principles can be followed: if the small program developer performs the sub-package configuration, it will be packaged according to the path of the developer’s sub-package configuration, and the directories outside the sub-package configuration path will be packaged to the main by default.
  • subcontracting can refer to resources in the main package and its own package; subcontracting and main package are packaged separately, and the same js module will exist in the main package and subcontracting separately.
  • the limit on the size of sub-packages can be set according to actual needs. For example, the size of all sub-packages of the entire applet does not exceed 4MB, and the size of a single sub-package or main package does not exceed 2MB.
  • step S11 specifically includes: Request to download the main package of the target applet.
  • the main package includes the main package signature file and the main package data package.
  • the main package data package contains the start page data of the target applet.
  • the offline package of the target applet is the main package plus sub-package structure
  • the main package of the target applet is downloaded on the applet server, and the main package of the target applet is downloaded according to the The main package signature file and the main package data package verify the main package. After the verification is passed, the startup page contained in the main package is loaded to realize the start of the target applet.
  • the target applet after the target applet is started through the main package, it also includes the following steps: when the operation to enter the target page is detected, request the applet server to download the target sub-package corresponding to the target page, and the target page is the same as the target applet.
  • the start page of the program is different from the page.
  • the target sub-package includes the sub-package signature file and the sub-package data package.
  • the sub-package data contains the data of the target page; based on the public key and the sub-package data package, the sub-package signature file is verified and signed, Obtain the sub-package verification result; when the sub-package verification result is passed, load the target page.
  • the user can click the icon or link corresponding to the target page on the start page to jump to the target page.
  • the target sub-package contains the sub-package signature file and the sub-package data package.
  • the sub-package signature file is verified by the public key. For the specific verification process, please refer to the previous description. I will not repeat it here.
  • the target After the sub-package verification is successful, load the target page in the target sub-package.
  • the signature file in the main package or sub-package may also be a file encoded by a preset encoding method.
  • each main package and sub-package has its own signature file, so that you can The signature file is checked to determine whether the main package or sub-package has been tampered with, ensuring the security of the offline package.
  • the target application as the wallet App as an example to describe the process of the mini program startup method.
  • Figure 2 is the mini program startup method for accessing the wallet App.
  • the wallet App is installed in the user’s terminal device and the container required for the target applet to run.
  • the container can be an H5 container, of course, other containers can also be used, here only To illustrate, not to limit.
  • the interactive process includes the following steps:
  • Step 001 The site corresponding to the wallet App enters the applet server
  • Step 002 The applet server calculates and generates the public-private key pair of the site
  • Step 003 The applet server sends the public key to the site
  • Step 004 The site sends the public key to the wallet App
  • Step 005 The user opens the wallet App
  • Step 006 The wallet App initializes the applet configuration and transfers the public key to the container;
  • Step 007 The user opens the target applet through the wallet App;
  • Step 008 The container requests the applet configuration from the applet server
  • Step 009 The applet server returns the applet configuration to the container
  • Step 010 The container requests to download the offline package of the target applet from the applet server;
  • Step 011 The applet server returns the offline package of the target applet
  • Step 012 Decompress the offline package of the target applet
  • Step 013 Read the signature file in the offline package
  • Step 014 Decode the signature file through Base64 to obtain the target signature data
  • Step 015 Use the data package, public key and target signature data in the offline package to verify and compare;
  • Step 016 If the verification is passed, load and render the data in the offline package
  • Step 017 Display data
  • Step 018 If the verification is passed but the data loading fails, the error page is returned to the wallet App;
  • Step 019 If the signature verification fails, the result of the signature verification failure is displayed to the user.
  • the applet configuration returned by the applet server includes the data package tar, the signature file CERT.json, and the version information manifest.xml. These three files are all included in the offline package. After decompressing the offline package , The above three files can be obtained, the signature file is verified by the public key, the verification result is obtained, and the page display is performed according to the verification result.
  • the whole process of development, release, and use of the applet involves the user, the applet development platform, the applet server, the international configuration push service center, the wallet App, and the container. Interactive.
  • mini program development process for accessing the wallet App is: mini program developers develop mini programs in the mini program development platform and generate offline packages; the mini program development platform judges whether the offline package size exceeds the limit, if offline If the package exceeds the limit, the applet developer is notified to subcontract the applet.
  • the applet development platform Compile the offline package that meets the restriction conditions, and generate a signature file according to the private key provided by the applet server; when the applet development platform compiles and assembles the offline package, the version information of the wallet App can be obtained, and the version information is the new version
  • the offline package is a sub-package structure, a signature file is generated for each main package and sub-package, and different packages are compiled and assembled; when the version information is the old version, the offline package is a complete package, and a signature file is generated for the complete package.
  • compile and assemble the complete package upload the compiled and assembled offline package (sub-package structure and/or complete package) to the applet server.
  • the applet server delivers the received offline package to the international configuration push service center for release.
  • the International Configuration Push Service Center delivers the offline package to the client of the Wallet App according to the version information, that is, when the version information is the new version, only the main package is delivered to the client, and when the version information is the old version, the complete offline package is delivered to the client Client, so that the client downloads the corresponding offline package.
  • the container loads the main package and verifies the signature file of the main package. When the verification is passed, the main package is loaded. If the package resource is loaded successfully, the page will be rendered and displayed to the user through the wallet App. If the page fails to load, the failed page will be displayed to the user; when the verification fails, the failed page will be displayed to the user.
  • the offline package is a complete package
  • the container loads the complete package and verifies the signature file of the complete package. When the verification is passed, the complete package resources are loaded. If the load is successful, the page is rendered and displayed to the user.
  • the page fails the failed page will be displayed to the user; when the verification fails, the failed page will be displayed to the user.
  • the container loads the sub-package corresponding to the page and verifies the sub-package signature file.
  • the sub-package resources are loaded. If the loading is successful, the page is rendered and displayed to the user. If the page fails to load, the failed page is displayed to the user; when the verification fails, the failed page is displayed to the user.
  • the solution in the embodiment of this specification can effectively ensure the security of the offline package by verifying the signature file of the offline package, and prevent others from tampering with the offline package.
  • the offline package start using the sub-package structure
  • the size of the offline resource package of the small program is greatly reduced, the download speed and the download success rate are improved, and the effect of the small program startup interface being opened in seconds.
  • the embodiment of this specification provides a method for signing an offline package of an applet, which is applied to an applet server.
  • FIG. 3 it is a flowchart of the method for signing an offline package of an applet. The method includes the following steps.
  • Step S32 When a signature request for the offline package of the target applet is received, determine the private key corresponding to the target applet; Step S34: Generate a signature file corresponding to the target applet based on the private key; Step S36: After receiving When the terminal device sends the download request of the offline package of the target applet, the offline package is sent to the terminal device, and the offline package includes the signature file and the data package of the target applet.
  • the applet developer develops the target applet on the applet development platform.
  • the signature file of the target applet needs to be generated.
  • the applet development platform can request and target the applet server. The private key corresponding to the applet.
  • the applet server can sign the offline package of the target applet according to the private key to obtain the signature file, or send the private key to the development platform to generate the signature file, here Not limited.
  • an offline package of the target applet is generated, and when the terminal device requests to download the offline package, the applet server sends the offline package to the terminal device.
  • the method further includes: when the request to enter the target site is received, the target The site allocates a public-private key pair, and the target site is the site corresponding to the target applet; the public key in the public-private key pair is sent to the target site.
  • an embodiment of this specification provides an apparatus for launching a small program, which is applied to a terminal device.
  • the offline package includes the signature file corresponding to the target applet and the data package of the target applet;
  • the second acquisition module 42 is used to acquire the target applet Corresponding public key;
  • verification module 43 used to verify the signature file based on the public key and data package, and obtain the verification result;
  • start module 44 used to load the offline package when the verification result is passed To start the target applet.
  • the second obtaining module 42 is configured to: receive the public key sent by the target site corresponding to the target applet, and the public key is used when the target site enters the applet server through the applet server. Allocate a public-private key pair to the target site, and send the public key in the public-private key pair to the target site.
  • the signature verification module 43 is used to: decrypt the signature file based on the public key to obtain the first summary information; obtain the binary stream data of the offline package according to the path of the data package; based on the signature file
  • the corresponding abstract extraction method is to extract the binary stream data of the offline package to obtain the second summary information; by comparing the first summary information with the second summary information, the verification result is determined.
  • the verification result is that the verification is passed.
  • the signature file is a file encoded by a preset encoding method
  • the signature verification module 43 is used to decode the signature file according to the decoding method corresponding to the preset encoding method to obtain the decoded file
  • the signature file based on the public key and the data packet, the decoded signature file is verified, and the verification result is obtained.
  • the target applet corresponds to multiple offline packages
  • the multiple offline packages are composed of a main package and N sub-packages, where N is a positive integer
  • the first acquisition module 41 is used to:
  • the server requests to download the main package of the target applet.
  • the main package includes the main package signature file and the main package data package.
  • the main package data package contains the start page data of the target applet.
  • the device further includes: a third acquisition module, configured to request the applet server to download the target subpackage corresponding to the target page when the operation to enter the target page is detected, and the target page is The start page of the target applet has different pages.
  • the target sub-package includes the sub-package signature file and the sub-package data package.
  • the sub-package data contains the data of the target page; the verification module is used based on the public key and the sub-package data package.
  • the sub-package signature file is checked to obtain the sub-package verification result; the page loading module is used to load the target page when the sub-package verification result is passed.
  • an embodiment of this specification provides an offline package signing device for a small program, which is applied to the small program server.
  • the private key corresponding to the target applet is determined;
  • the signature module 52 is used to generate a signature file corresponding to the target applet based on the private key;
  • the offline package sending module 53 is used to When the terminal device sends the download request of the offline package of the target applet, the offline package is sent to the terminal device, and the offline package includes the signature file and the data package of the target applet.
  • the device further includes: a processing module for allocating a public-private key pair to the target site when receiving the entry request of the target site, the target site is the site corresponding to the target applet; the public key is sent The module is used to send the public key in the public-private key pair to the target site.
  • the embodiment of this specification also provides an electronic device, including a memory, a processor, and a computer program stored on the memory and running on the processor, When the processor executes the program, the steps of starting the small program described above are realized.
  • an embodiment of this specification also provides a server, as shown in FIG. A computer program that can be run on the processor 402, and the processor 402 implements the steps of the above-mentioned offline package signature method for the small program when the processor 402 executes the program.
  • the bus architecture (represented by the bus 400), the bus 400 may include any number of interconnected buses and bridges, and the bus 400 will include one or more processors represented by the processor 402 and the memory 404 represented
  • the various circuits of the memory are linked together.
  • the bus 400 may also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, etc., which are all known in the art, and therefore, will not be further described herein.
  • the bus interface 406 provides an interface between the bus 400 and the receiver 401 and transmitter 403.
  • the receiver 401 and the transmitter 403 may be the same element, that is, a transceiver, which provides a unit for communicating with various other devices on the transmission medium.
  • the processor 402 is responsible for managing the bus 400 and general processing, and the memory 404 may be used to store data used by the processor 402 when performing operations.
  • the embodiments of this specification also provide a computer-readable storage medium on which a computer program is stored.
  • the processor executes, the steps of any one of the aforementioned method for starting the applet and the method for signing an offline package of the applet are implemented.
  • These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing equipment to work in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including the instruction device.
  • the device implements the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.
  • These computer program instructions can also be loaded on a computer or other programmable data processing equipment, so that a series of operation steps are executed on the computer or other programmable equipment to produce computer-implemented processing, so as to execute on the computer or other programmable equipment.
  • the instructions provide steps for implementing functions specified in a flow or multiple flows in the flowchart and/or a block or multiple blocks in the block diagram.

Abstract

本说明书实施例公开一种小程序启动方法、签名方法、装置、服务器及介质,在所述小程序启动方法中, 在启动目标小程序时, 向小程序服务器请求下载目标小程序的离线包,离线包中包括目标小程序对应的签名文件和数据包,基于目标小程序的公钥和数据包对签名文件进行验签,并在验签通过时, 加载离线包, 启动目标小程序。由于通过对离线包的签名文件进行验签, 能够有效保证离线包的安全性, 避免他人对离线包的篡改。

Description

小程序启动方法、签名方法、装置、服务器及介质 技术领域
本说明书实施例涉及计算机技术领域,尤其涉及一种小程序启动方法、签名方法、装置、服务器及介质。
背景技术
随着科学技术的不断发展以及用户需求的日渐增加,电子设备的功能越来越丰富。小程序,作为一种不需要安装即可使用的应用,已经得到了广泛使用,用户可以通过扫一扫或者搜索小程序即可打开应用,无需安装及卸载,大大满足了用户的需求。
发明内容
本说明书实施例提供一种小程序启动方法、签名方法、装置、服务器及介质。
第一方面,本说明书实施例提供一种小程序启动方法,包括:在检测到启动目标小程序的操作时,向小程序服务端请求下载所述目标小程序的离线包,所述离线包中包括与所述目标小程序对应的签名文件以及所述目标小程序的数据包;获取所述目标小程序对应的公钥;基于所述公钥以及所述数据包,对所述签名文件进行验签,获得验签结果;在所述验签结果为验签通过时,加载所述离线包,以启动所述目标小程序。
第二方面,本说明书实施例提供一种小程序离线包签名方法,应用于小程序服务端,包括:在接收到针对目标小程序离线包的签名请求时,确定与所述目标小程序对应的私钥;基于所述私钥,生成与所述目标小程序对应的签名文件;在接收到终端设备发送的所述目标小程序的离线包的下载请求时,将所述离线包发送给所述终端设备,所述离线包中包括所述签名文件以及所述目标小程序的数据包。
第三方面,本说明书实施例提供一种小程序启动装置,应用于终端设备,所述装置包括:第一获取模块,用于在检测到启动目标小程序的操作时,向小程序服务端请求下载所述目标小程序的离线包,所述离线包中包括与所述目标小程序对应的签名文件以及所述目标小程序的数据包;第二获取模块,用于获取所述目标小程序对应的公钥;验签模块,用于基于所述公钥以及所述数据包,对所述签名文件进行验签,获得验签结果;启动模块,用于在所述验签结果为验签通过时,加载所述离线包,以启动所述目标小程 序。
第四方面,本说明书实施例提供一种小程序离线包签名装置,应用于小程序服务端,包括:获取模块,用于在接收到针对目标小程序离线包的签名请求时,确定与所述目标小程序对应的私钥;签名模块,用于基于所述私钥,生成与所述目标小程序对应的签名文件;离线包发送模块,用于在接收到终端设备发送的所述目标小程序的离线包的下载请求时,将所述离线包发送给所述终端设备,所述离线包中包括所述签名文件以及所述目标小程序的数据包。
第五方面,本说明书实施例提供一种电子设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行上述小程序启动方法的步骤。
第六方面,本说明书实施例提供一种服务器,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行上述小程序离线包签名方法的步骤。
第七方面,本说明书实施例提供一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现上述任一项所述方法的步骤。
本说明书实施例有益效果如下:本说明书实施例提供的方法,在检测到启动目标小程序的操作时,在小程序服务端上下载目标小程序的离线包,离线包中包括目标小程序对应的签名文件和数据包,通过获取目标小程序的公钥,并基于公钥和数据包对签名文件进行验签,在验签通过时,加载离线包,以启动目标小程序。上述方案中,通过对离线包的签名文件进行验签,能够有效保证离线包的安全性,避免他人对离线包的篡改。
附图说明
通过阅读下文优选实施方式的详细描述,各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的,而并不认为是对本说明书的限制。而且在整个附图中,用相同的参考符号表示相同的部件。在附图中:
图1为本说明书实施例第一方面提供的一种小程序启动方法的流程图;
图2为本说明书实施例提供的一种小程序启动方法的交互图;
图3为本说明书实施例第二方面提供的一种小程序离线包签名方法的流程图;
图4为本说明书实施例第三方面提供的一种小程序启动装置的流程图;
图5为本说明书实施例第四方面提供的一种小程序离线包签名装置的示意图;
图6为本说明书实施例第六方面提供的服务器的示意图。
具体实施方式
为了更好的理解上述技术方案,下面通过附图以及具体实施例对本说明书实施例的技术方案做详细的说明,应当理解本说明书实施例以及实施例中的具体特征是对本说明书实施例技术方案的详细的说明,而不是对本说明书技术方案的限定,在不冲突的情况下,本说明书实施例以及实施例中的技术特征可以相互组合。
本说明书实施例中,小程序在开发、发布以及使用的过程中会涉及到多个平台及设备的交互,包括但不限于小程序开发平台、小程序服务端、用户终端设备。其中,小程序开发平台用于小程序开发者对小程序进行开发,生成小程序的离线包,在小程序开发完成后,小程序开发平台将开发完成后的小程序的离线包上传到小程序服务端,当用户在终端设备中运行小程序时,可以通过终端设备与小程序服务端之间的交互来完成小程序的启动和功能实现。
第一方面,本说明书实施例提供一种小程序启动方法,应用于终端设备中,例如用户的手机、平板电脑等电子设备中。如图1所示,为本说明书实施例提供的一种小程序启动方法的流程图,该方法包括以下步骤:步骤S12:在检测到启动目标小程序的操作时,向小程序服务端请求下载目标小程序的离线包,离线包中包括与目标小程序对应的签名文件以及目标小程序的数据包;步骤S14:获取目标小程序对应的公钥;步骤S16:基于公钥以及数据包,对签名文件进行验签,获得验签结果;步骤S18:在验签结果为验签通过时,加载离线包,以启动目标小程序。
本说明书实施例中,用户的终端设备中安装有目标应用,小程序可以接入目标应用中,即用户在启动小程序时,首先打开目标应用,然后通过目标应用的扫一扫功能、搜索功能、或者点击目标应用上的小程序的图标等操作来启动小程序。目标小程序可以是接入目标应用的任意小程序,目标操作可以是上述启动小程序操作中的任一操作,在检测到目标操作后,终端设备向小程序服务端发送离线包下载请求,小程序服务端在接收到终端设备发送的针对目标小程序的离线包下载请求后,将目标小程序的离线包返回至终端设备。
小程序在开发的过程中,可以将全部代码以及资源打包成一个完整包,此时,离线 包即为小程序的完整包,当用户在终端设备通过完整包运行小程序时,有可能会由于完整包过大,导致加载时间较长,终端设备会出现长较时间的白屏,当网络环境较差时,还会导致加载失败。因此,可以将小程序的代码和资源进行分包,构建一个主包以及N个分包,N为正整数。其中,主包中的数据包括放置默认启动页面、TabBar页面、所有分包都需要用到的公共资源、JS脚本等,分包可以根据开发者的配置进行划分,或者根据小程序服务端对小程序分包的规则进行划分。
本说明书实施例中,在小程序的离线包为分包结构时,终端设备会先向小程序服务端请求下载主包并启动主包内的页面,当用户需要进入分包的某个页面时,终端设备会请求下载对应的分包,下载完成后再进行该页面的展示。
为了确保离线包的安全性,本说明书实施例中,在开发目标小程序时,会生成目标小程序的签名文件,对于完整包来说,可以生成一个签名文件,对于分包结构来说,针对主包和每个分包,分别生成对应的签名文件。其中,数据签名文件可以是通过私钥对目标小程序离线包二进制流数据的摘要信息进行签名得到的。
另外,离线包除了签名文件,还包括数据包、版本信息等数据,数据包中包含有压缩的对应的页面数据,版本信息可以为小程序接入的目标应用的版本信息,不同版本的目标应用,支持加载的离线包类型可以不同,例如旧版本的目标应用支持完整包的加载,新版本的目标应用支持主包和分包的加载。也就是说,离线包可以看做是将小程序的在线页面的压缩包、版本信息和签名文件组合压缩成zip包的产物。
进一步的,终端设备在下载了目标小程序的离线包之后,根据获取到的公钥对离线包中的签名文件进行验签。公钥可以是终端设备向小程序服务端请求获取的,也可以是将公钥集成到接入目标小程序的目标应用中,通过目标应用得到的,这里不做限定。
根据公钥以及数据包对签名文件进行验签,当验签结果为验签通过时,将离线包进行解压并加载渲染解压后的数据,将数据包中包含的启动页面进行展示,以实现目标小程序的启动过程。
本说明书实施例中的方案,通过对离线包的签名文件进行验签,能够有效的保证离线包安全性,避免他人对离线包的篡改,另外,在采用分包结构的离线包启动小程序时,由于在启动时仅需要下载主包,大大减小了小程序离线资源包的大小,提高了下载速度已经下载成功率,能够实现小程序启动界面秒开的效果。
在具体实施过程中,步骤S12可以通过以下方式实现:接收与目标小程序对应的目 标站点发送的公钥,公钥为目标站点在入驻小程序服务端时,通过小程序服务端为目标站点分配公私钥对,并将公私钥对中的公钥发送给目标站点获得的。
本说明书实施例中,针对接入目标小程序的目标应用来说,可以对应有一个站点,以目标应用为支付应用A为例,若支付应用A可以在多个国家使用,对于每个国家,均可以设置有一个与支付应用A对应的站点,例如,对于中国区域的支付应用A,对应有中国站点,对于印度区域的支付应用A,对应有印度站点。对于不同的区域站点,还可以有各自的小程序服务端与之相对应,例如,中国站点对应有中国区域的小程序服务端,印度站点对应有印度区域的小程序服务端,当然,不同区域的站点也可以均对应同一个小程序服务端,这里不做限定。
当站点在入驻对应的小程序服务端时,小程序服务端为该站点分配一组公私钥对,其中,将公钥反馈至该站点,将私钥保存在小程序服务端上并用于后续的签名文件的生成。应理解的是,对于接入目标应用的小程序来说,均可以使用小程序服务端为站点分配的公钥进行签名操作,当然,对于不同的小程序来说,小程序服务端还可以为每个小程序分配各自的公私钥对,以使每个小程序根据各自的公钥进行签名,这里不做限定。
以小程序服务端为目标小程序对应的目标站点分配公私钥对为例,在目标站点接收到公钥之后,可以将公钥集成在目标应用中,当终端设备下载目标应用后,用户打开目标应用运行目标小程序时,可以通过目标应用获取到公钥。或者,目标站点在接收到小程序服务端发送的公钥后,将公钥发送给终端设备上的目标应用,以使目标小程序在运行过程中使用该公钥进行验签。
进一步的,终端设备在下载了目标小程序的离线包之后,使用公钥对目标小程序的离线包进行验签,在具体实施过程中,验签过程可以通过以下方式实现:基于公钥对签名文件进行解密处理,得到第一摘要信息;根据数据包的路径,获取离线包的二进制流数据;基于签名文件对应的摘要提取方式,对离线包的二进制流数据进行摘要提取,得到第二摘要信息;通过将第一摘要信息与第二摘要信息进行比对,确定验签结果,其中,在第一摘要信息与第二摘要信息相同时,验签结果为验签通过。在第一摘要信息与第二摘要信息不相同时,验签结果为验签未通过,此时,可以重新请求下载离线包,也可以不进行任何操作,并返回离线包被篡改等风险信息。
具体来讲,目标小程序的离线包至少包含有签名文件以及数据包,其中,在生成签名文件时,首先对目标小程序的离线包二进制流数据进行摘要提取,如通过SHA-1(Secure Hash Algorithm 1,安全散列算法1)计算出摘要信息,然后利用私钥对摘要信 息进行签名,生成签名文件。
为了确保下载的离线包未被篡改,本说明说实施例中,在获取到离线包之后,通过公钥对签名文件进行解密,得到第一摘要信息,然后,通过数据包的存储路径,读取离线包的二进制流数据,并采用签名过程中使用的摘要提取方式对离线包的二进制流数据进行摘要提取,得到第二摘要信息。若第一摘要信息与第二摘要信息相同,则验签通过,表明离线包是安全的,未被篡改过的。若第一摘要信息与第二摘要信息不同,则验签失败,表明离线包被篡改过,是不安全的。
本说明书实施例中,为了保证传输过程中签名文件内容的完整性,在通过私钥生成签名文件之后,可以对该签名文件按照预设编码方式编码,例如,通过Base64编码方式进行编码,将编码后的签名文件打包到离线包中,作为离线包中的最终签名文件。因此,本说明书实施例中,在对目标小程序的离线包进行验签时,可以根据以下方式进行验签:根据与预设编码方式对应的解码方式,对签名文件进行解码,得到解码后的签名文件;基于公钥以及数据包,对解码后的签名文件进行验签,获得验签结果。
在具体实施过程中,在获取到目标小程序的离线包之后,在离线包中提取出签名文件,然后对签名文件进行解密,例如,如果签名文件为经过Base64编码得到的文件,则对签名文件进行Base64解码,得到解码后的解码后的签名文件,然后再利用公钥对解码后的签名文件进行验签,具体的验签过程可参考上述描述,这里就不再赘述了。
本说明书实施例中,为了能够快速启动目标小程序,可以将目标小程序的离线包构建为主包加分包的形式。具体来讲,将目标小程序的全部代码和资源划分到不同的包中,其中,主包中放置默认启动页面、TabBar页面、所有分包都需要用到的公共资源、JS脚本等,分包根据开发者的配置进行划分,或者根据小程序服务端对小程序分包的规则进行划分。在启动目标小程序时,会先下载主包,加载主包内页面,当进入分包内某个页面时,才会将对应的分包下载并进行展示。
对于主包和分包的构建,可以遵循以下原则:如果是小程序开发者进行分包配置,则按照开发者分包配置的路径进行打包,分包配置路径外的目录将被默认打包到主包中;启动页面和TabBar的所有页面均需要放在主包中;每个分包的根目录不能是其他分包内的子目录;分包之间不能相互引用对方包中的资源(比如图片和js脚本等),分包可以引用主包和自己包内的资源;分包和主包是分别独立打包的,同一个js模块会在主包和分包中分别存在。
对于分包大小的限制可以根据实际需要进行设定,例如,整个小程序的所有分包大小不超过4MB,单个分包或主包大小不超过2MB。
因此,本说明书实施例中,当目标小程序对应多个离线包,多个离线包由一个主包和N个分包构成时(N为正整数),步骤S11具体包括:向小程序服务端请求下载目标小程序的主包,主包包括主包签名文件以及主包数据包,主包数据包中包含有目标小程序的启动页面数据。
具体来讲,当目标小程序的离线包为主包加分包结构时,在检测到启动目标小程序的操作后,在小程序服务端下载目标小程序的主包,并根据主包中的主包签名文件以及主包数据包对主包进行验签,在验签通过后,对主包中包含的启动页面进行加载,以实现目标小程序的启动。
进一步的,在通过主包启动目标小程序之后,还包括以下步骤:在检测到进入目标页面的操作时,向小程序服务端请求下载与目标页面对应的目标分包,目标页面为与目标小程序的启动页面不同的页面,目标分包包括分包签名文件以及分包数据包,分包数据包含有目标页面的数据;基于公钥以及分包数据包,对分包签名文件进行验签,获得分包验签结果;在分包验签结果为验签通过时,加载目标页面。
具体来讲,当主包的启动页面加载成功后,用户可以通过点击启动页面上的目标页面对应的图标或链接,跳转到目标页面,此时,向小程序服务端下载目标页面所在的目标分包,其中,目标分包包含有分包签名文件以及分包数据包,通过公钥对分包签名文件进行验签,具体的验签过程可以参考之前的描述,这里不再赘述了,当目标分包验签成功后,加载目标分包中的目标页面。另外,为了保证主包或分包在传输过程的完整性,对于主包或分包中的签名文件,也可以是经过预设编码方式编码后的文件。
综上,本说明书实施例中的方案,当目标小程序的离线包为主包加分包结构时,针对每个主包和分包,均有各自的签名文件,这样就可以通过对每个签名文件进行验签,来判断该主包或分包是否被篡改,确保了离线包的安全性。
为了更好的理解本说明书实施例中的小程序启动方法,以目标应用为钱包App为例,对小程序启动方法的流程进行说明,请参考图2,为接入钱包App的小程序启动方法的交互图,在该交互过程中,用户的终端设备中安装有钱包App,以及目标小程序运行所需要的容器,该实施例中,容器可以为H5容器,当然也可以采用其他容器,这里仅做举例说明,不做限定。
如图2所示,交互流程包括以下步骤:
步骤001:钱包App对应的站点入驻小程序服务端;
步骤002:小程序服务端计算生成该站点的公私钥对;
步骤003:小程序服务端将公钥发送给该站点;
步骤004:站点将公钥发送给钱包App;
步骤005:用户打开钱包App;
步骤006:钱包App初始化小程序配置,将公钥传入容器;
步骤007:用户通过钱包App打开目标小程序;
步骤008:容器向小程序服务端请求小程序配置;
步骤009:小程序服务端返回小程序配置给容器;
步骤010:容器向小程序服务端请求下载目标小程序的离线包;
步骤011:小程序服务端返回目标小程序的离线包;
步骤012:解压目标小程序的离线包;
步骤013:读取离线包中的签名文件;
步骤014:通过Base64对签名文件解码,得到目标签名数据;
步骤015:使用离线包中的数据包、公钥以及目标签名数据进行验签比对;
步骤016:如果验签通过,加载并渲染离线包中的数据;
步骤017:展示数据;
步骤018:如果验签通过,但数据加载失败,则将报错页面返回给钱包App;
步骤019:如果验签失败,将验签失败的结果展示给用户。
在具体实施过程中,小程序服务端返回的小程序配置中包含有数据包tar、签名文件CERT.json、版本信息manifest.xml,这三个文件均包含在离线包中,在解压离线包之后,可以得到上述三个文件,在通过公钥对签名文件进行验签,得到验签结果,并根据验签结果进行页面展示。
为了更好的理解本说明书实施例中的小程序启动方法,下面从小程序开发、发布、使用的全过程来进行说明。仍以目标程序为钱包App为例,钱包App在开发、发布、 使用的全过程中涉及到用户、小程序开发平台、小程序服务端、国际配置推送服务中心、钱包App、以及容器之间的交互。
具体来讲,接入钱包App的小程序开发过程为:小程序开发者在小程序开发平台中进行小程序的开发,生成离线包;小程序开发平台判断离线包大小是否超出限制条件,若离线包超出限制条件,则通知小程序开发者对小程序进行分包划分,在进行分包划分时,可以通过开发者自定义功能进行划分,也可以通过小程序开发平台自动划分;小程序开发平台将满足限制条件的离线包进行编译,并根据小程序服务端提供的私钥生成签名文件;小程序开发平台对离线包进行编译组装时,可以获取钱包App的版本信息,在版本信息为新版本时,离线包为分包结构,为每个主包和分包生成签名文件,对不同的包进行编译组装;在版本信息为旧版本时,离线包为完整包,为完整包生成签名文件,并进行完整包编译的组装;将编译组装好的离线包(分包结构和/或完整包)上传到小程序服务端。
进一步的,小程序服务端将接收到的离线包投递到国际配置推送服务中心,进行发布。国际配置推送服务中心根据版本信息将离线包投递到钱包App的客户端,即在版本信息为新版本时,只投递主包到客户端,在版本信息为旧版本时,投递完整的离线包到客户端,以使客户端下载对应的离线包。
在小程序启动过程中,用户点击打开小程序,创建并打开容器,若离线包为分包结构,则容器加载主包,并对主包签名文件进行验签,在验签通过时,加载主包资源,若加载成功,渲染页面并将页面通过钱包App展示给用户,若加载页面失败,将展示失败页面展示给用户;在验签失败时,将展示失败页面展示给用户。若离线包为完整包,则容器加载完整包,并对完整包的签名文件进行验签,在验签通过时,加载完整包资源,若加载成功,渲染页面并将页面展示给用户,若加载页面失败,将展示失败页面展示给用户;在验签失败时,将展示失败页面展示给用户。进一步的,在用户点击其他页面时,若离线包为分包结构,则容器加载该页面对应的分包,并对分包签名文件进行验签,在验签通过时,加载分包资源,若加载成功,渲染页面并将页面展示给用户,若加载页面失败,将展示失败页面展示给用户;在验签失败时,将展示失败页面展示给用户。
综上,本说明书实施例中的方案,通过对离线包的签名文件进行验签,能够有效的保证离线包安全性,避免他人对离线包的篡改,另外,在采用分包结构的离线包启动小程序时,由于在启动时仅需要下载主包,大大减小了小程序离线资源包的大小,提高了下载速度已经下载成功率,能够实现小程序启动界面秒开的效果。
第二方面,本说明书实施例提供一种小程序离线包签名方法,应用于小程序服务端,如图3所示,为小程序离线包签名方法的流程图,该方法包括以下步骤。
步骤S32:在接收到针对目标小程序离线包的签名请求时,确定与目标小程序对应的私钥;步骤S34:基于私钥,生成与目标小程序对应的签名文件;步骤S36:在接收到终端设备发送的目标小程序的离线包的下载请求时,将离线包发送给终端设备,离线包中包括签名文件以及目标小程序的数据包。
在具体实施过程中,小程序开发者在小程序开发平台上进行目标小程序的开发,在开发过程中,需要生成目标小程序的签名文件,小程序开发平台可以向小程序服务端请求与目标小程序对应的私钥。
在确定了目标小程序对应的私钥后,小程序服务端可以根据该私钥对目标小程序的离线包进行签名,得到签名文件,或者将私钥发送给开发平台,以生成签名文件,这里不做限定。
基于签名文件,生成目标小程序的离线包,并在终端设备请求下载离线包时,小程序服务端将离线包发送给终端设备。
在一种可选实现方式中,在接收到针对目标小程序离线包的签名请求时,确定与目标小程序对应的私钥之前,方法还包括:在接收到目标站点的入驻请求时,为目标站点分配公私钥对,目标站点为与目标小程序对应的站点;将公私钥对中的公钥发送给目标站点。
关于上述方法,其中各个步骤的具体功能实现已经在本说明书实施例提供的小程序启动方法的实施例中进行了详细描述,此处将不做详细阐述说明。
第三方面,基于同一发明构思,本说明书实施例提供一种小程序启动装置,应用于终端设备,请参考图4,该装置包括:第一获取模块41,用于在检测到启动目标小程序的操作时,向小程序服务端请求下载目标小程序的离线包,离线包中包括与目标小程序对应的签名文件以及目标小程序的数据包;第二获取模块42,用于获取目标小程序对应的公钥;验签模块43,用于基于公钥以及数据包,对签名文件进行验签,获得验签结果;启动模块44,用于在验签结果为验签通过时,加载离线包,以启动目标小程序。
在一种可选实现方式中,第二获取模块42,用于:接收与目标小程序对应的目标站点发送的公钥,公钥为目标站点在入驻小程序服务端时,通过小程序服务端为目标站点分配公私钥对,并将公私钥对中的公钥发送给目标站点获得的。
在一种可选实现方式中,验签模块43,用于:基于公钥对签名文件进行解密处理,得到第一摘要信息;根据数据包的路径,获取离线包的二进制流数据;基于签名文件对应的摘要提取方式,对离线包的二进制流数据进行摘要提取,得到第二摘要信息;通过将第一摘要信息与第二摘要信息进行比对,确定验签结果,其中,在第一摘要信息与第二摘要信息相同时,验签结果为验签通过。
在一种可选实现方式中,签名文件为经过预设编码方式编码后的文件,验签模块43,用于:根据与预设编码方式对应的解码方式,对签名文件进行解码,得到解码后的签名文件;基于公钥以及数据包,对解码后的签名文件进行验签,获得验签结果。
在一种可选实现方式中,目标小程序对应多个离线包,多个离线包由一个主包和N个分包构成,N为正整数,第一获取模块41,用于:向小程序服务端请求下载目标小程序的主包,主包包括主包签名文件以及主包数据包,主包数据包中包含有目标小程序的启动页面数据。
在一种可选实现方式中,装置还包括:第三获取模块,用于在检测到进入目标页面的操作时,向小程序服务端请求下载与目标页面对应的目标分包,目标页面为与目标小程序的启动页面不同的页面,目标分包包括分包签名文件以及分包数据包,分包数据包含有目标页面的数据;验签模块,用于基于公钥以及分包数据包,对分包签名文件进行验签,获得分包验签结果;页面加载模块,用于在分包验签结果为验签通过时,加载目标页面。
关于上述装置,其中各个模块的具体功能已经在本说明书实施例提供的小程序启动方法的实施例中进行了详细描述,此处将不做详细阐述说明。
第四方面,基于同一发明构思,本说明书实施例提供一种小程序离线包签名装置,应用于小程序服务端,如图5所示,装置包括:获取模块51,用于在接收到针对目标小程序离线包的签名请求时,确定与目标小程序对应的私钥;签名模块52,用于基于私钥,生成与目标小程序对应的签名文件;离线包发送模块53,用于在接收到终端设备发送的目标小程序的离线包的下载请求时,将离线包发送给终端设备,离线包中包括签名文件以及目标小程序的数据包。
在一种可选实现方式中,装置还包括:处理模块,用于在接收到目标站点的入驻请求时,为目标站点分配公私钥对,目标站点为与目标小程序对应的站点;公钥发送模块,用于将公私钥对中的公钥发送给目标站点。
关于上述装置,其中各个模块的具体功能已经在本说明书实施例提供的小程序启动方法的实施例中进行了详细描述,此处将不做详细阐述说明。
第五方面,基于与前述实施例中小程序启动方法同样的发明构思,本说明书实施例还提供一种电子设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述程序时实现前文所述小程序启动的步骤。
第六方面,基于与前述实施例中小程序离线包签名方法同样的发明构思,本说明书实施例还提供一种服务器,如图6所示,包括存储器404、处理器402及存储在存储器404上并可在处理器402上运行的计算机程序,所述处理器402执行所述程序时实现前文所述小程序离线包签名方法的步骤。
其中,在图6中,总线架构(用总线400来代表),总线400可以包括任意数量的互联的总线和桥,总线400将包括由处理器402代表的一个或多个处理器和存储器404代表的存储器的各种电路链接在一起。总线400还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起,这些都是本领域所公知的,因此,本文不再对其进行进一步描述。总线接口406在总线400和接收器401和发送器403之间提供接口。接收器401和发送器403可以是同一个元件,即收发机,提供用于在传输介质上与各种其他装置通信的单元。处理器402负责管理总线400和通常的处理,而存储器404可以被用于存储处理器402在执行操作时所使用的数据。
第七方面,基于与前述实施例中基于小程序启动方法、小程序离线包签名方法的发明构思,本说明书实施例还提供一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现前文所述小程序启动方法、小程序离线包签名方法中任一方法的步骤。
本说明书是参照根据本说明书实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的设备。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方 式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令设备的制造品,该指令设备实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本说明书的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例作出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本说明书范围的所有变更和修改。
显然,本领域的技术人员可以对本说明书进行各种改动和变型而不脱离本说明书的精神和范围。这样,倘若本说明书的这些修改和变型属于本说明书权利要求及其等同技术的范围之内,则本说明书也意图包含这些改动和变型在内。

Claims (19)

  1. 一种小程序启动方法,应用于终端设备,所述方法包括:
    在检测到启动目标小程序的操作时,向小程序服务端请求下载所述目标小程序的离线包,所述离线包中包括与所述目标小程序对应的签名文件以及所述目标小程序的数据包;
    获取所述目标小程序对应的公钥;
    基于所述公钥以及所述数据包,对所述签名文件进行验签,获得验签结果;
    在所述验签结果为验签通过时,加载所述离线包,以启动所述目标小程序。
  2. 根据权利要求1所述的方法,所述获取目标小程序对应的公钥,包括:
    接收与所述目标小程序对应的目标站点发送的公钥,所述公钥为所述目标站点在入驻所述小程序服务端时,通过所述小程序服务端为所述目标站点分配公私钥对,并将所述公私钥对中的公钥发送给所述目标站点获得的。
  3. 根据权利要求1所述的方法,所述基于所述公钥以及所述数据包,对所述签名文件进行验签,获得验签结果,包括:
    基于所述公钥对所述签名文件进行解密处理,得到第一摘要信息;
    根据所述数据包的路径,获取所述离线包的二进制流数据;
    基于所述签名文件对应的摘要提取方式,对所述离线包的二进制流数据进行摘要提取,得到第二摘要信息;
    通过将所述第一摘要信息与所述第二摘要信息进行比对,确定所述验签结果,其中,在所述第一摘要信息与所述第二摘要信息相同时,所述验签结果为验签通过。
  4. 根据权利要求1所述的方法,所述签名文件为经过预设编码方式编码后的文件,所述基于所述公钥以及所述数据包,对所述签名文件进行验签,获得验签结果,包括:
    根据与所述预设编码方式对应的解码方式,对所述签名文件进行解码,得到解码后的签名文件;
    基于所述公钥以及所述数据包,对所述解码后的签名文件进行验签,获得所述验签结果。
  5. 根据权利要求1所述的方法,所述目标小程序对应多个离线包,所述多个离线包由一个主包和N个分包构成,N为正整数,所述在检测到启动目标小程序的操作时,向小程序服务端请求下载所述目标小程序的离线包,包括:
    向所述小程序服务端请求下载所述目标小程序的主包,所述主包包括主包签名文件以及主包数据包,所述主包数据包中包含有所述目标小程序的启动页面数据。
  6. 根据权利要求5所述的方法,所述在所述验签结果为验签通过时,加载所述离线包,以启动所述目标小程序之后,所述方法还包括:
    在检测到进入目标页面的操作时,向所述小程序服务端请求下载与所述目标页面对应的目标分包,所述目标页面为与所述目标小程序的启动页面不同的页面,所述目标分包包括分包签名文件以及分包数据包,所述分包数据包含有所述目标页面的数据;
    基于所述公钥以及所述分包数据包,对所述分包签名文件进行验签,获得分包验签结果;
    在所述分包验签结果为验签通过时,加载所述目标页面。
  7. 一种小程序离线包签名方法,应用于小程序服务端,所述方法包括:
    在接收到针对目标小程序离线包的签名请求时,确定与所述目标小程序对应的私钥;
    基于所述私钥,生成与所述目标小程序对应的签名文件;
    在接收到终端设备发送的所述目标小程序的离线包的下载请求时,将所述离线包发送给所述终端设备,所述离线包中包括所述签名文件以及所述目标小程序的数据包。
  8. 根据权利要求7所述的方法,所述在接收到针对目标小程序离线包的签名请求时,确定与所述目标小程序对应的私钥之前,所述方法还包括:
    在接收到目标站点的入驻请求时,为所述目标站点分配公私钥对,所述目标站点为与所述目标小程序对应的站点;
    将所述公私钥对中的公钥发送给所述目标站点。
  9. 一种小程序启动装置,应用于终端设备,所述装置包括:
    第一获取模块,用于在检测到启动目标小程序的操作时,向小程序服务端请求下载所述目标小程序的离线包,所述离线包中包括与所述目标小程序对应的签名文件以及所述目标小程序的数据包;
    第二获取模块,用于获取所述目标小程序对应的公钥;
    验签模块,用于基于所述公钥以及所述数据包,对所述签名文件进行验签,获得验签结果;
    启动模块,用于在所述验签结果为验签通过时,加载所述离线包,以启动所述目标小程序。
  10. 根据权利要求9所述的装置,所述第二获取模块,用于:
    接收与所述目标小程序对应的目标站点发送的公钥,所述公钥为所述目标站点在入驻所述小程序服务端时,通过所述小程序服务端为所述目标站点分配公私钥对,并将所述公私钥对中的公钥发送给所述目标站点获得的。
  11. 根据权利要求9所述的装置,所述验签模块,用于:
    基于所述公钥对所述签名文件进行解密处理,得到第一摘要信息;
    根据所述数据包的路径,获取所述离线包的二进制流数据;
    基于所述签名文件对应的摘要提取方式,对所述离线包的二进制流数据进行摘要提取,得到第二摘要信息;
    通过将所述第一摘要信息与所述第二摘要信息进行比对,确定所述验签结果,其中,在所述第一摘要信息与所述第二摘要信息相同时,所述验签结果为验签通过。
  12. 根据权利要求9所述的装置,所述签名文件为经过预设编码方式编码后的文件,所述验签模块,用于:
    根据与所述预设编码方式对应的解码方式,对所述签名文件进行解码,得到解码后的签名文件;
    基于所述公钥以及所述数据包,对所述解码后的签名文件进行验签,获得所述验签结果。
  13. 根据权利要求9所述的装置,所述目标小程序对应多个离线包,所述多个离线包由一个主包和N个分包构成,N为正整数,所述第一获取模块,用于:
    向所述小程序服务端请求下载所述目标小程序的主包,所述主包包括主包签名文件以及主包数据包,所述主包数据包中包含有所述目标小程序的启动页面数据。
  14. 根据权利要求13所述的装置,所述装置还包括:
    第三获取模块,用于在检测到进入目标页面的操作时,向所述小程序服务端请求下载与所述目标页面对应的目标分包,所述目标页面为与所述目标小程序的启动页面不同的页面,所述目标分包包括分包签名文件以及分包数据包,所述分包数据包含有所述目标页面的数据;
    所述验签模块,用于基于所述公钥以及所述分包数据包,对所述分包签名文件进行验签,获得分包验签结果;
    页面加载模块,用于在所述分包验签结果为验签通过时,加载所述目标页面。
  15. 一种小程序离线包签名装置,应用于小程序服务端,所述装置包括:
    获取模块,用于在接收到针对目标小程序离线包的签名请求时,确定与所述目标小程序对应的私钥;
    签名模块,用于基于所述私钥,生成与所述目标小程序对应的签名文件;
    离线包发送模块,用于在接收到终端设备发送的所述目标小程序的离线包的下载请求时,将所述离线包发送给所述终端设备,所述离线包中包括所述签名文件以及所述目 标小程序的数据包。
  16. 根据权利要求15所述的装置,所述装置还包括:
    处理模块,用于在接收到目标站点的入驻请求时,为所述目标站点分配公私钥对,所述目标站点为与所述目标小程序对应的站点;
    公钥发送模块,用于将所述公私钥对中的公钥发送给所述目标站点。
  17. 一种电子设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述程序时实现权利要求1-6任一项所述方法的步骤。
  18. 一种服务器,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,所述处理器执行所述程序时实现权利要求7-8任一项所述方法的步骤。
  19. 一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现权利要求1-8任一项所述方法的步骤。
PCT/CN2021/093358 2020-05-15 2021-05-12 小程序启动方法、签名方法、装置、服务器及介质 WO2021228143A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010412174.4A CN111708990A (zh) 2020-05-15 2020-05-15 小程序启动方法、签名方法、装置、服务器及介质
CN202010412174.4 2020-05-15

Publications (1)

Publication Number Publication Date
WO2021228143A1 true WO2021228143A1 (zh) 2021-11-18

Family

ID=72537818

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/093358 WO2021228143A1 (zh) 2020-05-15 2021-05-12 小程序启动方法、签名方法、装置、服务器及介质

Country Status (2)

Country Link
CN (1) CN111708990A (zh)
WO (1) WO2021228143A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114691236A (zh) * 2022-03-24 2022-07-01 中国银联股份有限公司 原生程序与小程序的集成方法、装置、设备及介质
CN114791834A (zh) * 2022-02-25 2022-07-26 数字广东网络建设有限公司 一种应用程序的启动方法、装置、电子设备及存储介质
CN116820555A (zh) * 2023-08-29 2023-09-29 腾讯科技(深圳)有限公司 应用程序的分包方法、装置、电子设备及可读存储介质

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111708990A (zh) * 2020-05-15 2020-09-25 支付宝(杭州)信息技术有限公司 小程序启动方法、签名方法、装置、服务器及介质
CN112685097B (zh) * 2020-12-28 2024-04-16 北京达佳互联信息技术有限公司 一种数据处理方法和装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105119888A (zh) * 2015-07-10 2015-12-02 小米科技有限责任公司 插件安装包上传方法、安装方法及装置
CN109814913A (zh) * 2018-12-25 2019-05-28 华为终端有限公司 一种应用包拆分重组和运行的方法和装置
CN111708990A (zh) * 2020-05-15 2020-09-25 支付宝(杭州)信息技术有限公司 小程序启动方法、签名方法、装置、服务器及介质

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100367094B1 (ko) * 1999-10-22 2003-01-06 한국전자통신연구원 컴퓨터 프로그램 온라인 유통 방법
CN101286842B (zh) * 2008-05-26 2011-04-06 西安西电捷通无线网络通信股份有限公司 一种利用公钥密码技术的密钥分配及其公钥在线更新方法
US8539610B2 (en) * 2010-10-29 2013-09-17 Nokia Corporation Software security
CN108600157A (zh) * 2018-03-08 2018-09-28 阿里巴巴集团控股有限公司 页面加载方法及装置
CN108683700A (zh) * 2018-04-03 2018-10-19 四川新网银行股份有限公司 一种基于微信小程序及金融开放平台的金融能力输出模式
CN109857385B (zh) * 2018-12-24 2022-01-28 四川长虹电器股份有限公司 应用程序文件打包方法、安装方法及启动方法
CN110362248A (zh) * 2019-06-19 2019-10-22 北京字节跳动网络技术有限公司 小程序侧边菜单栏的控制方法、装置、设备及介质
CN110414190B (zh) * 2019-07-30 2023-06-27 宇龙计算机通信科技(深圳)有限公司 应用安装包的签名方法、相关装置、存储介质及电子设备
CN110401526B (zh) * 2019-07-31 2022-10-18 中国工商银行股份有限公司 基于小程序的客户信息安全交互方法、终端及服务器
CN110688124B (zh) * 2019-08-23 2023-03-17 北京奇艺世纪科技有限公司 小程序处理方法、装置、电子设备及计算机可读存储介质
CN111026438B (zh) * 2019-11-29 2023-08-04 百度在线网络技术(北京)有限公司 小程序包和页面关键信息的提取方法、装置、设备及介质
CN111049897B (zh) * 2019-12-10 2023-02-17 北京百度网讯科技有限公司 小程序包的加密上传和解密部署方法、装置、设备和介质

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105119888A (zh) * 2015-07-10 2015-12-02 小米科技有限责任公司 插件安装包上传方法、安装方法及装置
CN109814913A (zh) * 2018-12-25 2019-05-28 华为终端有限公司 一种应用包拆分重组和运行的方法和装置
CN111708990A (zh) * 2020-05-15 2020-09-25 支付宝(杭州)信息技术有限公司 小程序启动方法、签名方法、装置、服务器及介质

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114791834A (zh) * 2022-02-25 2022-07-26 数字广东网络建设有限公司 一种应用程序的启动方法、装置、电子设备及存储介质
CN114791834B (zh) * 2022-02-25 2024-04-26 数字广东网络建设有限公司 一种应用程序的启动方法、装置、电子设备及存储介质
CN114691236A (zh) * 2022-03-24 2022-07-01 中国银联股份有限公司 原生程序与小程序的集成方法、装置、设备及介质
CN114691236B (zh) * 2022-03-24 2024-04-19 中国银联股份有限公司 原生程序与小程序的集成方法、装置、设备及介质
CN116820555A (zh) * 2023-08-29 2023-09-29 腾讯科技(深圳)有限公司 应用程序的分包方法、装置、电子设备及可读存储介质
CN116820555B (zh) * 2023-08-29 2023-11-28 腾讯科技(深圳)有限公司 应用程序的分包方法、装置、电子设备及可读存储介质

Also Published As

Publication number Publication date
CN111708990A (zh) 2020-09-25

Similar Documents

Publication Publication Date Title
WO2021228143A1 (zh) 小程序启动方法、签名方法、装置、服务器及介质
US20180373523A1 (en) Application update method and apparatus
CN109634619B (zh) 可信执行环境实现方法及装置、终端设备、可读存储介质
CN111143869B (zh) 应用程序包处理方法、装置、电子设备及存储介质
CN111666564B (zh) 应用程序安全启动方法、装置、计算机设备和存储介质
CN106170763B (zh) 一种软件校验方法和装置
CN112861191B (zh) 一种应用程序监控方法及装置
CN111880826A (zh) 云业务应用升级方法、装置、电子设备和存储介质
CN106709281B (zh) 补丁发放和获取方法、装置
KR20170089352A (ko) 가상화 시스템에서 수행하는 무결성 검증 방법
CN108400875B (zh) 基于键值的授权认证方法、系统、电子设备、存储介质
CN106354832B (zh) 一种数据发布方法、设备及系统
EP4224316A1 (en) Mirror image management method and apparatus
KR101482700B1 (ko) 해시를 이용한 프로그램의 무결성 검증 방법
JP7439067B2 (ja) ファイルシステムの検証とインストール
CN109934016B (zh) 应用的签名校验方法、装置及电子设备
CN106155723B (zh) 业务应用程序的升级方法和装置、终端和计算机存储介质
CN113360172B (zh) 应用部署方法、装置、计算机设备及存储介质
CN114912097A (zh) 一种证书校验方法、装置、电子设备及存储介质
CN116029526A (zh) 一种实验资源的调度方法、装置、设备及存储介质
CN115080147A (zh) 基于人工智能的h5页面加载方法、装置、设备及介质
CN114462101A (zh) 一种应用apk包的处理系统、方法和装置
CN113761587A (zh) 用于签名校验的方法和装置
CN110489276B (zh) 基于业务页面的验证服务的容灾方法和装置
CN114301655B (zh) 基于Android的数据安全传输方法、系统、装置及介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21803951

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21803951

Country of ref document: EP

Kind code of ref document: A1