Data sharing method and device and electronic equipment

Abstract

The invention discloses a data sharing method and device and electronic equipment. The method comprises the following steps: encrypting data shared by a source lightweight application and a target lightweight application to obtain encrypted data; creating a temporary encrypted file corresponding to the target lightweight application in a target storage position of equipment running the target lightweight application and the source lightweight application; and storing the encrypted data in a temporary encrypted file, the temporary encrypted file being used for the target lightweight application to obtain the shared encrypted data. According to the method and the device, the technical problem that direct data sharing cannot be realized between lightweight applications without depending on a third-party platform is solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of software development, in particular to a data sharing method and device and electronic equipment. BACKGROUND

[0002] With the continuous expansion of lightweight application users, lightweight applications quickly occupy the mobile application market, and are widely used in various fields such as life service, mobile shopping, financial management, mobile video, medical service, etc. It has become a core tool for low-cost, high-penetration digital transformation.

[0003] However, most businesses require a large ecosystem, and business scenarios need to rely on multiple lightweight applications to achieve lightweight application running space, which is independent, and different lightweight applications cannot directly share data. Although it can be achieved through the method provided by the third-party platform or the separately developed data sharing application programming interface (API), the implementation process is complex, the delay is high and uncontrollable, the workload is large, and relying on the third-party platform to achieve data sharing has a big data security problem.

[0004] In view of the above problems, no effective solution has been proposed so far. SUMMARY

[0005] The embodiments of the present application provide a data sharing method, device and electronic equipment to at least solve the technical problem that lightweight applications cannot directly share data without relying on a third-party platform. According to one aspect of an embodiment of the present application, a data sharing method is provided, comprising: encrypting data shared by a source lightweight application and a target lightweight application to obtain encrypted data; creating a temporary encrypted file corresponding to the target lightweight application in a target storage location of a device running the target lightweight application and the source lightweight application; and storing the encrypted data in the temporary encrypted file, wherein the temporary encrypted file is used by the target lightweight application to obtain shared encrypted data.

[0006] According to some embodiments of the present application, the method further comprises: after the encrypted data is stored in the temporary encrypted file, starting a timing detection task, which includes: detecting whether the temporary encrypted file exists after a preset time period; in the case that the temporary encrypted file exists, deleting the temporary encrypted file and ending the timing detection task, and in the case that the temporary encrypted file does not exist, ending the timing detection task.

[0007] According to some embodiments of the present application, the method further comprises: adjusting the preset time period according to the remaining storage capacity of the target storage location of the device and the performance index of the device.

[0008] According to some embodiments of the present application, creating a temporary encrypted file corresponding to a target lightweight application in a target storage location of a device running the target lightweight application and a source lightweight application includes: obtaining an application identifier of the target lightweight application from a registry, wherein the registry is used to indicate at least application identifiers of all lightweight applications allowed to interact with the source lightweight application; obtaining a preset encrypted file path in the target storage location; and creating the temporary encrypted file according to the application identifier of the target lightweight application and the preset encrypted file path.

[0009] According to some embodiments of the present application, encrypting data shared by a source lightweight application and a target lightweight application includes: encrypting the data shared by the source lightweight application and the target lightweight application by using a secret key pair, wherein the secret key pair is synchronized to the target lightweight application and the source lightweight application in an offline manner, and the offline manner refers to synchronizing the secret key pair to the target lightweight application and the source lightweight application without interaction between the target lightweight application and the source lightweight application.

[0010] According to some embodiments of the present application, creating the temporary encrypted file according to the application identifier of the target lightweight application and the preset encrypted file path includes: checking a remaining storage capacity of the target storage location, and creating a target file named according to the application identifier of the target lightweight application under the preset encrypted file path of the target storage location and determining the target file as the temporary encrypted file corresponding to the target lightweight application in a case where the remaining storage capacity is greater than a data size of the encrypted data, wherein file read-write permissions of the temporary encrypted file only include the source lightweight application and the target lightweight application.

[0011] According to some embodiments of the present application, the method further includes: in a case where creating the temporary encrypted file under the preset encrypted file path of the target storage location fails, obtaining a creation failure reason; starting a retry mechanism according to at least the creation failure reason to re-create the temporary encrypted file under the preset encrypted file path of the target storage location, wherein the retry mechanism at least includes a retry number and a retry interval; and in a case where the temporary encrypted file is not successfully created under the preset encrypted file path of the target storage location after starting the retry mechanism, generating an error report, wherein the error report at least includes a timestamp and the creation failure reason.

[0012] According to another aspect of the embodiments of the present application, a data sharing method is further provided, including: determining a temporary encrypted file from a target storage location of a device running a target lightweight application and a source lightweight application, wherein the temporary encrypted file is used to store encrypted data shared between the target lightweight application and the source lightweight application; decrypting the encrypted file in the temporary encrypted file to obtain decrypted data, and deleting the temporary encrypted file after obtaining the decrypted data.

