File sharing method, device, equipment, computer storage medium and program product

Abstract

The application discloses a file sharing method and device, equipment, computer storage medium and program product, and relates to the technical field of big data. The method comprises the following steps: receiving a file uploading request of a target file sent by a file uploading mechanism, wherein the file uploading request comprises a first sender node number of the file uploading mechanism and a first receiver node number of the specified target file; sending a file unique identifier of the target file to the file uploading mechanism; receiving a file downloading request of the target file sent by a file downloading mechanism when the file downloading mechanism obtains the file unique identifier sent by the file uploading mechanism; and returning the target file to the file downloading mechanism based on the file unique identifier when the first receiver node number matches the second sender node number and the first sender node number matches the second receiver node number. According to the application, the overall file sharing reliability and security between different mechanisms can be effectively improved.

Description

Technical Field

[0001] This application belongs to the field of big data technology, and in particular relates to a file sharing method, apparatus, device, computer storage medium and program product. Background Technology

[0002] With the massive growth of internet data and the increasing demand for data resources in various application scenarios, data sharing has become a development trend of the internet. Traditional file transfer solutions often fail to provide secure and reliable file transfer and sharing for point-to-point or network-based file sharing between different business centers and banking institutions.

[0003] Therefore, the industry still urgently needs a new file-sharing solution to accurately and effectively achieve file data sharing between different organizations, thereby improving the stability and security of data transmission. Summary of the Invention

[0004] This application provides a file sharing method, apparatus, device, computer storage medium, and program product, which can more specifically and accurately realize file sharing between different organizations, thereby effectively improving the reliability and security of file sharing between organizations as a whole.

[0005] In a first aspect, embodiments of this application provide a file sharing method applied to a file transfer server, the file sharing method comprising:

[0006] Receive file upload request for target file from file upload organization. The file upload request includes the first sender node number of file upload organization and the first receiver node number of the specified target file.

[0007] Send the unique file identifier of the target file to the file uploading organization;

[0008] Once the file downloading organization obtains the unique file identifier sent by the file uploading organization, it receives the file download request for the target file from the file downloading organization. The file download request includes the unique file identifier, the second sender node number and the second receiver node number of the file downloading organization.

[0009] If the first receiver node number matches the second sender node number, and the first sender node number matches the second receiver node number, the target file is retrieved based on the file's unique identifier, and the target file is returned to the file downloading organization.

[0010] In some possible implementations, the file upload request includes a first encrypted file of the target file and a first business type; before sending the file's unique identifier to the file upload organization, the file sharing method further includes:

[0011] Based on the first session key corresponding to the first business type, the first encrypted file is decrypted to obtain the target file;

[0012] The file download request also includes a second business type specified by the file download organization; the target file is retrieved based on the file's unique identifier, and the target file is returned to the file download organization, including:

[0013] The target file is retrieved based on the file's unique identifier, and the target file is encrypted using the second session key corresponding to the second business type to obtain the second encrypted file. The second encrypted file is then returned to the file downloading organization.

[0014] In some possible implementations, the file's unique identifier is sent to the file upload organization, including:

[0015] The file's unique identifier is encrypted using the first session key to obtain the first encrypted file's unique identifier;

[0016] The unique identifier of the first encrypted file is transmitted to the file uploading organization, which uses the first session key to decrypt the first encrypted file identifier to obtain the unique file identifier.

[0017] The file download request includes a second encrypted file identifier, which is obtained by the file downloading organization from encrypting a unique file identifier based on a second session key; before retrieving the target file based on the file's unique identifier, the file sharing method also includes:

[0018] The second encrypted file identifier is decrypted based on the second session key to obtain the file's unique identifier.

[0019] In some possible implementations, after receiving a file upload request for the target file from a file upload organization, and before decrypting the first encrypted file to obtain the target file, the file sharing method further includes:

[0020] Verify the number of file uploads by the file uploading organization within a preset time period;

[0021] Decrypting the first encrypted file yields the target file, which includes:

[0022] If the number of file uploads does not exceed the first preset threshold, the first encrypted file is decrypted to obtain the target file.

[0023] In some possible implementations, after the target file is retrieved based on its unique file identifier, and before the second encrypted file is returned to the file downloading organization, the file sharing method further includes:

[0024] Verify the number of times the file download organization has downloaded the target file;

[0025] The target file is encrypted using the second session key corresponding to the second business type to obtain the second encrypted file, and the second encrypted file is returned to the file downloading organization, including:

[0026] If the number of file downloads does not exceed the second preset threshold, the target file is encrypted based on the second session key to obtain the second encrypted file, and the second encrypted file is returned to the file downloading organization.

[0027] In some possible implementations, the file upload request also includes a first request timestamp; decrypting the first encrypted file to obtain the target file includes:

[0028] If the time difference between the first request timestamp and the current time of the file transfer server is less than the first preset time difference, the first encrypted file is decrypted to obtain the target file;

[0029] The file download request also includes a second request timestamp; the target file is encrypted based on the second session key corresponding to the second business type to obtain a second encrypted file, including:

[0030] If the time difference between the second request timestamp and the current time of the file transfer server is less than the second preset time difference, the target file is encrypted based on the second session key to obtain the second encrypted file.

[0031] In some possible implementations, before decrypting the first encrypted file to obtain the target file based on the first session key corresponding to the first service type, the file sharing method further includes:

[0032] Digital check-in is performed based on the first sender node number to obtain the first correspondence between the business type and the session key of the file upload organization;

[0033] Based on the first correspondence, determine the first session key corresponding to the first service type;

[0034] Before obtaining the second encrypted file by encrypting the target file based on the second session key corresponding to the second business type, the file sharing method also includes:

[0035] Digital check-in is performed based on the second sender node number to obtain the second correspondence between the business type and the session key of the file download organization;

[0036] Based on the second correspondence, determine the second session key corresponding to the second business type.

[0037] In some possible implementations, the file uploader is also used to generate corresponding first file digest information based on the target file and transmit the first file digest to the file downloader;

[0038] The file download request also includes first file digest information; after obtaining the target file based on the file's unique identifier, the file sharing method also includes:

[0039] Generate a second file digest information corresponding to the current time based on the target file, and compare the first file digest information with the second file digest information;

[0040] Return the target file to the file download provider, including:

[0041] If the first and second file summary information match, return the target file to the file downloading organization.

[0042] In some possible implementations, the file uploading agency is used to: push the file unique identifier to the file downloading agency after receiving the file unique identifier;

[0043] Alternatively, in response to a query request from a document downloading organization, a response corresponding to the query request is returned to the document downloading organization, and the response carries a unique file identifier.

[0044] In some possible implementations, the file is uniquely identified as: the relative path where the target file is stored on the file transfer server, and / or, the file index of the target file's storage location on the file transfer server.

[0045] Based on the same inventive concept, in a second aspect, applied to a file transfer server, embodiments of this application provide a file sharing device, which includes:

[0046] The first receiving module is used to receive a file upload request for a target file from a file upload organization. The file upload request includes the first sender node number of the file upload organization and the first receiver node number of the specified target file.

[0047] The first processing module is used to send the unique file identifier of the target file to the file upload organization;

[0048] The second receiving module is used to receive a file download request for a target file from the file downloading organization when the file downloading organization obtains the unique file identifier sent by the file uploading organization. The file download request includes the unique file identifier, the second sender node number and the second receiver node number of the file downloading organization.