[0013] According to a further aspect of the embodiments of the present application, a data sharing apparatus is also provided, which comprises: an encryption module configured to encrypt data shared by a source lightweight application and a target lightweight application to obtain encrypted data; a creation module configured to create a temporary encrypted file corresponding to the target lightweight application in a target storage location of a device running the target lightweight application and the source lightweight application; and a storage module configured to store the encrypted data into the temporary encrypted file, wherein the temporary encrypted file is used by the target lightweight application to obtain the shared encrypted data.

[0014] According to a further aspect of the embodiments of the present application, a non-volatile storage medium is also provided, which stores a program, wherein the program, when executed, controls a device where the non-volatile storage medium is located to perform the above data sharing method.

[0015] According to a further aspect of the embodiments of the present application, an electronic device is also provided, which comprises a memory and a processor, wherein the processor is configured to execute a program stored in the memory, and the program, when executed, performs the above data sharing method.

[0016] According to a further aspect of the embodiments of the present application, a computer program product is also provided, which comprises computer instructions, and the computer instructions, when executed by a processor, implement the above data sharing method.

[0017] In the embodiments of the present application, the data shared by the source lightweight application and the target lightweight application is encrypted to obtain encrypted data, a temporary encrypted file corresponding to the target lightweight application is created in a target storage location of a device running the target lightweight application and the source lightweight application, and the encrypted data is stored into the temporary encrypted file, wherein the temporary encrypted file is used by the target lightweight application to obtain the shared encrypted data. In this way, the source lightweight application creates the temporary encrypted file corresponding to the target lightweight application in the target storage location of the device running the target lightweight application and the source lightweight application, and stores the data to be shared into the temporary encrypted file, and then the target lightweight application obtains the encrypted data from the temporary encrypted file, so as to achieve the purpose of directly sharing data between the source lightweight application and the target lightweight application, and further solve the technical problem that lightweight applications cannot directly share data without relying on a third-party platform. BRIEF DESCRIPTION OF DRAWINGS

[0018] The accompanying drawings, which are included to provide a further understanding of the present application and constitute a part of this application, illustrate certain illustrative embodiments of the present application and together with the description serve to explain the present application. In the drawings:

[0019] Figure 1A hardware structure block diagram of a computer terminal for implementing a data sharing method according to an embodiment of the present application is provided.

[0020] Figure 2 A flow chart of a first data sharing method according to an embodiment of the present application is provided.

[0021] Figure 3 A flow chart of a second data sharing method according to an embodiment of the present application is provided.

[0022] Figure 4 A flow chart of a third data sharing method according to an embodiment of the present application is provided.

[0023] Figure 5 A flow chart of a fourth data sharing method according to an embodiment of the present application is provided.

[0024] Figure 6 A flow chart of a fifth data sharing method according to an embodiment of the present application is provided.

[0025] Figure 7 A flow chart of a sixth data sharing method according to an embodiment of the present application is provided.

[0026] Figure 8 A structure schematic diagram of a data sharing device according to an embodiment of the present application is provided. DETAILED DESCRIPTION

[0027] In order to enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work should fall within the scope of protection of the present application.

[0028] The information collected in the embodiments of the present application is information and data authorized by users or authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of related data all comply with relevant laws, regulations and standards in relevant regions, necessary security measures are taken, public order and good customs are not violated, and appropriate operation portals are provided for users to choose authorization or refuse automatic decision results; if the user chooses to refuse, the expert decision process is entered.

[0029] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0030] To better understand the embodiments of this application, the technical terms involved in the embodiments of this application are explained below:

[0031] Data sharing refers to the process by which different systems, organizations, or individuals authorize access to, exchange, or integrate data resources based on agreements or technical means.

[0032] Lightweight applications are a type of application designed to be small in size, consume few resources, and start up quickly. Unlike traditional native applications that require downloading and installing packages, lightweight applications do not require users to install them and can be used directly on specific platforms.

[0033] In related technologies, direct data sharing between different lightweight applications is not possible. Although it can be achieved through methods provided by third-party platforms or by developing a separate application programming interface (API), the implementation process is complex, has high and uncontrollable latency, and involves a large workload. Relying on third-party platforms for data sharing also poses significant data security risks. Therefore, there is a technical problem that lightweight applications cannot achieve direct data sharing without relying on third-party platforms. To solve this problem, this application provides a related solution, which is described in detail below.

[0034] According to an embodiment of this application, an embodiment of a data sharing method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0035] The methods and embodiments provided in this application can be executed on a computer terminal or similar computing device. Figure 1A hardware structure block diagram of a computer terminal for implementing the method of sharing data is shown. As shown in Figure 1 The computer terminal 10 can include one or more processors 102 (the processor 102 can include but not limited to a microprocessor MCU or a programmable logic device FPGA processing device, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it can also include a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which can be included as one of the ports in the BUS bus), a network interface, a power supply and / or a camera. Those skilled in the art can understand that Figure 1 The structure shown is only schematic, which does not limit the structure of the above-mentioned electronic device. For example, the computer terminal 10 can include more or less components than those shown in Figure 1 or have a different configuration than that shown in Figure 1 .

[0036] It should be noted that the one or more processors 102 and / or other data processing circuits described above can be referred to herein as "data processing circuits" in general. The data processing circuit can be embodied in whole or in part as software, hardware, firmware or any combination thereof. In addition, the data processing circuit can be a single independent processing module, or all or part of any one of the other elements incorporated into the computer terminal 10. As referred to in the embodiments of the present application, the data processing circuit serves as a processor to control (for example, selection of a variable resistance terminal path connected to an interface).

[0037] The memory 104 can be used to store software programs and modules of application software, such as program instructions / data storage means corresponding to the method of sharing data in the embodiments of the present application. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, that is, implements the above-mentioned method of sharing data. The memory 104 can include a high-speed random access memory, and can also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 can further include a memory remotely disposed with respect to the processor 102, which can be connected to the computer terminal 10 through a network. Examples of the above-mentioned network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0038] The transmission device 106 is configured to receive or send data via a network. The network can include a wireless network provided by a communication provider of the computer terminal 10. In one example, the transmission device 106 includes a network interface controller (NIC) that can connect to other network devices through a base station to communicate with the Internet. In one example, the transmission device 106 can be a radio frequency (RF) module that is configured to communicate with the Internet wirelessly.

[0039] The display can be a liquid crystal display (LCD) that is touch screen, for example, which can enable a user to interact with a user interface of the computer terminal 10.

[0040] In the above operating environment, an embodiment of a data sharing method is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0041] As shown in FIG. 1, the computer terminal 10 includes a processor 100, a memory 102, a display 104, a transmission device 106, and a storage device 108. Figure 2 As shown in FIG. 2, an embodiment of a data sharing method is provided, which includes the following steps:

[0042] In step S202, the data shared by the source lightweight application and the target lightweight application is encrypted to obtain encrypted data.

[0043] In the technical solution provided in step S202, there are various implementation manners for encrypting the data shared by the source lightweight application and the target lightweight application, for example, a secret key pair is used to encrypt the data shared by the source lightweight application and the target lightweight application, wherein the secret key pair is synchronized to the target lightweight application and the source lightweight application in an offline manner, and the offline manner refers to synchronizing the secret key pair to the target lightweight application and the source lightweight application without interaction between the target lightweight application and the source lightweight application.

[0044] As some embodiments of the present application:

[0045] When the source lightweight application uses the key pair to encrypt the data shared with the target lightweight application, data preparation needs to be performed first. First, the data to be encrypted is obtained, and the data is preprocessed, such as data cleaning, standardization, or desensitization, to ensure data quality and comply with data privacy regulations. Then, the collected and preprocessed data is converted into an object conforming to the JSON (JSON (JavaScript Object Notation) is a lightweight data exchange format, easy for humans to read and write, and also easy for machines to parse and generate) standard. When building a JSON object, the syntax rules of JSON should be followed, and the data should be stored in the form of key-value pairs to ensure accurate representation and clear structure of the data. Finally, the JSON-formatted data is converted into a string, and the string-formatted data is the final data for encryption.

[0046] When the source lightweight application (for example, a small program) uses the key pair to encrypt the data (the above-mentioned string-formatted data) shared with the target lightweight application, an RSA key pair (RSA is an asymmetric encryption algorithm. In RSA encryption, a key pair contains a public key and a private key. The public key is used for encryption, and the private key is used for decryption. Since different keys are used for encryption and decryption, RSA can achieve information confidentiality and identity verification) can be used. Before encryption using the key pair, the key pair is synchronized to the target lightweight application and the source lightweight application in an offline manner, for example, in response to a setting instruction of a developer, the key pair is synchronized to the target lightweight application and the source lightweight application (the public key in the key pair is synchronized to the source lightweight application for encrypting data, and the private key in the key pair is synchronized to the target lightweight application for decrypting data). The key pair can be obtained by encrypted email to the developers of the target lightweight application and the source lightweight application or offline meeting or secure physical medium transmission. This offline manner ensures that the key pair will not be intercepted during network transmission, increasing the security of data transmission.

[0047] The source lightweight application uses the public key (the public key of the target lightweight application) in the key pair to perform asymmetric encryption on the data shared with the target lightweight application. The encryption process can use a standard implementation of the RSA algorithm.

[0048] Step S204, in the target storage location of the device running the target lightweight application and the source lightweight application, a temporary encrypted file corresponding to the target lightweight application is created. The device running the target lightweight application and the source lightweight application can be a mobile phone, a tablet computer, a smart wearable device, etc., the target storage location can be a hard disk, a memory card, a local file system, etc. of the device, and the target lightweight application and the source lightweight application can be any lightweight application supported software, a small program in a website or platform running in the device, for example, a small program in a social software, a small program in an e-commerce platform, etc.