[0049] The second processing module is used to query the target file based on the file's unique identifier, and return the target file to the file downloading organization, provided that the first receiver node number matches the second sender node number and the first sender node number matches the second receiver node number.

[0050] Thirdly, embodiments of this application provide a file sharing device, which includes:

[0051] Processor and memory storing computer program instructions;

[0052] When the processor executes the computer program instructions, it implements the file sharing method provided in any of the embodiments of this application described above.

[0053] Fourthly, embodiments of this application provide a computer storage medium storing computer program instructions, which, when executed by a processor, implement the file sharing method provided in any of the embodiments of this application described above.

[0054] Fifthly, embodiments of this application provide a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to perform a file sharing method as provided in any of the embodiments of this application described above.

[0055] This application provides a file sharing method, apparatus, device, computer storage medium, and program product. A file transfer server acts as an intermediary in both the file upload and download mechanisms. The file transfer server receives file upload requests from the file upload mechanism, including a first sender node number from the file upload mechanism and a first receiver node number for the specified target file. The file transfer server then generates a unique file identifier for the target file and sends it to the file upload mechanism. Upon receiving the unique file identifier from the file download mechanism, the file download mechanism receives the file download request for the target file. If the first receiver node number matches the second sender node number, and vice versa, the file transfer server retrieves the target file based on the unique file identifier and returns it to the file download mechanism.

[0056] As described above, the file-sharing method, apparatus, device, computer storage medium, and program product of this application embodiment facilitates secure mesh file sharing by having the requesting party carry its respective sender node number and receiver node number during upload and download, enabling the file transfer server to record and compare the corresponding information. Therefore, by employing the file-sharing method, apparatus, device, computer storage medium, and program product provided in this application embodiment, stable file sharing between different organizations can be achieved more specifically and accurately, thereby effectively improving the reliability and security of file sharing between organizations as a whole. Attached Figure Description

[0057] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0058] Figure 1 This is a schematic diagram of the architecture of a traditional file sharing scheme provided in an embodiment of this application;

[0059] Figure 2 This is a schematic flowchart of a file sharing method provided in an embodiment of this application;

[0060] Figure 3 This is one of the scenario flow diagrams of a file sharing method provided in an embodiment of this application;

[0061] Figure 4 This is a second schematic diagram of a scenario flow of a file sharing method provided in an embodiment of this application;

[0062] Figure 5 This is a flowchart illustrating the file upload logic of a file transfer server provided in an embodiment of this application;

[0063] Figure 6 This is a flowchart illustrating the file download logic of a file transfer server provided in one embodiment of this application;

[0064] Figure 7 This is a schematic diagram of the file management function of an external file management system provided in an embodiment of this application;

[0065] Figure 8 This is a schematic diagram of the structure of a file sharing device provided in an embodiment of this application;

[0066] Figure 9 This is a schematic diagram of the structure of a file-sharing device provided in an embodiment of this application. Detailed Implementation

[0067] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0068] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0069] It should be noted that the acquisition, storage, use, and processing of data in this application's technical solution all comply with the relevant provisions of national laws and regulations.

[0070] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0071] Currently, housing provident fund services are a key area of ​​focus for housing and urban-rural development. The processing of housing provident fund transactions often involves point-to-point or network-based data sharing between different institutions. For example... Figure 1 As shown, Figure 1 This is a schematic diagram of the architecture of a traditional file-sharing scheme provided in one embodiment of this application. File-uploading institution A (e.g., a housing provident fund service center) may share image file information to file-downloading institution D (e.g., a bank), or file-uploading institution B may share image file information to file-downloading institution D, etc. However, the efficiency of process linkage and file data sharing between housing provident fund management centers and banking institutions in various regions is currently quite low. To overcome the information barriers between local housing provident fund centers and various banking institutions and achieve efficient linkage and data sharing for combined loans, the existing solution is to build a public-bank combined loan system based on the current settlement platform.

[0072] Information sharing in a combined loan system can be achieved through direct transmission of interface messages, but the amount of data that a request message can carry is relatively small. Alternatively, direct file push or querying can be used for file data sharing. However, for shared files with large memory sizes, this method results in long connection times during direct file transfer, and transactions are prone to problems. Furthermore, in real-world business scenarios, the combined loan information that needs to be shared often includes not only small amounts of structured data but also large video or image files related to authorizations and contracts, making online transmission unsuitable for transactions.

[0073] Specifically, traditional file transfer methods typically involve using communication protocols such as FTP (File Transfer Protocol) or HTTP (Hypertext Transfer Protocol) to transfer files over a network. While these methods are widely used, they still have some limitations:

[0074] HTTP protocols are mostly used in web (World Wide Web) systems, while FTP protocols, involving dynamic ports, may be more suitable for file transfers on local area networks (LANs). Both tend to use persistent connections. However, in trading platform systems, trading ports are often opened on demand and cannot support dynamic ports. Short connections are typically used to ensure system security. Furthermore, file transfers in trading platform systems are often business-related and treated as transaction attachments, making the above solutions less suitable. These solutions only support client-to-server file transfers and are insufficient for scenarios where the trading platform acts as a transaction channel between different institutional systems (point-to-point mesh transmission scenarios). Moreover, they cannot guarantee the security and reliability of long-term online transfers of large files in trading scenarios. Using online file transfers under high-concurrency trading conditions will result in high system load and, due to coupling with the trading system, excessive concurrency can easily lead to failures.

[0075] In view of the above, in order to solve the problems of the prior art, embodiments of this application provide a file sharing method, apparatus, device, computer storage medium, and program product. It should be noted that the embodiments provided in this application are not intended to limit the scope of disclosure of this application.

[0076] The file sharing method provided in the embodiments of this application will be introduced first below.

[0077] Figure 2 A schematic flowchart of a file-sharing method according to an embodiment of this application is shown. This file-sharing method is applied to a file transfer server. Figure 1 As shown, the file sharing method includes the following steps:

[0078] S210, Receive a file upload request for a target file from a file upload organization. The file upload request includes the first sender node number of the file upload organization and the first receiver node number of the specified target file.

[0079] S220: Send the unique file identifier of the target file to the file uploading organization;

[0080] S230, when the file downloading organization obtains the unique file identifier sent by the file uploading organization, it receives the file download request for the target file from the file downloading organization. The file download request includes the unique file identifier, the second sender node number and the second receiver node number of the file downloading organization.

[0081] S240: If the first receiver node number matches the second sender node number, and the first sender node number matches the second receiver node number, the target file is obtained based on the file's unique identifier, and the target file is returned to the file downloading organization.

[0082] This application provides a file sharing method in which a file transfer server acts as an intermediary between a file uploader and a file downloader. The file transfer server receives file upload requests from the file uploader, which include a first sender node number from the file uploader and a first receiver node number for the specified target file. The file transfer server then generates a unique file identifier for the target file and sends it to the file uploader. When the file downloader receives the unique file identifier from the file uploader, it receives the file download request for the target file. If the first receiver node number matches the second sender node number, and vice versa, the file transfer server retrieves the target file based on the unique file identifier and returns it to the file downloader.

[0083] As described above, the file-sharing method of this application embodiment facilitates secure mesh file sharing by having the requesting party carry its respective sender node number and receiver node number during upload and download, enabling the file transfer server to record and compare them accordingly. Therefore, by employing the file-sharing method provided in this application embodiment, file sharing between different organizations can be achieved more specifically and accurately, thereby effectively improving the reliability and stability of overall inter-organizational file sharing.