[0049] In the technical solution provided in step S204, there are various implementation manners for creating the temporary encrypted file corresponding to the target lightweight application in the target storage location of the device running the target lightweight application and the source lightweight application, for example: obtaining the application identifier of the target lightweight application from a registry, wherein the registry is used at least to indicate the application identifiers of all lightweight applications allowed to interact by the source lightweight application; obtaining a preset encrypted file path in the target storage location; and creating the temporary encrypted file according to the application identifier of the target lightweight application and the preset encrypted file path.

[0050] In the above step, the temporary encrypted file can be created according to the application identifier of the target lightweight application and the preset encrypted file path by the following manner: checking the remaining storage capacity of the target storage location, and in the case that the remaining storage capacity is greater than the data size of the encrypted data, creating a target file named according to the application identifier of the target lightweight application under the preset encrypted file path of the target storage location, and determining the target file as the temporary encrypted file corresponding to the target lightweight application, wherein the file read-write permission of the temporary encrypted file only contains the source lightweight application and the target lightweight application.

[0051] In the case that the creation of the temporary encrypted file with the application identifier of the target lightweight application as the file name under the preset encrypted file path of the target storage location fails, the reason for the failure is obtained; and at least according to the reason for the failure, a retry mechanism is started to re-create the temporary encrypted file under the preset encrypted file path of the target storage location, wherein the retry mechanism at least includes the number of retries and the retry interval; and in the case that the temporary encrypted file is not successfully created under the preset encrypted file path of the target storage location after the retry mechanism is started, an error report is generated, wherein the error report at least includes a timestamp and the reason for the failure.

[0052] As some embodiments of the present application:

[0053] The registry stores and manages the application identifier of all the lightweight applications allowed to interact with the source lightweight application. The registry is a local storage area possessed by the lightweight application on each device (such as a smart phone, a tablet computer, etc.) for recording the lightweight application and various configuration information and state information thereof when running on the device. The registry is essentially a part of the device storage, and each lightweight application has its own registry for saving the metadata and running parameters of the lightweight application itself and the authorized application list (explicitly listing the lightweight application list allowed to interact with the source lightweight application, and the application identifier of each lightweight application). The source lightweight application first obtains the lightweight application list allowed to interact from the authorized application list of the registry, and then finds the application identifier (for example, APP ID) of the target lightweight application from the lightweight application list allowed to interact. When obtaining the preset encrypted file path in the target storage location, the preset encrypted file path is added to the environment variable or the configuration file in response to the definition instruction of the developer. The developers of the target lightweight application and the source lightweight application pre-agree the specific file path of the target storage location of the preset encrypted file path through offline meetings or encrypted emails, etc. The selection of the preset encrypted file path can further isolate sensitive data in the sandbox environment of the device, preventing unauthorized access. It is particularly suitable for scenarios that require strict control of data access permissions, such as financial transactions, medical health information sharing, etc., greatly reducing the risk of data abuse.

[0054] When creating the temporary encrypted file according to the application identifier of the target lightweight application and the preset encrypted file path, first, the remaining storage capacity of the target storage location (for example, the remaining storage capacity of the hard disk) is checked, the remaining capacity is compared with the data size required by the encrypted data (that is, the capacity size required to store the encrypted data), and in the case where the remaining storage capacity is greater than the data size of the encrypted data, the temporary encrypted file can be created. If the preset encrypted file path is not found in the target storage location, the directory needs to be created first to ensure the smooth operation of the subsequent temporary encrypted file creation operation. Then a target file is created in the preset encrypted file path as a temporary encrypted file, which is named according to the application identifier of the target lightweight application. The naming method of the temporary encrypted file has been added to the environment variable or configuration file in response to the definition instruction of the developer. The developers of the target lightweight application and the source lightweight application have previously agreed on the naming method of the temporary encrypted file through offline meetings or encrypted emails, etc. For example, the temporary encrypted file is directly named as the application identifier of the target lightweight application. In the case where the remaining storage capacity is not greater than the data size of the encrypted data, a prompt message is pushed to the client of the source lightweight application to prompt that the device memory is insufficient and the temporary encrypted file cannot be created. After successfully creating the temporary encrypted file, the file read-write permission of the temporary encrypted file is set to only include the source lightweight application and the target lightweight application.