[0084] The specific implementation methods of steps 210 to 240 above are described in detail below.

[0085] In S210, in specific implementation, a file upload request for a target file is received from the file upload organization. The file upload request includes the first sender node number of the file upload organization and the first receiver node number of the specified target file.

[0086] In this embodiment, a file upload request for the target file is received from the file upload organization by using communication protocols such as FTP (File Transfer Protocol) or HTTP (Hypertext Transfer Protocol).

[0087] The target files mentioned above include image files, video files, or other text files, and this embodiment does not impose strict limitations on them.

[0088] The file upload request includes the first sender node number of the file uploading organization and the first receiver node number of the specified target file. The file upload request may directly include the plaintext or encrypted version of the target file, or its storage address, etc., without strict limitations.

[0089] The aforementioned first sender node number may be the organization code, organization number, etc. of the file upload organization, and the aforementioned first receiver node number may be the organization code or organization number of at least one file download organization designated by the file upload organization that is allowed to share the target file. This application does not impose strict restrictions on these.

[0090] In S220, the unique file identifier of the target file is sent to the file upload organization.

[0091] For example, if the file upload request includes a plaintext version of the target file, the file transfer server can directly obtain the target file from the file upload request. In this case, the file transfer server stores the target file, generates a unique file identifier for the target file, and then returns the unique file identifier to the file upload provider.

[0092] To ensure accurate retrieval of the target file based on the aforementioned unique file identifier, the unique file identifier can specifically be: the relative path of the target file stored on the file transfer server, and / or, the file index of the target file's storage location on the file transfer server.

[0093] It should be added that, in the above file upload request, if the target file is encrypted, the encrypted file can also be decrypted according to the agreed encryption / decryption method to obtain the plaintext target file. In this case, the file transfer server stores the target file, generates a unique file identifier for the target file, and then returns the unique file identifier to the file uploader. This embodiment does not impose strict limitations on this.

[0094] In S230, in specific implementation, after the file downloading organization obtains the unique file identifier sent by the file uploading organization, it receives the file download request for the target file from the file downloading organization. The file download request includes the unique file identifier, the second sender node number and the second receiver node number of the file downloading organization.

[0095] The aforementioned second sender node number may be the organization code, organization number, etc. of the aforementioned file downloading organization, and the aforementioned second receiver node number may be the organization code or organization number of the aforementioned file uploading organization, etc. This application does not impose strict restrictions here.

[0096] According to some embodiments of this application, optionally, in combination with the actual business transaction processing needs between different structures, the document uploading agency can be used to: push the document unique identifier to the document downloading agency after receiving the document unique identifier;

[0097] Alternatively, in response to a query request from a document downloading organization, a response corresponding to the query request is returned to the document downloading organization, and the response carries a unique file identifier.

[0098] In other words, after receiving the unique file identifier from the file transfer server, the file uploading organization can either push the file identifier to the file downloading organization in an actual business transaction scenario, or, when the file downloading organization has a corresponding information query request, package the file identifier along with the required response information and send it together. In this way, the file identifier can be transmitted to the file downloading organization simply through routine transactions, and the file downloading organization, upon receiving the file identifier, determines whether to send a download request to the file transfer server based on its actual file needs.

[0099] In this embodiment, considering the high concurrency of business interactions and transactions between institutions, the transmission of file unique identifiers is selected for business transaction scenarios with high processing time requirements and unable to support online transmission of large files. The transmission of file unique identifiers is isolated and decoupled from the transmission of target files to avoid mutual interference and effectively reduce the information load on the transaction system and file transfer server.

[0100] In S240, in specific implementation, if the first receiving node number matches the second sending node number, and the first sending node number matches the second receiving node number, the target file is obtained based on the file's unique identifier, and the target file is returned to the file downloading organization.

[0101] In this embodiment, the second sender node number and the second receiver node number of the file download organization are obtained by parsing the above file download request. Then, the first receiver node number and the second sender node number are compared to see if they match, and the first sender node number and the second receiver node number are compared to see if they match.

[0102] If the first receiving node number matches the second sending node number, and vice versa, the file downloading organization is determined to be qualified to download the target file. Thus, based on the sending and receiving node numbers carried by the requester during upload and download, the file transfer server records and compares them accordingly, thereby achieving secure mesh-like file sharing.

[0103] If the verification node number matches, the target file is retrieved based on the unique file identifier in the file download request, and then the target file is returned to the file download organization.

[0104] It should be understood that the plaintext version of the target file can be directly sent to the file download provider. Alternatively, to effectively ensure file security, the file transfer server can also encrypt the target file before sending it to the file download provider; this is not strictly limited.

[0105] Optionally, according to some embodiments of this application, in order to fully ensure the security of file data, the above-mentioned file upload request includes a first encrypted file of the target file and a first business type; before sending the file unique identifier of the target file to the file upload organization, the file sharing method further includes:

[0106] Based on the first session key corresponding to the first business type, the first encrypted file is decrypted to obtain the target file;

[0107] The file download request also includes a second business type specified by the file download organization; the target file is retrieved based on the file's unique identifier, and the target file is returned to the file download organization, including:

[0108] The target file is retrieved based on the file's unique identifier, and the target file is encrypted using the second session key corresponding to the second business type to obtain the second encrypted file. The second encrypted file is then returned to the file downloading organization.

[0109] The aforementioned file upload organization can pre-agree with the file upload structure on session keys corresponding to different business types. Before uploading a file, the file upload organization first encrypts the target file according to the first session key corresponding to the first business type, and then transmits the encrypted file, thereby ensuring the security of file transmission and effectively reducing the possibility of transmitted data being maliciously intercepted and tampered with, leading to information leakage and security risks. The encryption method can be, for example, DESede (3DES) symmetric key.

[0110] In practice, the file transfer server parses the file upload request to obtain the first service type carried in the request, and then decrypts the first encrypted file based on the first session key corresponding to the first service type to obtain the target file, and stores the decrypted target file.

[0111] After storing the target file, the file transfer server generates a unique file identifier for the target file and then returns the unique file identifier to the file uploader.

[0112] Accordingly, after the file transfer server receives a file download request from the file download provider, if the target file is found based on its unique file identifier, the server can encrypt the target file using the second session key corresponding to the second service type to obtain a second encrypted file, which is then returned to the file download provider. This ensures that the transmitted data is not easily tampered with and maintains data security. Upon receiving the second encrypted file, the file download provider can decrypt it using the second session key to obtain the plaintext data of the shared target file.

[0113] The encryption method may include, for example, DESede (3DES) symmetric key. The second session key is the session key corresponding to the second business type pre-agreed upon by the file downloading organization.

[0114] In this embodiment of the application, the files transmitted during the communication between the file transfer server and the file uploader or file downloader are all encrypted files. The file transfer server decrypts the files using the first session key corresponding to the service type requested by the file uploader. When downloading files, in order to fully ensure the secure download and transmission of shared files, the file transfer server also encrypts the files using the second session key corresponding to the service type requested by the file downloader before returning the encrypted files to the file downloader.

[0115] In this way, by encrypting and protecting the data during the file upload and download process, and by obtaining the corresponding session key based on the business type carried in the request to decrypt the uploaded file or encrypt the file before downloading, the security of the file data can be fully guaranteed.

[0116] Optionally, according to some embodiments of this application, in order to further ensure reliable data transmission, sending the unique file identifier of the target file to the file upload organization may include:

[0117] The file's unique identifier is encrypted using the first session key to obtain the first encrypted file's unique identifier;

[0118] The unique identifier of the first encrypted file is transmitted to the file uploading organization, which uses the first session key to decrypt the first encrypted file identifier to obtain the unique file identifier.

[0119] The file download request may include a second encrypted file identifier, which is obtained by the file downloading organization from encrypting a unique file identifier based on a second session key; before retrieving the target file based on the file identifier, the file sharing method may also include:

[0120] The second encrypted file identifier is decrypted based on the second session key to obtain the file's unique identifier.

[0121] In this embodiment, after the file transfer server generates the file unique identifier of the target file, it encrypts the file unique identifier according to the first session key specified by the file uploader before transmitting it, thereby fully ensuring the reliability of the file unique identifier returned to the file uploader. After receiving the first encrypted file identifier, the file uploader decrypts it according to the first session key to obtain the plaintext data of the file unique identifier.

[0122] After the file uploading organization transmits the file's unique identifier to the file downloading organization, to ensure the reliability of the file unique identifier received by the file transfer server, it will encrypt the file unique identifier using the second session key before transmitting it, just like before sending a file download request. Upon receiving the encrypted file identifier, the file transfer server will decrypt it using the second session key corresponding to the second business type in the file download request, thus obtaining the plaintext data of the file unique identifier for subsequent target file retrieval. This fully ensures the data security and reliability of the target file's unique identifier during data transmission.

[0123] According to some embodiments of this application, optionally, in order to fully ensure the accurate and effective sharing of the target file, the file uploading agency is also used to generate corresponding first file summary information based on the target file and transmit the first file summary to the file downloading agency;

[0124] The file download request may also include first file digest information; after obtaining the target file based on the file's unique identifier, the file sharing method may also include:

[0125] Generate a second file digest information corresponding to the current time based on the target file, and compare the first file digest information with the second file digest information;

[0126] The above-mentioned return of the target file to the file download provider may include:

[0127] If the first and second file summary information match, return the target file to the file downloading organization.

[0128] In this embodiment, the file uploading organization can generate a first digest of the target file in advance, using a digest generation method such as the MD5 (Message Digest Algorithm 5) cryptographic hash function. Then, after receiving the unique file identifier from the file transfer server, the file uploading organization can send the unique file identifier and the first file digest to the file downloading organization.

[0129] In this way, when sending a file download request, the file downloading organization can package the file's unique identifier and the first file digest information together in the file download request and send it to the file transfer server. After the file transfer server finds the target file based on the file's unique identifier, it can generate the second file digest information of the found target file using the same file digest generation method.

[0130] Next, the second file summary information is compared with the first file summary information. If the verification matches, it means that the target file is safe, reliable and has not been tampered with. In this case, the target file is returned to the file downloading organization.

[0131] It should be added that, in some embodiments, the first file digest information of the target file can be uploaded along with the file upload request. This first file digest information can then be used to verify whether the uploaded file is a duplicate.

[0132] In some more specific embodiments, in conjunction with the foregoing embodiments of encrypting data to ensure data security, the aforementioned encryption of the target file based on the second session key corresponding to the second service type to obtain the second encrypted file may include:

[0133] If the first file digest information and the second file digest information are consistent, the target file is encrypted based on the second session key to obtain the second encrypted file.

[0134] In this way, by verifying that the first file digest information and the second file digest information are consistent before encryption, unnecessary encryption operations on the target file by the file transfer server can be effectively avoided, thereby effectively saving server resources.

[0135] Optionally, according to some embodiments of this application, to fully ensure the performance stability of the file transfer server, after receiving the file upload request for the target file from the file upload institution and before decrypting the first encrypted file to obtain the target file, the file sharing method may further include:

[0136] Verify the number of file uploads by the file uploading organization within a preset time period;

[0137] Decrypting the first encrypted file to obtain the target file can include:

[0138] If the number of file uploads does not exceed the first preset threshold, the first encrypted file is decrypted to obtain the target file.

[0139] In this embodiment, by verifying the recent number of file uploads by the file upload organization, the problem of frequent file uploads due to system failures of the file upload organization, which could lead to excessive uploads and cause the file transfer server system to crash, is avoided. At the same time, it also helps to avoid unnecessary occupation of file transfer server resources.

[0140] Optionally, according to some embodiments of this application, for reasons similar to those in the foregoing embodiments, in order to ensure the stability of the data transmission load of the file transfer server, after the target file is obtained based on the file's unique identifier, and before returning the second encrypted file to the file downloading organization, the file sharing method may further include:

[0141] Verify the number of times the file download organization has downloaded the target file;

[0142] The process of encrypting the target file using the second session key corresponding to the second business type to obtain a second encrypted file and returning the second encrypted file to the file downloading organization may include:

[0143] If the number of file downloads does not exceed the second preset threshold, the target file is encrypted based on the second session key to obtain the second encrypted file, and the second encrypted file is returned to the file downloading organization.

[0144] In this embodiment, by verifying the number of times the file downloading organization downloads the target file, the excessive use of data processing resources on the file transfer server caused by the high frequency of downloading the same target file by the file downloading organization is avoided, which helps to reduce the occurrence of file transfer server overload.

[0145] Optionally, according to some embodiments of this application, in order to fully verify the validity of the request and to fully avoid unnecessary resource usage caused by the file transfer server processing outdated requests, the file upload request may further include a first request timestamp; decrypting the first encrypted file to obtain the target file may include:

[0146] If the time difference between the first request timestamp and the current time of the file transfer server is less than the first preset time difference, the first encrypted file is decrypted to obtain the target file;

[0147] The file download request may also include a second request timestamp; encrypting the target file based on the second session key corresponding to the second business type to obtain a second encrypted file may include:

[0148] If the time difference between the second request timestamp and the current time of the file transfer server is less than the second preset time difference, the target file is encrypted based on the second session key to obtain the second encrypted file.

[0149] The aforementioned first preset time difference is, for example, 5 seconds, and the second preset time difference is, for example, 10 seconds, etc., but this embodiment does not strictly limit these values. The aforementioned first request timestamp can be the time when the file upload organization sends the file upload request, and the second request timestamp can be the time when the file download organization sends the file download request. In this embodiment, by verifying the time difference of request reception, the timeliness of the current request processing is fully guaranteed.

[0150] Optionally, according to some embodiments of this application, in order to more effectively ensure the security of files during file transfer based on session keys, before decrypting the first encrypted file based on the first session key corresponding to the first service type to obtain the target file, the file sharing method may further include:

[0151] Digital check-in is performed based on the first sender node number to obtain the first correspondence between the business type and the session key of the file upload organization;

[0152] Based on the first correspondence, determine the first session key corresponding to the first service type;

[0153] Before obtaining the second encrypted file by encrypting the target file based on the second session key corresponding to the second business type, the file sharing method may also include:

[0154] Digital check-in is performed based on the second sender node number to obtain the second correspondence between the business type and the session key of the file download organization;

[0155] Based on the second correspondence, determine the second session key corresponding to the second business type.

[0156] In practice, each organization sets different session keys for different business types. The file transfer server can pre-agree with each organization on the session keys corresponding to the business types. Thus, after a file upload organization sends a file upload request, the file transfer server can use the first sender node number of the file upload organization in the file upload request to query and obtain the first correspondence between the business type and the session key corresponding to that file upload organization. Based on this first correspondence, the first session key corresponding to the first business type can be determined.