[0055] The creation process can fail for various reasons (e.g. permission issues, file system busy, etc.), so all possible exceptions should be caught at the code level. In the case that the creation of the temporary encrypted file with the application identifier of the target lightweight application as the file name under the preset encrypted file path of the target storage location fails, the log of the device is captured, which contains the operation status of the target storage location. The log is analyzed to obtain the creation failure reason (e.g. the target storage location is in a read-only state, the storage medium is damaged, other high-intensity operations (e.g. disk defragmentation) are being performed, etc.), and at least according to the creation failure reason, a retry mechanism is started. The retry mechanism can be implemented in various ways, for example: only in the case that the creation failure reason is temporary or can be predicted to be resolved (i.e. without the intervention of the developer, for example, other high-intensity operations (e.g. disk defragmentation) are being performed), the retry mechanism is started. For other types of creation failure reasons, a prompt message is generated and pushed to the developer client of the source lightweight application, and the prompt message at least includes the failure reason. After the retry mechanism is started, the temporary encrypted file is created again under the preset encrypted file path of the target storage location, wherein the retry mechanism at least includes the number of retries and the retry interval (e.g. up to 3 retries, and each retry interval is 5 seconds). Within the number of retries, each time the retry interval is waited and then the file is created again. Before retrying, it should be checked whether the creation failure reason has changed. Each time the retry is performed, the corresponding information is recorded, including the timestamp (including the timestamp of the time when the retry starts and the timestamp of the time when the retry fails), the number of retries, the failure reason and the current retry interval. After the retry mechanism is started, if the temporary encrypted file is not successfully created under the preset encrypted file path of the target storage location (i.e. all retries fail, at this time no automatic retry is attempted, but an error report is generated), an error report is generated, wherein the error report at least includes the timestamp (at least includes the timestamp of the first attempt to create (records the time point of the first attempt to create the temporary encrypted file, which is helpful for analyzing the time line of the entire operation and identifying whether there is a time-related factor affecting the creation of the file); the error occurrence timestamp (records the specific time point when the temporary encrypted file creation fails for the first time); the retry timestamp (if the retry mechanism is started, the start time point of each retry attempt and the time point when the retry fails should be recorded); the retry start and end timestamp (records the time point when the first retry starts and the time point when the final retry ends, whether it is successful or not. If the retry finally fails, the comparison of this timestamp and the error occurrence timestamp can provide information about the duration of the retry mechanism) error report generation timestamp (records the time point when the error report is created)) and the creation failure reason.

[0056] In step S206, the encrypted data is stored in the temporary encrypted file, wherein the temporary encrypted file is used by the target lightweight application to obtain the shared encrypted data.

[0057] In the technical solution provided in step S206, after the encrypted data is stored in the temporary encrypted file, a timing detection task is started, which includes: detecting whether the temporary encrypted file exists after a preset time length; in the case where the temporary encrypted file exists, deleting the temporary encrypted file and ending the timing detection task, and in the case where the temporary encrypted file does not exist, ending the timing detection task. The preset time length is adjusted according to the remaining storage capacity of the target storage location of the device and the performance index of the device.

[0058] As some embodiments of the present application:

[0059] After the encrypted data is stored in the temporary encrypted file, a timing detection task is started, which includes: detecting whether the temporary encrypted file exists after a preset time length (for example, initially 3 seconds), and the purpose of the timing detection task is to prevent data leakage, in the case where the temporary encrypted file exists (that is, the temporary encrypted file exists in the preset encrypted file path of the target storage location), the temporary encrypted file is deleted and the timing detection task is ended, which can effectively prevent data leakage, and in the case where the temporary encrypted file does not exist, the timing detection task is directly ended, and the temporary encrypted file may not exist because the target lightweight application has read the encrypted data in the temporary encrypted file in the preset encrypted file path of the target storage location within the preset time length, at which time the timing detection task of the source lightweight application detects that the temporary encrypted file does not exist after the preset time length (for example, initially 3 seconds).

[0060] It should be noted that the preset time length can be adjusted according to the remaining storage capacity of the target storage location of the device, the performance index of the device, and the network condition: the remaining storage capacity of the target storage location is detected before the timing detection task is started, the available space ratio is calculated, and the CPU usage, memory occupation and other indexes are collected through the device performance monitoring API before the timing detection task is started to evaluate the current load state of the device. The available space ratio and the load state are used as two influence factors. Based on the above two influence factors (mapped to 0 to 1) after normalization processing and the preset weight corresponding to each influence factor, a weighted average adjustment coefficient is calculated, the adjusted preset time length is the product of the original preset time length and the adjustment coefficient, and the adjusted preset time length needs to meet the constraints of the maximum and minimum thresholds (for example, the maximum cannot exceed 5 seconds, and the minimum cannot be shorter than 1 second), if the adjusted preset time length is less than the minimum threshold, the adjusted preset time length takes the minimum threshold, and if the adjusted preset time length is greater than the maximum threshold, the adjusted preset time length takes the maximum threshold. In addition, in the case where the encrypted data is specific data (for example, medical data), the preset time is adjusted according to the importance level of the medical data, wherein different importance levels correspond to different preset times.

[0061] Figure 3 is a flow chart of a second data sharing method according to an embodiment of the application, which shows a sharing method between lightweight applications in the related art, the source lightweight application and the target lightweight application directly carry shared data to jump, this way has the risk of data leakage and can carry very limited shared data.

[0062] Figure 4 is a flow chart of a third data sharing method according to an embodiment of the application, which shows a sharing method between lightweight applications in the related art, the source lightweight application and the target lightweight application realize data sharing through the development environment of the third-party data platform, the source lightweight application writes data into the third-party data platform, and the target lightweight application reads data from the third-party data platform, this way has the risk of data leakage of the third-party data platform, and in addition, the transmission delay is uncontrollable.