[0157] Accordingly, after the file downloading organization sends a file download request, the file transfer server can query and obtain the second correspondence between the business type and the session key corresponding to the file downloading organization based on the second sender node number of the file downloading organization carried in the file download request. In this way, the second session key corresponding to the second business type can be determined based on the second correspondence.

[0158] In this embodiment, the correspondence between the business types and session keys set by different organizations is different. This can effectively ensure the uniqueness of the encryption and decryption session keys between each organization and the file transfer server, thereby ensuring the high isolation and sharing security of file data between each organization in the file transfer server.

[0159] To facilitate understanding of the file sharing method provided in the above embodiments, the following describes the method using a specific scenario embodiment. Figure 3 This is one of the schematic flowcharts of a scenario embodiment of the file sharing method provided in this application. Figure 4 This is a second schematic flowchart of a scenario embodiment of the file sharing method provided in this application.

[0160] The application scenario of this embodiment can be as follows: the file uploading institution can be a housing provident fund center, and the file downloading institution can be a commercial bank. In business transaction scenarios, the housing provident fund center and the commercial bank can forward transaction information through a combined loan system. This combined loan system is isolated from the file transfer server added in this application to achieve decoupling of business transactions and file sharing and transmission.

[0161] In response to the current situation where point-to-point and network-based file sharing between different housing provident fund centers and different commercial banks cannot provide secure and reliable file transmission and sharing, this scenario embodiment builds a file transfer server (file server) as a file transmission network relay station to solve the problem of secure, stable and efficient file transmission and sharing between various housing provident fund centers and various commercial banks in such network-based file sharing.

[0162] Regarding the combined loan process, during the information sharing phase of a combined housing provident fund and commercial loan application, either party can initiate the loan application process. Once accepted, the application information is shared with the other party. There are two methods of sharing: proactively pushing application information and passively querying application information.

[0163] 1. Please see Figure 3 Example of push mode in China:

[0164] After compressing the target files, such as the image information files to be shared, into a zip (Zipped) archive, the Housing Provident Fund Center generates a first file digest. Simultaneously, it encrypts the target files using a first session key corresponding to the first business type and then calls the file server's upload interface to send a request. Upon receiving the upload request, the file transfer server performs corresponding digest verification and file decryption processes, stores the decrypted target files, generates a unique identifier for the target files, encrypts the unique identifier according to the first session key, and finally uploads the encrypted unique identifier to the file server.

[0165] Subsequently, the Housing Provident Fund Center proactively pushes the loan application materials to the commercial bank through the combined loan system, including the unique identifier of the shared target document and the summary information of the first document. The combined loan system performs tasks such as verifying the legality of the request, recording the request process, and forwarding information according to the normal business transaction processing flow.

[0166] Commercial banks obtain the unique identifier and first file digest information of the file transmitted by the housing provident fund center. They then send a file download request, including the encrypted unique identifier and first file digest information, to the file transfer server to download the shared image file information. Upon receiving the download request, the file transfer server decrypts the unique identifier and other information using the corresponding bank node session key (second session key) and verifies the request timestamp and download count. If the verification is successful, the target file is retrieved using the unique identifier, and a second file digest information is generated for the retrieved target file. This is then compared with the first and second file digest information. If the digest information verification is successful and the file exists, the encrypted file stream of the target file is returned to the commercial bank. At this point, the shared image information exchange initiated by the housing provident fund center is completed.

[0167] 2. Please see Figure 4 Pull mode example:

[0168] After compressing the target files, such as the image information files to be shared, into a zip archive, the Housing Provident Fund Center generates a first file digest. Simultaneously, it encrypts the target files using a first session key corresponding to the first business type and then calls the file server's upload interface to send a request. Upon receiving the upload request, the file transfer server performs corresponding digest verification and file decryption, stores the decrypted target files, generates a unique identifier for the target files, encrypts the unique identifier according to the first session key, and finally uploads the encrypted unique identifier to the file server.

[0169] Subsequently, the commercial bank proactively inquired about loan application materials from the housing provident fund center through the combined loan system. The housing provident fund center returned the query results, including the unique file identifier of the shared image file and the first file summary information. During this process, the combined loan system performed tasks such as verifying the legality of the request, recording the request process, and forwarding information according to the normal business transaction processing procedures.

[0170] The commercial bank obtains the unique identifier and first file digest information of the file transmitted by the housing provident fund, and then sends a file download request, including the encrypted unique identifier and first file digest information, to the file transfer server to download the shared image file information. Upon receiving the file download request, the file transfer server decrypts the unique identifier and other information according to the corresponding bank node session key (second session key), and verifies the request timestamp and download count. If the verification is successful, the target file is obtained through the unique identifier, and a second file digest information of the obtained target file is generated. The first and second file digest information are then compared. If the digest information verification is successful and the file exists, the encrypted file stream of the target file is returned to the commercial bank. Thus, the shared image information exchange initiated by the commercial bank is completed.

[0171] The combined push and pull modes of loan image file sharing both achieve secure file sharing through a network-based file transfer relay station (file transfer server). This embodiment ensures the security of network-based file sharing between the housing provident fund center and multiple commercial banks, as well as between commercial banks and multiple housing provident fund centers.

[0172] Furthermore, it's important to note that when a housing provident fund center requests to upload shared files or a commercial bank requests to download shared files, both the sender's node number and the receiver's node number must be included. The file server records file transfer information during upload and download. The receiver's node number specified during upload determines the institution from which the file can be downloaded. For example, in push and pull modes, when the housing provident fund center uploads a file, the receiver's node number must match the node number of the corresponding commercial bank. Similarly, when a commercial bank downloads a file, it also includes the sender's node number. The file server then uses this node number and file identifier to retrieve the shared image file and complete the download. In this way, by recording and comparing the sender's and receiver's node numbers during upload and download, the file transfer server achieves secure mesh-like file sharing.

[0173] To better understand the working logic of the file transfer server after receiving a file upload request in the embodiments of this application, please refer to [link to relevant documentation]. Figure 5 , Figure 5This is a flowchart illustrating the file upload logic of a file transfer server provided in one embodiment of this application. Figure 5 The complete file upload processing logic flow of the file transfer server shown includes steps 510 to 560:

[0174] S510 receives file upload requests from file upload organizations;

[0175] S520: Obtain the first session key for check-in based on the first sender node number and service type;

[0176] S530, verify the number of file uploads by the file upload organization;

[0177] S540, verify the time difference between the first request timestamp and the current time of the file transfer server;

[0178] S550: Decrypt the first encrypted file using the first session key to obtain the target file;

[0179] S560 generates a unique file identifier for the target file and encrypts it based on the first session key, then returns the encrypted first unique file identifier to the file uploading organization.

[0180] It is understood here that the specific implementation methods of steps 510 to 560 have been described in detail in the foregoing embodiments. For the sake of brevity, the specific implementation of the above steps will not be repeated here.

[0181] It should be added that, during file upload: the file upload organization uses the HTTP POST method to transmit the file upload request to the address corresponding to the file transfer server. This file upload request carries the first encrypted file of the target file to be shared, the first business type, the first sender node number of the file upload organization, and the first receiver node number of the specified target file.