[0063] Figure 5 is a flow chart of a fourth data sharing method according to an embodiment of the application, which shows a sharing method between lightweight applications in the related art, in this method, the source lightweight application and the target lightweight application share data through the source lightweight application server and the target lightweight application server, the source lightweight application and the source lightweight application server interact user behavior data, that is, the data to be shared is transmitted to the source lightweight application server. When the source lightweight application and the target lightweight application interact data, the source lightweight application carries authentication parameters (represented by token) when jumping to the target lightweight application, the target lightweight application uses the authentication parameters token to obtain shared data from the target lightweight application server, the target lightweight application server requests legitimacy authentication from the source lightweight application server, the source lightweight application server returns the authentication situation, if the authentication is passed, the target lightweight application server requests user / business data (that is, shared data) from the source lightweight application server, the source lightweight application server returns the data (that is, shared data) to the target lightweight application server, and finally the target lightweight application server returns the shared data to the target lightweight application. This method has low data transmission rate and low efficiency. The interfacing process has large workload, and there is the risk of data leakage caused by network packet capture behavior.

[0064] Figure 6 is a flow chart of a fifth data sharing method according to an embodiment of the application, which shows the data sharing method of the application, compared with Figures 3-5The method described in this application embodiment involves the source lightweight application and the target lightweight application sharing data through dynamically encrypted files (i.e., the aforementioned temporary encrypted files). Specifically, the source lightweight application and the target lightweight application pre-agree on the encrypted file path (represented by filePath, i.e., the aforementioned preset encrypted file path; pre-agreement means that the aforementioned preset encrypted file path is added to the environment variable or configuration file in response to the developer's definition instruction. The developers of the target lightweight application and the source lightweight application pre-agree on the specific file path of the pre-preset encrypted file path in the target storage location through offline meetings or encrypted emails, etc.), where fileName represents the encrypted file name as the target mini-program APPID (i.e., the naming method of the temporary encrypted file pre-agreeed by the developers of the target lightweight application and the source lightweight application through offline meetings or encrypted emails, where APPID is the application identifier). The RSA key pair is then synchronized to both lightweight applications (i.e., the RSA key pair is distributed to the target lightweight application and the source lightweight application; corresponding to the aforementioned offline synchronization of the key pair to the target lightweight application and the source lightweight application before encryption). The source lightweight application first prepares the shared data, then uses an RSA key to encrypt the shared data, generating an encrypted file based on filePath and fileName (i.e., creating a temporary encrypted file according to the target lightweight application's application identifier and the preset encrypted file path). The encrypted data is then written to the encrypted file (here, the encrypted file is the dynamically encrypted file highlighted in red, which is also the temporary encrypted file in this example, corresponding to the step of storing encrypted data into the temporary encrypted file described above). Finally, a scheduled task is started, checking after 3 seconds whether the encrypted file exists. If it does not exist, the scheduled task ends directly; otherwise, it deletes the encrypted file and ends the scheduled task. The target lightweight application is responsible for reading the encrypted file data, specifically from the dynamically encrypted file, then decrypting it using the RSA key, and finally deleting the dynamically encrypted file after decryption. This method ensures data validity by generating dynamically encrypted shared data with each jump by the source lightweight application, deleting the dynamically encrypted file after data reading, and deleting the data within 3 seconds by the scheduled task. This approach effectively prevents data theft and tampering during the process, improving data security.

[0065] The method in the embodiments of the present application uses a local file as a data transmission medium. The applet has a higher reading speed for a local file than a network request for obtaining data. Moreover, the reading time of the local file is basically fixed and is not affected by network delay and other factors. This approach can improve data sharing efficiency. In addition, the amount of data that can be stored in the local file is larger than the amount of data directly transmitted through parameters and the amount of data transmitted through the server development API method. Therefore, using this method can increase the amount of shared data. The source applet writes the encrypted shared data into a dynamic encrypted file, and the target applet reads the shared data in the encrypted file, thereby avoiding data transmission through a third-party platform and effectively avoiding the risk of data leakage on the third-party platform. At the same time, the complex process of using the server development API is saved, the development workload is saved, and the risk of data leakage due to network packet capture behavior during data transmission is avoided. The encryption processing has high reliability in terms of data privacy and integrity, thereby improving the overall security.

[0066] Figure 7 FIG. 6 is a flowchart of a sixth data sharing method according to the embodiments of the present application, showing a flowchart of the data sharing method when the target lightweight application is the execution subject, including the following steps:

[0067] In step S702, a temporary encrypted file is determined from a target storage location of a device running the target lightweight application and the source lightweight application, wherein the temporary encrypted file is used to store encrypted data shared between the target lightweight application and the source lightweight application.

[0068] In the technical solution provided in step S702, the source lightweight application calls a preset encrypted file path and an application identifier of the source lightweight application in a startup function (the startup function will be used to check and read the encrypted file) of the global configuration file when starting to determine the temporary encrypted file in the target storage location of the device.

[0069] In step S704, the encrypted file in the temporary encrypted file is decrypted to obtain decrypted data, and after obtaining the decrypted data, the temporary encrypted file is deleted.

[0070] It should be noted that Figure 7 FIG. 7 is a flowchart of a data sharing method according to the embodiments of the present application, showing a flowchart of the data sharing method when the target lightweight application is the execution subject, including the following steps: Figure 2 The target lightweight application in the data sharing method shown in FIG. 7 is a method executed by the execution subject, and thus Figure 2 The related explanations and descriptions in the data sharing method in FIG. 1 are also applicable to the flowchart of the data sharing method, and will not be repeated here.

[0071] The embodiments of the present application also provide a structural diagram of a data sharing device, as shown in FIG. 8, which includes the following components: Figure 8 The embodiments of the present application also provide a structural diagram of a data sharing device, as shown in FIG. 8, which includes the following components:

[0072] The encryption module 802 is configured to encrypt the data shared by the source lightweight application and the target lightweight application to obtain encrypted data.

[0073] The encryption module 802 is further configured to encrypt the data shared by the source lightweight application and the target lightweight application by using a key pair, wherein the key pair is synchronized to the target lightweight application and the source lightweight application in an offline manner, and the offline manner refers to synchronizing the key pair to the target lightweight application and the source lightweight application without interaction of the target lightweight application and the source lightweight application.

[0074] The creation module 804 is configured to create a temporary encrypted file corresponding to the target lightweight application in a target storage location of a device running the target lightweight application and the source lightweight application.

[0075] The creation module 804 is further configured to obtain an application identifier of the target lightweight application from a registry, wherein the registry is used to at least indicate application identifiers of all lightweight applications allowed to interact by the source lightweight application; obtain a preset encrypted file path in the target storage location; and create the temporary encrypted file according to the application identifier of the target lightweight application and the preset encrypted file path.

[0076] The creation module 804 is further configured to check a remaining storage capacity of the target storage location, and create a target file named according to the application identifier of the target lightweight application under the preset encrypted file path in the target storage location and determine the target file as the temporary encrypted file corresponding to the target lightweight application in a case where the remaining storage capacity is greater than a data size of the encrypted data, wherein file read-write permissions of the temporary encrypted file only include the source lightweight application and the target lightweight application.

[0077] The creation module 804 is further configured to start a retry mechanism to re-create the temporary encrypted file under the preset encrypted file path in the target storage location according to at least a creation failure reason, wherein the retry mechanism at least includes a retry number and a retry interval; and generate an error report in a case where the temporary encrypted file is not successfully created under the preset encrypted file path in the target storage location after starting the retry mechanism, wherein the error report at least includes a timestamp and the creation failure reason.

[0078] The storage module 806 is configured to store the encrypted data into the temporary encrypted file, wherein the temporary encrypted file is used for the target lightweight application to obtain the shared encrypted data.

[0079] The storage module 806 is further configured to start a timing detection task after the encrypted data is stored in the temporary encrypted file, and the timing detection task comprises: detecting whether the temporary encrypted file exists after a preset time length; in a case where the temporary encrypted file exists, deleting the temporary encrypted file and ending the timing detection task, and in a case where the temporary encrypted file does not exist, ending the timing detection task.

[0080] It should be noted that, Figure 8 The data sharing apparatus shown in the data sharing method is configured to perform Figure 2 The data sharing method shown in the data sharing method, therefore Figure 2 The relevant explanations and descriptions in the data sharing method in the data sharing apparatus also apply to the data sharing apparatus, and will not be repeated here.

[0081] It should be noted that each module in the data sharing apparatus described above can be a program module (for example, a set of program instructions that implement a certain specific function) or a hardware module. For the latter, it can be in the following form, but is not limited to this: the form of each module is a processor, or the functions of each module are implemented by a processor.

[0082] The embodiments of the present application also provide a non-volatile storage medium, which comprises a stored program, wherein when the program is running, the non-volatile storage medium controls the device where the non-volatile storage medium is located to perform the data sharing method in any one of the above embodiments.

[0083] The embodiments of the present application also provide an electronic device, which comprises a processor, and the processor is configured to run a program, wherein when the program is running, the electronic device performs the data sharing method in any one of the above embodiments.

[0084] According to another aspect of the embodiments of the present application, a computer program product is also provided, which comprises a computer program, and the computer program is executed by a processor to implement the data sharing method in any one of the above embodiments.

[0085] In the above embodiments of the present application, the description of each embodiment has its own focus, and the parts not described in detail in a certain embodiment can be referred to the relevant description of other embodiments.

[0086] In several embodiments provided in the present application, it should be understood that the disclosed technology can be implemented by other ways. Among them, the above-described device embodiments are only schematic, for example, the division of the units can be a logical function division, and actual implementation can have another division manner, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the displayed or discussed units can be indirect coupling or communication connection through some interfaces, units or modules, and can be electrical or other forms.

[0087] The units described as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, that is, they can be located in one place, or they can be distributed to multiple units. Part or all of the units can be selected according to actual needs to achieve the purpose of the embodiment.