[0182] File transfer can also be achieved using communication methods such as FTP, SFTP (Secure File Transfer Protocol), or SCP (Secure Copy Protocol).

[0183] The first business type can be the HTTP request header parameter TxCode, for example, business type 10 when uploading data files for a combined loan business. The first sender node number can be, for example, the HTTP request header parameter SendNode. The first receiver node number can be, for example, the HTTP request header parameter ReceiveNode. In some other embodiments, the file upload request may also include a sender sequence number: i.e., the HTTP request header parameter SendSeqNo.

[0184] Furthermore, before uploading files, business files should be organized according to the business interface agreement and compressed and encrypted (using DESede (3DES) symmetric key encryption). The compressed file format should be uniformly set to zip, and the naming convention should also follow the business interface agreement. Finally, the compressed and encrypted files should be uploaded. In practical scenarios, to fully ensure file transmission security, each file uploading organization should only upload one file at a time, and unless otherwise agreed upon by the business, the uploaded file should not exceed 50MB. Additionally, to ensure the availability of memory resources on the file transfer server, a retention period can be set on the file server after shared files are uploaded, for example, setting the retention period to only 7 days after upload to effectively avoid long-term unreasonable occupation of memory resources.

[0185] After receiving a file upload request, the file transfer server returns the corresponding file upload result to the file upload provider. This result can be in byte stream format, and the returned result information is character-encoded. Both successful and failed uploads will return the following result information: "Upload Result | Error Code | Error Message | Unique File Identifier (e.g., relative path)". Furthermore, the returned file upload result can be encrypted using a DESede (3DES) symmetric key.

[0186] The upload result will be either SUCCESS or FAIL. If the upload result is SUCCESS, the error code and error message will be empty, but the file's unique identifier will not be empty; if the upload result is FAIL, the error code and error message will not be empty, but the file's unique identifier will be empty. For example, a successful file upload result might be: "SUCCESS|||20140723 / 440106198595270330.DAT". A failed file upload result might be: "FAIL|0001|File upload error|".

[0187] The unique identifier of the aforementioned file may be a relative path stored on the file transfer server, or it may be a file index indicating the file storage location. This scenario embodiment does not impose strict limitations.

[0188] Corresponding to the file upload processing logic, to better understand the working logic of the file transfer server after receiving a file download request in the embodiments of this application, please refer to... Figure 6 , Figure 6 This is a flowchart illustrating the file download logic of a file transfer server provided in one embodiment of this application. Figure 6 The complete file download processing logic flow of the file transfer server shown includes steps 610 to 670:

[0189] S610 receives file download requests from file download organizations;

[0190] S620: Obtain the second session key for check-in based on the second sender node number and the second service type in the file download request;

[0191] S630, use the second session key to decrypt the second encrypted file unique identifier in the file download request to obtain the file unique identifier;

[0192] S640, verify the time difference between the second request timestamp and the current time of the file transfer server;

[0193] S650: Query the target file based on the file's unique identifier, and compare the current second file digest information of the target file with the first file digest information in the file download request;

[0194] S660, verifies the number of times a file download organization has downloaded the target file;

[0195] S670: Use the second session key to encrypt the target file to obtain a second encrypted file, and return the second encrypted file to the file downloading organization.

[0196] It is understood here that the specific implementation methods of steps 610 to 670 have been described in detail in the foregoing embodiments. For the sake of brevity, the specific implementation of the above steps will not be repeated here.

[0197] It should be added that, during file download: the file downloading organization uses the HTTP POST method to transmit the file download request to the address corresponding to the file transfer server. This file download request carries a unique file identifier encrypted with a second session key, first file digest information, second service type, and the file downloading organization's second sender node number and second receiver node number.

[0198] The second business type can be the HTTP request header parameter TxCode. The second sender node number can be, for example, the HTTP request header parameter SendNode. The second receiver node number can be, for example, the HTTP request header parameter ReceiveNode. In some other embodiments, the file download request may also include a sender sequence number, i.e., the HTTP request header parameter SendSeqNo.

[0199] Furthermore, before downloading files, business files should be organized according to the business interface agreement and compressed and encrypted (using DESede (3DES) symmetric key encryption). The compressed file format should be uniformly set to zip, and the naming convention should also follow the business interface agreement. Finally, the compressed and encrypted files should be downloaded. In practical scenarios, to fully ensure file transfer security, each file downloading organization should only download one file at a time. Additionally, to ensure the availability of memory resources on the file transfer server, the retention period for downloaded shared files can be set on the file server, for example, setting the retention period to only 7 days after download to effectively avoid long-term unreasonable occupation of memory resources.

[0200] After receiving a file download request, the file transfer server returns the corresponding download result to the file download provider. This result can be a byte stream, and the returned information is character-encoded. If the shared target file exists and is read correctly, an encrypted file byte stream is returned directly. If an error occurs during the download, relevant error codes and information are returned to the file download provider. The returned download result information is encoded in UTF-8 and can also be encrypted using a DESede (3DES) symmetric key.

[0201] In addition, to fully realize the operation and maintenance management of the file transfer server, it can also be maintained through an external system. Please see [link to relevant documentation]. Figure 7 , Figure 7 This is a schematic diagram of the file management function of an external file management system provided in an embodiment of this application. In this embodiment, the combined loan system involved in the aforementioned scenario embodiment can be used to effectively manage the shared file function in the file transfer server.

[0202] This combined loan system provides web-based functionality for managing file transfer servers, enabling file service administrators to easily select files, control transfers, and monitor progress. The system offers web-based file transfer management, supporting file transfer records and download details queries. It also includes maintenance functions such as resetting upload flags and download counts for the file transfer server.

[0203] In summary, this application's embodiments address the need for file information sharing in a combined loan system, resolving the inability of traditional file transfer schemes to ensure the security of point-to-point and mesh file transfers, and providing better transmission control and monitoring. This application's embodiments record and compare the sender's node number and receiver's node number carried by the requester during upload and download, thereby achieving secure mesh file sharing. Furthermore, this application's embodiments configure the file transfer server to avoid online transmission, isolating transactions from file transfers and preventing mutual interference.

[0204] In this application embodiment, the sign-in information of the organization is verified during file upload and download. For file uploads, the file is also encrypted using the session password of the uploading organization with a DESede (3DES) symmetric key, and a DM5 digest of the file is also sent. The file transfer server compares the uploaded file with the file digest; the file transfer server also compares the request timestamp when the file is uploaded; after a successful file download, an encrypted (DESede (3DES) symmetric key encrypted) file byte stream is obtained, thereby ensuring the security of the file data and fully guaranteeing the reliability and integrity of the data.

[0205] Based on the file sharing method provided in the above embodiments, and with the same inventive concept, this application also provides a file sharing device corresponding to the above file sharing method. The following describes... Figure 8 A detailed introduction to file sharing devices is provided.

[0206] Figure 8 A schematic diagram of a file sharing device provided in an embodiment of this application is shown, which is applied to a file transfer server. Figure 8 The file-sharing device 800 shown includes:

[0207] The first receiving module 810 is used to receive a file upload request for a target file from a file upload organization. The file upload request includes the first sender node number of the file upload organization and the first receiver node number of the specified target file.

[0208] The first processing module 820 is used to send the unique file identifier of the target file to the file upload organization;

[0209] The second receiving module 830 is used to receive a file download request for a target file from the file downloading organization when the file downloading organization obtains the unique file identifier sent by the file uploading organization. The file download request includes the unique file identifier, the second sending node number and the second receiving node number of the file downloading organization.

[0210] The second processing module 840 is used to query the target file based on the file's unique identifier, and return the target file to the file downloading organization, provided that the first receiving node number matches the second sending node number and the first sending node number matches the second receiving node number.

[0211] This application provides a file sharing device applied to a file transfer server. This device, through the configuration of corresponding functional modules, receives file upload requests from file upload organizations. The file upload request includes a first sender node number of the file upload organization and a first receiver node number of the specified target file. The file transfer server then generates a unique file identifier for the target file and sends it to the file upload organization. Upon receiving the unique file identifier from the file download organization, the file download server receives the file download request for the target file. If the first receiver node number matches the second sender node number, and the first sender node number and the second receiver node number also match, the file transfer server retrieves the target file based on the unique file identifier and returns it to the file download organization.

[0212] As described above, the file-sharing device of this application embodiment facilitates secure mesh file sharing by having the requesting party carry its own sender node number and receiver node number during upload and download, enabling the file transfer server to record and compare them accordingly. Therefore, by employing the file-sharing device provided in this application embodiment, file sharing between different organizations can be achieved more specifically and accurately, thereby effectively improving the reliability and security of overall inter-organizational file sharing.

[0213] According to some embodiments of this application, optionally, in some possible implementations, the file upload request includes a first encrypted file of the target file and a first business type; before sending the file unique identifier of the target file to the file upload agency, the file sharing device method further includes:

[0214] The first decryption module can be used to decrypt the first encrypted file to obtain the target file based on the first session key corresponding to the first business type.

[0215] The file download request also includes a second business type specified by the file download organization; the above-mentioned query based on the file's unique identifier to obtain the target file and return the target file to the file download organization includes:

[0216] The target file is retrieved based on the file's unique identifier, and the target file is encrypted using the second session key corresponding to the second business type to obtain the second encrypted file. The second encrypted file is then returned to the file downloading organization.

[0217] According to some embodiments of this application, optionally, sending the file unique identifier of the target file to the file uploading organization may include:

[0218] The file's unique identifier is encrypted using the first session key to obtain the first encrypted file's unique identifier;

[0219] The unique identifier of the first encrypted file is transmitted to the file uploading organization, which uses the first session key to decrypt the first encrypted file identifier to obtain the unique file identifier.

[0220] The file download request may include a second encrypted file identifier, which is obtained by the file downloading organization from encrypting a unique file identifier based on a second session key; before retrieving the target file based on the unique file identifier, the file sharing device may further include:

[0221] The second decryption module can be used to decrypt the second encrypted file identifier based on the second session key to obtain the file's unique identifier.

[0222] According to some embodiments of this application, optionally, after receiving a file upload request for a target file from a file upload organization, and before decrypting the first encrypted file to obtain the target file, the file sharing device may further include:

[0223] The first verification module can be used to verify the number of times a file uploader has uploaded files within a preset time period;

[0224] The decryption of the first encrypted file to obtain the target file can include:

[0225] If the number of file uploads does not exceed the first preset threshold, the first encrypted file is decrypted to obtain the target file.

[0226] According to some embodiments of this application, optionally, after the target file is obtained based on the file's unique identifier, and before returning the second encrypted file to the file downloading organization, the file sharing device may further include:

[0227] The second verification module can be used to verify the number of times a file downloader has downloaded a target file;

[0228] The above-mentioned method of encrypting the target file based on the second session key corresponding to the second service type to obtain the second encrypted file, and returning the second encrypted file to the file downloading organization, may include:

[0229] If the number of file downloads does not exceed the second preset threshold, the target file is encrypted based on the second session key to obtain the second encrypted file, and the second encrypted file is returned to the file downloading organization.

[0230] According to some embodiments of this application, optionally, the file upload request may further include a first request timestamp; the above-mentioned decryption of the first encrypted file to obtain the target file may include:

[0231] If the time difference between the first request timestamp and the current time of the file transfer server is less than the first preset time difference, the first encrypted file is decrypted to obtain the target file;

[0232] The file download request may also include a second request timestamp; the above-mentioned encryption of the target file based on the second session key corresponding to the second business type to obtain the second encrypted file may include:

[0233] If the time difference between the second request timestamp and the current time of the file transfer server is less than the second preset time difference, the target file is encrypted based on the second session key to obtain the second encrypted file.

[0234] Optionally, according to some embodiments of this application, before decrypting the first encrypted file to obtain the target file based on the first session key corresponding to the first service type, the file sharing device may further include:

[0235] The first acquisition module can be used to perform digital check-in based on the first sender node number and obtain the first correspondence between the business type and the session key corresponding to the file upload organization.

[0236] The first determining module can be used to determine the first session key corresponding to the first service type based on the first correspondence relationship;

[0237] Before obtaining the second encrypted file by encrypting the target file based on the second session key corresponding to the second service type, the file sharing device may further include:

[0238] The second acquisition module can be used to perform digital check-in based on the second sender node number and obtain the second correspondence between the business type and the session key of the file download organization.

[0239] The second determining module can be used to determine the second session key corresponding to the second service type based on the second correspondence.

[0240] According to some embodiments of this application, optionally, the file uploading agency is further configured to generate corresponding first file digest information based on the target file, and transmit the first file digest to the file downloading agency;

[0241] The file download request may also include first file summary information; after the target file is obtained based on the file's unique identifier, the file sharing device may further include:

[0242] The first comparison module can be used to generate second file summary information corresponding to the current time based on the target file, and compare the first file summary information and the second file summary information.

[0243] The above-mentioned return of the target file to the file download provider may include:

[0244] If the first and second file summary information match, return the target file to the file downloading organization.

[0245] According to some embodiments of this application, optionally, the above-mentioned file uploading agency can be used to: push the file unique identifier to the file download agency after receiving the file unique identifier;

[0246] Alternatively, in response to a query request from a document downloading organization, a response corresponding to the query request is returned to the document downloading organization, and the response carries a unique file identifier.

[0247] According to some embodiments of this application, optionally, the above-mentioned unique file identifier can be: the relative path where the target file is stored on the file transfer server, and / or, the file index of the storage location of the target file on the file transfer server.

[0248] Based on the file sharing method provided in the above embodiments, and with the same inventive concept, this application also provides a file sharing device corresponding to the above file sharing method. The following describes... Figure 9 A detailed introduction to file sharing devices.

[0249] Please see below. Figure 9 , Figure 9 This is a schematic diagram of the structure of a file-sharing device provided in an embodiment of this application.

[0250] The file-sharing device may include a processor 901 and a memory 902 storing computer program instructions.

[0251] Specifically, the processor 901 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0252] Memory 902 may include mass storage for data or instructions. For example, and not limitingly, memory 902 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 902 may include removable or non-removable (or fixed) media. Where appropriate, memory 902 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 902 is non-volatile solid-state memory.

[0253] Memory may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, and electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the methods according to one aspect of this disclosure.

[0254] The processor 901 implements any of the file sharing methods described in the above embodiments by reading and executing computer program instructions stored in the memory 902.

[0255] In one example, the data file sharing device may also include a communication interface 903 and a bus 910. For example, Figure 9 As shown, the processor 901, memory 902, and communication interface 903 are connected through bus 910 and complete communication with each other.

[0256] The communication interface 903 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0257] Bus 910 includes hardware, software, or both, that couples components of a file-sharing device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 910 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, any suitable bus or interconnect is contemplated herein.