[0088] In addition, the functional units in each embodiment of the present application can be integrated in one processing unit, or each unit can be physically present separately, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of a software functional unit.

[0089] The integrated unit, if realized in the form of a software functional unit and sold or used as an independent product, can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application essentially or the part that contributes to the related art or the whole or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium, including a plurality of instructions for causing a computer device (which can be a personal computer, a server or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The foregoing storage medium includes: a U disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a mobile target storage location, a magnetic disk or an optical disk, and various media that can store program codes.

[0090] The above is only the preferred embodiment of the present application, and it should be pointed out that for ordinary skilled in the art, without departing from the principles of the present application, a number of improvements and refinements can be made, and these improvements and refinements should be considered as the protection scope of the present application.

Claims

1. A data sharing method, characterized in that, include: Encrypt the data shared between the source lightweight application and the target lightweight application to obtain encrypted data; In the target storage location of the device running the target lightweight application and the source lightweight application, create a temporary encrypted file corresponding to the target lightweight application; The encrypted data is stored in the temporary encrypted file, wherein the temporary encrypted file is used by the target lightweight application to obtain the shared encrypted data.

2. The method according to claim 1, characterized in that, The method further includes: After the encrypted data is stored in the temporary encrypted file, a timed detection task is started. The timed detection task includes: checking whether the temporary encrypted file exists after a preset time period. If the temporary encrypted file exists, delete the temporary encrypted file and end the timed detection task; if the temporary encrypted file does not exist, end the timed detection task.

3. The method according to claim 2, characterized in that, The method further includes: the preset duration is adjusted based on the remaining storage capacity of the target storage location of the device and the performance indicators of the device.

4. The method according to claim 1, characterized in that, The step of creating a temporary encrypted file corresponding to the target lightweight application in the target storage location of the device running the target lightweight application and the source lightweight application includes: Obtain the application identifier of the target lightweight application from the registry, wherein the registry is at least used to indicate the application identifiers of all lightweight applications that the source lightweight application is allowed to interact with; Obtain the preset encrypted file path in the target storage location; The temporary encrypted file is created according to the application identifier of the target lightweight application and the preset encrypted file path.

5. The method according to claim 1, characterized in that, The encryption of data shared between the source lightweight application and the target lightweight application includes: Data shared between the source lightweight application and the target lightweight application is encrypted using a key pair. The key pair is synchronized to both the target lightweight application and the source lightweight application offline. The offline method means that the key pair is synchronized to both the target lightweight application and the source lightweight application without any interaction between them.

6. The method according to claim 4, characterized in that, Creating the temporary encrypted file according to the application tag of the target lightweight application and the preset encrypted file path includes: Check the remaining storage capacity of the target storage location. If the remaining storage capacity is greater than the data size of the encrypted data, create a target file named according to the application identifier of the target lightweight application under the preset encrypted file path of the target storage location, and identify the target file as the temporary encrypted file corresponding to the target lightweight application. The file read and write permissions of the temporary encrypted file only include the source lightweight application and the target lightweight application.

7. The method according to claim 6, characterized in that, The method further includes: If the creation of the temporary encrypted file fails at the preset encrypted file path in the target storage location, obtain the reason for the failure. At least based on the stated reason for creation failure, a retry mechanism is initiated to recreate the temporary encrypted file under the preset encrypted file path in the target storage location. The retry mechanism includes at least the number of retries and the retry interval. If the temporary encrypted file is not successfully created under the preset encrypted file path at the target storage location after the retry mechanism is initiated, an error report is generated, wherein the error report includes at least a timestamp and the reason for the creation failure.

8. A data sharing method, characterized in that, include: A temporary encrypted file is determined from the target storage location of the device running the target lightweight application and the source lightweight application, wherein the temporary encrypted file is used to store encrypted data shared between the target lightweight application and the source lightweight application; The encrypted file in the temporary encrypted file is decrypted to obtain the decrypted data, and after obtaining the decrypted data, the temporary encrypted file is deleted.

9. A data sharing device, characterized in that, include: The encryption module is used to encrypt data shared between the source lightweight application and the target lightweight application to obtain encrypted data; A creation module is used to create a temporary encrypted file corresponding to the target lightweight application in the target storage location of the device running the target lightweight application and the source lightweight application; A storage module is used to store the encrypted data into the temporary encrypted file, wherein the temporary encrypted file is used by the target lightweight application to obtain the shared encrypted data.

10. A non-volatile storage medium, characterized in that, The non-volatile storage medium stores a program, wherein when the program is executed, it controls the device where the non-volatile storage medium is located to execute the data sharing method according to any one of claims 1 to 7 or the data sharing method according to claim 8.

11. An electronic device, characterized in that, include: A memory and a processor, the processor being configured to run a program stored in the memory, wherein the program, when running, executes the data sharing method according to any one of claims 1 to 7 or the data sharing method according to claim 8.

12. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the data sharing method according to any one of claims 1 to 7 or the data sharing method according to claim 8.

Images