[0258] The file sharing device executes the file sharing method in the embodiments of this application, thereby realizing the file sharing method described in the embodiments of this application.

[0259] Furthermore, in conjunction with the file-sharing methods described in the above embodiments, this application embodiment can provide a computer storage medium for implementation. This computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the file-sharing methods described in the above embodiments.

[0260] Based on the file sharing method in the above embodiments, this application provides a computer program product. When the instructions in the computer program product are executed by the processor of an electronic device, the electronic device performs the file sharing method provided in any of the above embodiments of this application.

[0261] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0262] The functional blocks shown in the above-described structural diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0263] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0264] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0265] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A file sharing method characterized by, The method is applied to a file transmission server, and comprises the following steps: receiving a file upload request of a target file by a file upload mechanism, wherein the file upload request comprises a first sender node number of the file upload mechanism and a first receiver node number of the target file, and the file upload request comprises a first encrypted file of the target file and a first service type, and the file upload request further comprises a first request timestamp; decrypting the first encrypted file to obtain the target file based on a first session key corresponding to the first service type, in a case where a time difference between the first request timestamp and a current time of the file transmission server is less than a first preset time difference value; sending a file unique identifier of the target file to the file upload mechanism; in a case where a file download mechanism obtains the file unique identifier sent by the file upload mechanism, receiving a file download request of the target file by the file download mechanism, wherein the file download request comprises the file unique identifier, a second sender node number and a second receiver node number of the file download mechanism, and the file download request further comprises a second service type specified by the file download mechanism, and the file download request further comprises a second request timestamp; in a case where the first receiver node number matches the second sender node number and the first sender node number matches the second receiver node number, querying the target file based on the file unique identifier, encrypting the target file based on a second session key corresponding to the second service type to obtain a second encrypted file, and returning the second encrypted file to the file download mechanism; the encrypting the target file based on the second session key corresponding to the second service type to obtain the second encrypted file comprises: in a case where a time difference between the second request timestamp and a current time of the file transmission server is less than a second preset time difference value, encrypting the target file based on the second session key to obtain the second encrypted file.

2. The method of claim 1, wherein, the sending the file unique identifier of the target file to the file upload mechanism comprises: encrypting the file unique identifier based on the first session key to obtain a first encrypted file unique identifier; transmitting the first encrypted file unique identifier to the file upload mechanism, and the file upload mechanism is configured to decrypt the first encrypted file unique identifier based on the first session key to obtain the file unique identifier; the file download request comprises a second encrypted file identifier, and the second encrypted file identifier is obtained by encrypting the file unique identifier based on the second session key by the file download mechanism; before the querying the target file based on the file unique identifier, the method further comprises: decrypting the second encrypted file identifier based on the second session key to obtain the file unique identifier.

3. The method of claim 1, wherein, after the receiving the file upload request of the target file by the file upload mechanism, and before the decrypting the first encrypted file to obtain the target file, the method further comprises: Verify the number of file uploads of the file upload mechanism within a preset time period; The decryption of the first encrypted file to obtain the target file comprises: In the case that the number of file uploads does not exceed a first preset threshold, decrypt the first encrypted file to obtain the target file.

4. The method of claim 1, wherein, After the target file is obtained based on the file unique identifier query, and before the second encrypted file is returned to the file download mechanism, the method further comprises: Verify the number of file downloads of the target file by the file download mechanism; The encryption of the target file based on the second session key corresponding to the second business type to obtain the second encrypted file, and the return of the second encrypted file to the file download mechanism, comprises: In the case that the number of file downloads does not exceed a second preset threshold, encrypt the target file based on the second session key to obtain the second encrypted file, and return the second encrypted file to the file download mechanism.

5. The method of claim 1, wherein, Before the decryption of the first encrypted file based on the first session key corresponding to the first business type to obtain the target file, the method further comprises: Based on the first sender node number, perform digital check-in to obtain a first correspondence relationship between the business type and the session key corresponding to the file upload mechanism; Based on the first correspondence relationship, determine the first session key corresponding to the first business type; Before the encryption of the target file based on the second session key corresponding to the second business type to obtain the second encrypted file, the method further comprises: Based on the second sender node number, perform digital check-in to obtain a second correspondence relationship between the business type and the session key corresponding to the file download mechanism; Based on the second correspondence relationship, determine the second session key corresponding to the second business type.

6. The method of claim 1, wherein, The file upload mechanism is also used to generate corresponding first file summary information based on the target file, and transmit the first file summary to the file download mechanism; The file download request also includes the first file summary information; after the target file is obtained based on the file unique identifier query, the method further comprises: Based on the target file, generate second file summary information corresponding to the current time, and compare the first file summary information and the second file summary information; Return the target file to the file download mechanism, comprising: In the case that the first file summary information and the second file summary information are consistent, return the target file to the file download mechanism.

7. The method according to any one of claims 1 to 6, characterized in that, The file upload mechanism is used to: after receiving the file unique identifier, push the file unique identifier to the file download mechanism; Or, in response to the query request of the file download mechanism, return the request response corresponding to the query request to the file download mechanism, and the request response carries the file unique identifier.

8. The method according to any one of claims 1 to 6, characterized in that, The file unique identifier is: the relative path of the target file saved in the file transmission server, and / or the file index of the storage location of the target file on the file transmission server.

9. A file sharing apparatus characterized by comprising: Applied to a file transmission server, the device comprises: The first receiving module is configured to receive a file uploading request for a target file from a file uploading mechanism, wherein the file uploading request comprises a first sender node number of the file uploading mechanism, a first receiver node number of the target file, a first encrypted file of the target file, a first service type, and a first request timestamp. The first decryption module is configured to decrypt the first encrypted file to obtain the target file based on a first session key corresponding to the first service type, in a case where a time difference between the first request timestamp and a current time of the file transmission server is less than a first preset time difference. The first processing module is configured to send a file unique identifier of the target file to the file uploading mechanism. The second receiving module is configured to receive a file downloading request for the target file from a file downloading mechanism, in a case where the file downloading mechanism obtains the file unique identifier sent by the file uploading mechanism, wherein the file downloading request comprises the file unique identifier, a second sender node number of the file downloading mechanism, a second receiver node number, a second service type specified by the file downloading mechanism, and a second request timestamp. The second processing module is configured to obtain the target file based on the file unique identifier, and encrypt the target file based on a second session key corresponding to the second service type to obtain a second encrypted file, and return the second encrypted file to the file downloading mechanism, in a case where the first receiver node number matches the second sender node number, and the first sender node number matches the second receiver node number. The encryption of the target file based on the second session key corresponding to the second service type to obtain the second encrypted file comprises: In a case where a time difference between the second request timestamp and a current time of the file transmission server is less than a second preset time difference, the target file is encrypted based on the second session key to obtain the second encrypted file.

10. A file sharing device, characterized by, The device comprises a processor and a memory storing computer program instructions. The processor executes the computer program instructions to implement the file sharing method according to any one of claims 1-8.

11. A computer readable storage medium, characterized in that, The computer readable storage medium stores computer program instructions, and the computer program instructions are executed by the processor to implement the file sharing method according to any one of claims 1-8.

12. A computer program product, characterised in that, The instructions in the computer program product are executed by the processor of the electronic device, and the electronic device executes the file sharing method according to any one of claims 1-8.

Images