File permission management method, device, system, computer device and medium

Abstract

The application provides a file permission management method, device, system, computer equipment and medium. The file permission management method comprises the following steps: receiving a file permission setting request sent by a first end, wherein the first end is used for creating an engineering file, the engineering file comprises a file identifier, and the file permission setting request comprises the file identifier and a permission rule; storing the file identifier and the permission rule in a permission database; receiving a file permission query request sent by a second end, wherein the second end is used for sending the file permission query request when an operation instruction of the engineering file is received, and the file permission query request comprises the file identifier; querying the permission rule corresponding to the file identifier in the permission database; determining an operation permission corresponding to the operation instruction according to the permission rule; and delivering the operation permission to the second end, wherein the second end responds to the operation instruction according to the operation permission. Through the application, dynamic management of engineering file permissions can be realized.

Description

Technical Field

[0001] This invention relates to the field of access control technology, and in particular to a method, apparatus, system, computer equipment, and medium for managing file permissions. Background Technology

[0002] Construction project bidding documents, also known as data files, contain confidential information about the compilers. Data security often impacts the success or failure of the entire bidding process. However, due to the need for third-party review and evaluation, these documents must be sent to third parties. Therefore, the following issues arise during the transfer of these documents:

[0003] 1. Data leakage risk: Once the project files are sent to a third party, the compiler loses control of the files, which can be arbitrarily backed up, distributed, and viewed.

[0004] 2. When project files are sent to third parties, the compiler cannot know how the data is used, including information such as the users and whether it has been copied, and cannot determine whether their data has been leaked.

[0005] The data security issues mentioned above can pose security risks to the compilers, and sometimes even disrupt necessary data flow processes. Similar problems exist in other types of engineering documents as well.

[0006] In existing technologies, the only solution users can find to protect project files is to encrypt the files and inform the file viewer of the decryption method. This method has several drawbacks: First, the viewer still gains full access to the file after decryption, and the protection provided by encryption is completely lost after decryption; second, it only provides static encryption protection, and users cannot subsequently adjust the permissions of the data files that have already been given, which inherently carries risks once the permissions are given.

[0007] Therefore, how to better address the risk of data leakage in engineering documents has become a pressing technical problem in this field. Summary of the Invention

[0008] The purpose of this invention is to provide a method, apparatus, system, computer device, and medium for managing file permissions, in order to solve the technical problems in the prior art.

[0009] On the one hand, in order to achieve the above objectives, the present invention provides a method for managing file permissions.

[0010] The method for managing file permissions includes: receiving a file permission setting request sent by a first end, wherein the first end is used to create a project file, the project file includes a file identifier, and the file permission setting request includes the file identifier and permission rules; storing the file identifier and the permission rules in a permission database; receiving a file permission query request sent by a second end, wherein the second end is used to send the file permission query request when receiving an operation instruction for the project file, the file permission query request including the file identifier; querying the permission rules corresponding to the file identifier in the permission database; determining the operation permission corresponding to the operation instruction according to the permission rules; and issuing the operation permission to the second end, wherein the second end responds to the operation instruction according to the operation permission.

[0011] Furthermore, the project file also includes a file signature ciphertext. The second end is further configured to, upon receiving an operation instruction for the project file, obtain the file signature ciphertext and the file owner identifier of the project file, generate and send a file tampering verification request based on the file owner identifier. The method further includes: receiving a user identifier and a key corresponding to the user identifier sent by the first end, wherein the key is a key used to generate the signature ciphertext; storing the user identifier and the corresponding key in a key database; receiving a file tampering verification request from the second end; querying the key database for a user identifier matching the file owner identifier in the file tampering verification request to determine the key corresponding to the file owner identifier; and sending the key corresponding to the file owner identifier to the second end, wherein the second end is configured to decrypt the signature ciphertext using the key corresponding to the file owner identifier, and use the decrypted signature plaintext to verify whether the project file has been tampered with, and send the file permission query request if it has not been tampered with.

[0012] Furthermore, the second end is also used to calculate the plaintext signature of the project file when receiving the save instruction of the project file, encrypt the plaintext signature using the key corresponding to the file owner identifier to obtain the current ciphertext signature, and update the ciphertext signature of the project file.

[0013] Furthermore, the permission rules include permission identifier, file owner identifier, file identifier, permission grantor information, permission category, and permission duration.

[0014] Furthermore, the method further includes: receiving an operation log sent by the second end, wherein the operation log includes a file identifier of the operated project file; storing the operation log in a log database; receiving a log query request sent by the first end, wherein the log query request includes the file identifier; querying the log database for the operation log corresponding to the file identifier; and sending the queried operation log to the first end.

[0015] Furthermore, the operation log includes a log identifier, file operator information, operation type, and operation time.

[0016] On the other hand, to achieve the above objectives, the present invention provides another method for managing file permissions.

[0017] The method for managing file permissions includes: receiving an operation instruction for a project file, wherein the project file includes a file identifier; sending a file permission query request to a server, wherein the file permission query request includes the file identifier, the server storing the file identifier and permission rules of the project file sent by the first end in a permission database, and upon receiving the file permission query request, querying the permission rules corresponding to the file identifier in the permission database to determine the operation permission corresponding to the operation instruction; receiving the operation permission sent by the server; and responding to the operation instruction according to the operation permission.

[0018] On the other hand, in order to achieve the above objectives, the present invention provides a file permission management device.

[0019] The file permission management device includes: a first receiving module for receiving a file permission setting request sent by a first end, wherein the first end is used to create a project file, the project file includes a file identifier, and the file permission setting request includes the file identifier and permission rules; a first storage module for storing the file identifier and the permission rules in a permission database; a second receiving module for receiving a file permission query request sent by a second end, wherein the second end is used to send the file permission query request when it receives an operation instruction for the project file, and the file permission query request includes the file identifier; a first query module for querying the permission rules corresponding to the file identifier in the permission database; a determining module for determining the operation permission corresponding to the operation instruction according to the permission rules; and a first sending module for issuing the operation permission to the second end, wherein the second end responds to the operation instruction according to the operation permission.

[0020] On the other hand, in order to achieve the above objectives, the present invention provides a file permission management system.

[0021] The file permission management system includes: a first end, used to create project files and send file permission setting requests, wherein the project file includes the file identifier, and the file permission setting request includes the file identifier and permission rules; a server end, used to receive and parse the file permission setting request, and store the file identifier and the permission rules in a permission database; a second end, used to send a file permission query request when receiving an operation instruction for the project file, wherein the file permission query request includes the file identifier; the server end is also used to receive and parse the file permission query request, query the permission rules corresponding to the file identifier in the permission database, determine the operation permission corresponding to the operation instruction according to the permission rules, and issue the operation permission to the second end; the second end is also used to respond to the operation instruction according to the operation permission.

[0022] In another aspect, to achieve the above objectives, the present invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above method.

[0023] In another aspect, to achieve the above objectives, the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above method.

[0024] The present invention provides a file permission management method, apparatus, system, computer equipment, and medium. After a file creator creates a project file on a first-end platform, they can send a file permission setting request to a server. This request includes a file identifier and permission rules. The server receives the request and stores the file identifier and permission rules in a permission database. When a file operator operates on the project file on a second-end platform, the second-end platform receives the operation instructions and sends a file permission query request to the server. This request includes a file identifier. The server receives the query request, queries the permission rules corresponding to the file identifier in the permission database, determines the operation permissions corresponding to the operation instructions based on the permission rules, and sends them to the second-end platform. The second-end platform responds to the operation instructions based on the operation permissions. Through this invention, project files are used as permission management units, granting permissions to file operators. File permissions are stored in a cloud database, allowing creators to modify file permissions in real time. Therefore, when operators perform functions such as browsing, editing, copying, and saving on the second-end platform, they need to query cloud permissions in real time, thus achieving dynamic permission management. Attached Figure Description

[0025] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0026] Figure 1 A flowchart illustrating a file permission management method provided in Embodiment 1 of the present invention;

[0027] Figure 2 A flowchart illustrating another file permission management method provided in Embodiment 2 of the present invention;

[0028] Figure 3 This is a block diagram of a file permission management device provided in Embodiment 3 of the present invention;

[0029] Figure 4 A block diagram of a file permission management system provided in Embodiment 4 of the present invention;

[0030] Figure 5 A schematic diagram illustrating the composition of the file permission management system provided in Embodiment 4 of the present invention;

[0031] Figure 6 A schematic diagram of the workflow of the file permission management system provided in Embodiment 4 of the present invention;

[0032] Figure 7 This is a schematic diagram of file permission storage provided in Embodiment 4 of the present invention;

[0033] Figure 8 This is a schematic diagram of access log storage provided in Embodiment 4 of the present invention;

[0034] Figure 9 This is a hardware structure diagram of a computer device provided in Embodiment 5 of the present invention. Detailed Implementation

[0035] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without inventive effort are within the scope of protection of this invention.

[0036] Example 1

[0037] Embodiment 1 of this invention provides a file permission management method. This method involves interaction between a first end, a second end, and a server. The first end is the end that generates the project file; specifically, it can be a front-end for the project file owner to upload the file and configure permissions. The second end is the end that reads and writes the project file; specifically, it can be a client that performs operations on the project file by accessing the server. The server is the executing entity of this method. Through this method, the project file creator can modify the file permissions in real time, and the project file operator needs to query permissions through the server in real time before operating the project file, thereby achieving dynamic permission management. Specifically… Figure 1 A flowchart of the file permission management method provided in Embodiment 1 of the present invention is shown below. Figure 1 As shown, the file permission management method provided in this embodiment includes the following steps S101 to S105.

[0038] Step S101: Receive the file permission setting request sent by the first end.

[0039] The first end is used to create project files, which include file identifiers. The file permission setting request includes file identifiers and permission rules.

[0040] The project document compiler creates the project document through the first end and generates a file identifier for the project document after creation. The file identifier can be a GUID, generated when the data file is created, and written into the project through encryption. It cannot be modified throughout the entire life cycle of the file and has uniqueness.

[0041] For the created project files, the developer can set permission rules as needed, specifying which personnel, terminals, times, and operations are permitted. The file identifier and permission rules are encapsulated into a file permission setting request and sent to the server. The server receives the file permission setting request sent by the client.

[0042] The developer can dynamically adjust permissions as needed by sending new file permission setting requests to the server. The server updates or adds / deletes permission rules. When the permission rules change, the permissions of the second end to operate on the project files change accordingly, thus realizing dynamic adjustment of permissions.

[0043] Step S102: Store the file identifier and permission rules in the permission database.

[0044] Optionally, the permission database stores a permission rule table, a user table, and a file table. The permission rule table stores multiple permission rules, each including fields such as permission identifier, file owner identifier, file identifier, permission grantor information, permission category, and permission duration. The permission identifier is a unique identifier for the permission rule, facilitating retrieval and management. The file owner identifier identifies the file owner. The file identifier is a unique identifier for the file, distinguishing different files. The permission grantor information describes the authorized personnel or terminals, i.e., the users with permissions to operate on the file. The permission category describes the specific type of permission, such as read, write, or delete permissions. The permission duration describes the effective and expiration time of the permission rule. The user table includes a user identifier, username, and user information. The file table includes a file identifier, filename, file owner identifier, and file information. The user table is associated with the file table and the permission rule table based on the user identifier and file owner identifier; the file table is associated with the permission rule table based on the file identifier.

[0045] Step S103: Receive the file permission query request sent by the second end.

[0046] The second end is used to send a file permission query request when it receives operation instructions for the project file. The file permission query request includes the file identifier.

[0047] The user manipulates the project file through a second-party application. Upon receiving an instruction to manipulate the project file, the second-party application sends a file permission query request to the server to determine whether it has the appropriate permissions. The server then receives the file permission query request.

[0048] Step S104: Query the permission rules corresponding to the file identifier in the permission database.

[0049] Specifically, the server queries the permission database for permission rules containing the file identifier based on the file identifier.

[0050] Step S105: Determine the operation permissions corresponding to the operation instruction according to the permission rules.

[0051] Optionally, the file permission query request also carries the file operator's attribute information, including the file operator's identifier, etc. Based on this attribute information, the permission rules determine whether the operation corresponding to the current operation instruction is allowed.

[0052] Step S106: Issue operation permissions to the second end.

[0053] The second terminal responds to operation commands based on the operation permissions. When the operation permission is allowed, the second terminal normally returns the operation result corresponding to the operation command; when the operation permission is prohibited, the second terminal returns a prompt message indicating that the operation is not authorized.

[0054] For example, a project file has a file identifier of "001" and a permission rule that only the file owner and their authorized personnel have read and write permissions. The first end creates the project file and sends a file permission setting request to the server. In this request, the file identifier is "001," the permission rule is: file owner identifier is "A001," permission identifier is "RW," permission grantor information is "A001" and "B001," permission type is "read and write," and permission duration is "permanent." The server stores the file identifier "001" and the permission rule in the permission database. When the second end receives a write command for the project file, it sends a file permission query request to the server. This query request includes the file identifier "001" and the operator attribute information "C001." The server queries the permission database for the permission rule corresponding to the file identifier "001" and determines that only the file owner and authorized personnel have read and write permissions for this write command. "C001" does not have permission, so the server issues a permission prohibition to the second end. The second end receives feedback that it does not have the permission to operate.

[0055] In the file permission management method provided in this embodiment, after the file creator creates a project file on the first end, they can send a file permission setting request to the server. This file permission setting request includes a file identifier and permission rules. The server receives the file permission setting request sent by the first end and stores the file identifier and permission rules in the permission database. When the file operator operates on the project file on the second end, the second end receives the operation instruction of the project file and sends a file permission query request to the server. This file permission setting request includes a file identifier. The server receives the file permission query request sent by the second end, queries the permission rules corresponding to the file identifier in the permission database, determines the operation permission corresponding to the operation instruction according to the permission rules, and issues it to the second end. The second end responds to the operation instruction according to the operation permission. Using the file permission management method provided in this embodiment, the project file is used as the permission management unit. Permissions are opened to file operators, and file permissions are stored in a cloud database. The creator can modify the file permissions in real time. Therefore, when the operator performs functions such as browsing, editing, copying, and saving on the second end, they need to query the cloud permissions in real time, thereby achieving dynamic permission management.

[0056] Optionally, in one embodiment, the project file further includes a file signature ciphertext. The second end is further configured to, upon receiving an operation instruction for the project file, obtain the file signature ciphertext and the file owner identifier of the project file, generate and send a file tampering verification request based on the file owner identifier. The file permission management method further includes: receiving a user identifier and a key corresponding to the user identifier sent by the first end, wherein the key is a key used to generate the signature ciphertext; storing the user identifier and the corresponding key in a key database; receiving a file tampering verification request; querying the key database for a user identifier that matches the file owner identifier in the file tampering verification request to determine the key corresponding to the file owner identifier; and sending the key corresponding to the file owner identifier to the second end, wherein the second end is configured to decrypt the signature ciphertext using the key corresponding to the file owner identifier, and use the decrypted signature plaintext to verify whether the project file has been tampered with, and send a file permission query request if it has not been tampered with.

[0057] Specifically, in this embodiment, an anti-tampering marker is added to the project file to prevent users from modifying the file content through other methods, thus preventing scenarios where the file cannot be controlled by permissions. Therefore, anti-tampering signature verification is required for the file. Based on the differentiation of project files using file identifiers, a file signature is added to the project file for file consistency verification. To further enhance the security of the file signature, the file signature is symmetrically encrypted, forming a ciphertext signature which is placed in the project file. The symmetric encryption key is stored on the server. During decryption verification, the file identifier of the project file is used to find the corresponding file author. By setting the key to correspond with the author, the secret key can be further found. Specifically, when calculating the file signature, the file content is first hashed to obtain a fixed-length digest value. Then, the digest value is encrypted using the private key to obtain the ciphertext signature. On the second end, when verifying whether the project file has been tampered with based on the secret key, the obtained secret key is used to decrypt the ciphertext signature, and then the file is hashed. If the calculated hash value is the same as the decrypted plaintext signature, it indicates that the file content has not been tampered with.

[0058] Based on the above, in the file permission management method provided in this embodiment, when an operator operates on a project file at the second end, the second end receives the operation instruction for the project file and does not directly send a file permission query request to the server. Instead, it obtains the encrypted file signature and the file owner identifier of the project file, and generates and sends a file tampering verification request based on the file owner identifier. The encrypted file signature is used to verify whether the project file has been tampered with, and the file owner identifier is used to determine the identity of the file owner. The server queries the key database for a user identifier that matches the file owner identifier in the file tampering verification request to determine the key corresponding to the file owner identifier. The server sends the key corresponding to the file owner identifier to the second end, which uses this key to decrypt the encrypted signature and uses the decrypted plaintext signature to verify whether the project file has been tampered with. If the file has not been tampered with, the second end sends a file permission query request to obtain the corresponding operation permissions.

[0059] The file permission management method provided in this embodiment further enhances file security. A file tampering verification mechanism is incorporated into file permission management. By combining this mechanism with permission management, scenarios where modifications to file content render the file uncontrollable are avoided, thus further improving the reliability of file permission control.

[0060] In a further optional embodiment, the second end is also used to calculate the plaintext signature of the project file when a save instruction for the project file is received, encrypt the plaintext signature using the key corresponding to the file owner identifier to obtain the current ciphertext signature, and update the ciphertext signature of the project file.

[0061] Specifically, once the operator obtains permission to perform legitimate operations on the project file, such as editing and modifying it, the project file can be saved after the legitimate operation. When the second end receives the save instruction for the project file, it first calculates the plaintext signature of the current project file, then encrypts the plaintext signature to obtain a new ciphertext signature, and updates the existing ciphertext signature in the project file to the latest ciphertext signature.

[0062] The file permission management method provided in this embodiment will save the legitimate operation results of the project files and update the signature ciphertext to ensure the accuracy of subsequent permission control.

[0063] Optionally, in one embodiment, the file permission management method further includes: receiving an operation log sent by a second end, wherein the operation log includes a file identifier of the project file being operated on; storing the operation log in a log database; receiving a log query request sent by a first end, wherein the log query request includes a file identifier; querying the operation log corresponding to the file identifier in the log database; and sending the queried operation log to the first end.

[0064] Specifically, once the second end obtains permission to operate, it executes the corresponding operation instructions and simultaneously records the operation log, which is then sent to the server. The operation log includes a log identifier, file operator information, operation type, and operation time. The server stores the operation log sent by the second end in a log database for subsequent operation log queries. The developer can view the operation status of all their project files in real time. When the first end is querying the operation log, it sends a log query request to the server. The server queries the log database for the operation log corresponding to the file identifier and sends the retrieved operation log back to the first end so that the first end can view the file operation records.

[0065] Using the file permission management method provided in this embodiment, the file author can set personalized permissions for designated operators of offline files, making control more precise and the process more flexible. At the same time, the dynamically issued permissions can be changed without modifying the project file itself. Even if the project file has been sent to others, access permissions can be adjusted. Furthermore, it supports the author to view the access logs of the project files they have provided in real time, realizing full lifecycle management.

[0066] Example 2

[0067] Embodiment 2 of the present invention provides a file permission management method. This method involves interaction between a first end, a second end, and a server. The first end is the end that generates the project file, specifically a front-end for the project file owner to upload the file and configure permissions. The second end is the end that reads and writes the project file, specifically a client that performs project file operations by accessing the server. The client can be the executing entity of this method. Through this method, the project file creator can modify the file permissions in real time, and the project file operator needs to query permissions through the server in real time before operating the project file, thereby achieving dynamic permission management. Related technical features and effects can also be referred to Embodiment 1 above. Specifically, Figure 2 The flowchart of the file permission management method provided in Embodiment 2 of the present invention is as follows: Figure 2 As shown, the file permission management method provided in this embodiment includes the following steps S201 to S204.

[0068] Step S201: Receive operation instructions from the project file.

[0069] The project documents include document identifiers.

[0070] Project files are files created by the project file compiler through the first-party application. For each created project file, the compiler can set permission rules as needed, restricting which personnel, terminals, times, and operations are permitted. The file identifier and permission rules are encapsulated into a file permission setting request and sent to the server. The server receives the file permission setting request from the first-party application. The compiler can dynamically adjust permissions as needed, sending new file permission setting requests to the server, which then updates or adds / deletes the permission rules.

[0071] The second end can be a webpage or application that requests the server to perform operations on the project files. These operations can include read, write, or save-as commands. Upon receiving the operation command, the server generates a file permission query request based on the project file's file identifier and obtains the necessary permissions from the server.

[0072] When the permission rules change, the permissions of the second end to operate on the project files change accordingly, realizing dynamic adjustment of permissions.

[0073] Step S202: Send a file permission query request to the server.

[0074] The file permission query request includes a file identifier. The server stores the file identifier and permission rules of the project file sent by the first end in the permission database. When a file permission query request is received, the server queries the permission database for the permission rules corresponding to the file identifier to determine the operation permissions corresponding to the operation instruction.

[0075] Step S203: Receive operation permissions sent by the server.

[0076] Step S204: Respond to the operation command according to the operation permission.

[0077] When the operation permission is allowed, the second end normally feeds back the operation result corresponding to the operation instruction; when the operation permission is prohibited, the second end feeds back a prompt message indicating that the operation is not authorized.

[0078] Optionally, in one embodiment, the project file further includes a file signature ciphertext, and the file permission management method further includes: upon receiving an operation instruction for the project file, obtaining the file signature ciphertext and the file owner identifier of the project file; generating a file tampering verification request based on the file owner identifier; and sending the file tampering verification request to the server. In this method, a key corresponding to a user identifier is set at the first end; this key is used to generate the signature ciphertext. The first end sends the user identifier and the key corresponding to the user identifier to the server, and the server stores the user identifier and the corresponding key in a key database. When the server receives the file tampering verification request... The system queries the key database for a user identifier that matches the file owner identifier in the file tampering verification request to determine the key corresponding to the file owner identifier, and then issues the key corresponding to the file owner identifier. It receives the key corresponding to the file owner identifier, decrypts the ciphertext of the signature using the key, and uses the decrypted plaintext signature to verify whether the project file has been tampered with. Specifically, a file permission query request is sent only if the file has not been tampered with. If the verification result indicates that the file has been tampered with, no further file permission query request is sent. Furthermore, a message indicating that the file has been tampered with can be sent to the server, which will then notify the compiler.

[0079] Optionally, in one embodiment, the file permission management method further includes: receiving a save instruction for a project file; calculating the plaintext signature of the project file; encrypting the plaintext signature using the key corresponding to the file owner identifier to obtain the current ciphertext signature; and updating the ciphertext signature of the project file.

[0080] Optionally, in one embodiment, the file permission management method further includes: sending operation logs to the server, wherein the operation logs include file identifiers of the operated project files, and after receiving the operation logs, the server stores them in a log database, so that the first end can send a log query request to the server to perform log query, wherein the log query request includes a file identifier, and after receiving the log query request, the server queries the log database for the operation logs corresponding to the file identifiers and sends the queried operation logs to the first end.

[0081] Example 3

[0082] Corresponding to Embodiment 1 above, Embodiment 3 of the present invention provides a file permission management device. The technical features and corresponding technical effects can be referred to Embodiment 1 above, and will not be repeated in this embodiment. Figure 3 This is a block diagram of the file permission management device provided in Embodiment 3 of the present invention, as shown below. Figure 3 As shown, the device includes: a first receiving module 301, a first storage module 302, a second receiving module 303, a first query module 304, a determination module 305, and a first sending module 306.

[0083] The system comprises the following components: a first receiving module 301 for receiving a file permission setting request sent by a first end, wherein the first end is used to create a project file, the project file includes a file identifier, and the file permission setting request includes the file identifier and permission rules; a first storage module 302 for storing the file identifier and permission rules in a permission database; a second receiving module 303 for receiving a file permission query request sent by a second end, wherein the second end sends a file permission query request upon receiving an operation instruction for the project file, and the file permission query request includes the file identifier; a first query module 304 for querying the permission rules corresponding to the file identifier in the permission database; a determining module 305 for determining the operation permissions corresponding to the operation instruction based on the permission rules; and a first sending module 306 for issuing operation permissions to the second end, wherein the second end responds to the operation instruction based on the operation permissions.

[0084] Optionally, in one embodiment, the project file further includes a file signature ciphertext, and the second end is further configured to, upon receiving an operation instruction for the project file, obtain the file signature ciphertext and the file owner identifier of the project file, generate and send a file tampering verification request based on the file owner identifier; the device further includes: a third receiving module, configured to receive a user identifier and a key corresponding to the user identifier sent by the first end, wherein the key is a key used to generate the signature ciphertext; a second storage module, configured to store the user identifier and the corresponding key in a key database; a fourth receiving module, configured to receive the file tampering verification request; a second query module, configured to query the key database for a user identifier matching the file owner identifier in the file tampering verification request, to determine the key corresponding to the file owner identifier; and a second sending module, configured to send the key corresponding to the file owner identifier to the second end, wherein the second end is configured to decrypt the signature ciphertext using the key corresponding to the file owner identifier, and use the decrypted signature plaintext to verify whether the project file has been tampered with, and send the file permission query request if it has not been tampered with.

[0085] Optionally, in one embodiment, the second end is further configured to, upon receiving the save instruction of the project file, calculate the plaintext signature of the project file, encrypt the plaintext signature using the key corresponding to the file owner identifier to obtain the current ciphertext signature, and update the ciphertext signature of the project file.

[0086] Optionally, in one embodiment, the permission rule includes a permission identifier, a file owner identifier, the file identifier, permission grantor information, permission category, and permission duration.

[0087] Optionally, in one embodiment, the device further includes: a fourth receiving module, configured to receive an operation log sent by the second end, wherein the operation log includes a file identifier of the operated project file; a third storage module, configured to store the operation log in a log database; a fifth receiving module, configured to receive a log query request sent by the first end, wherein the log query request includes the file identifier; a third query module, configured to query the operation log corresponding to the file identifier in the log data; and a third sending module, configured to send the queried operation log to the first end.

[0088] Optionally, in one embodiment, the operation log includes a log identifier, file operator information, operation type, and operation time.

[0089] Example 4

[0090] Corresponding to Embodiment 1 above, Embodiment 4 of the present invention provides a file permission management system. The technical features and corresponding technical effects can be referred to Embodiment 1 above, and will not be repeated in this embodiment. Figure 4 This is a block diagram of the file permission management system provided in Embodiment 4 of the present invention, as shown below. Figure 4 As shown, the file permission management system includes: first terminal 10, server terminal 20, and second terminal 30.

[0091] The system comprises the following components: a first terminal 10, which creates a project file and sends a file permission setting request, wherein the project file includes the file identifier and the file permission setting request includes the file identifier and permission rules; a server terminal 20, which receives and parses the file permission setting request and stores the file identifier and permission rules in a permission database; a second terminal 30, which, upon receiving an operation instruction for the project file, sends a file permission query request, wherein the file permission query request includes the file identifier; the server terminal 20, which also receives and parses the file permission query request, queries the permission rules corresponding to the file identifier in the permission database, determines the operation permission corresponding to the operation instruction based on the permission rules, and issues the operation permission to the second terminal 30; and the second terminal 30, which responds to the operation instruction based on the operation permission.

[0092] Optionally, in one embodiment, the project file further includes a file signature ciphertext. The second terminal 30 is further configured to, upon receiving an operation instruction for the project file, obtain the file signature ciphertext and the file owner identifier of the project file, generate and send a file tampering verification request based on the file owner identifier; the server terminal 20 is further configured to receive a user identifier and a key corresponding to the user identifier sent by the first terminal 10, wherein the key is a key used to generate the signature ciphertext, store the user identifier and the corresponding key in a key database, receive the file tampering verification request, query the key database for a user identifier matching the file owner identifier in the file tampering verification request to determine the key corresponding to the file owner identifier, and send the key corresponding to the file owner identifier to the second terminal 30; the second terminal 30 is further configured to decrypt the signature ciphertext using the key corresponding to the file owner identifier, and use the decrypted signature plaintext to verify whether the project file has been tampered with, and send the file permission query request if it has not been tampered with.

[0093] Optionally, in one embodiment, the second terminal 30 is further configured to, upon receiving the save instruction of the project file, calculate the plaintext signature of the project file, encrypt the plaintext signature using the key corresponding to the file owner identifier to obtain the current ciphertext signature, and update the ciphertext signature of the project file.

[0094] Optionally, in one embodiment, the permission rule includes a permission identifier, a file owner identifier, the file identifier, permission grantor information, permission category, and permission duration.

[0095] Optionally, in one embodiment, the server 20 is further configured to receive operation logs sent by the second terminal 30, wherein the operation logs include file identifiers of the operated project files, store the operation logs in a log database, receive log query requests sent by the first terminal 10, wherein the log query requests include the file identifiers, query the operation logs corresponding to the file identifiers in the log data, and send the queried operation logs to the first terminal 10.

[0096] Optionally, in one embodiment, the operation log includes a log identifier, file operator information, operation type, and operation time.

[0097] Alternatively, in one embodiment, Figure 5 This is a schematic diagram illustrating the composition of the file permission management system provided in Embodiment 4 of the present invention. Figure 6 This is a schematic diagram of the workflow of the file permission management system provided in Embodiment 4 of the present invention. Figure 7 This is a schematic diagram of file permission storage provided in Embodiment 4 of the present invention. Figure 8 This is a schematic diagram of access log storage provided in Embodiment 4 of the present invention, as shown below. Figures 5 to 8 As shown, the cloud stores the access permissions set by the compiler for the project files and the operation logs of the project files; the first end provides a function that allows users to modify permissions online, and the permissions set by the compiler for their project files can take effect immediately; the server collects the access logs of the project files from the second end, and the compiler can view the logs at any time.

[0098] like Figure 5 and Figure 6 As shown, a) the file creator can modify the permissions of the data file at any time and grant permissions to designated viewers; when a viewer opens the data file from the second end, they need to verify whether the file has been tampered with; browsing and editing operations require requesting the dynamic permission status stored on the server from the second end and uploading the browsing log; the creator can view the browsing log of their own file from the first end in real time.

[0099] Specifically, the server provides core functions such as permission management, access log management, and user key management, while also supporting auxiliary functions for user project upload and download. The client provides users with core functions such as editing and modifying file permissions and viewing logs, while also supporting file upload and download. The issued permissions are associated with the file's GUID encoding, which serves as the file's unique identifier. The issued permissions are specific to a particular user, and each record stores only one type of permission for a specific user. The permissions are stored in the database in the following format: Figure 7 As shown in the image. The access log is associated with the file's GUID encoding. Each log entry stores one access record for that file, including the visitor, access behavior, time, and machine-related information, as detailed below. Figure 8 As shown in the diagram. The user key management module stores the user's key, which is generated when the user creates their account and remains unchanged throughout the account's lifecycle. The user key is stored in a separate data table, with the user ID as the primary key.

[0100] The second end provides an independent SDK for permission control: it queries whether logged-in users and specified projects have operation permissions and performs access enable adjustments; the base layer is implemented in C++, while the interface and web access are implemented in Qt; it provides core middleware modules including parsing symmetric encryption that the encryption signature depends on, providing permission queries, uploading operation logs, and a GUI interaction method; the final supported query functions include opening data files, saving data files, and exporting data; the SDK provides independent encryption and decryption processes, and supports querying results for specified users with specified permissions, which can be directly inherited and used by the product side.

[0101] This embodiment provides an open access control system that allows business process participants among users to run their own access permissions. Permissions protect specific, independent data files, thereby protecting the security of specific user data. Dynamic access management can issue or revoke permissions in real time, supports users in browsing the access status of data files, and provides real-time and effective security protection.

[0102] Example 5

[0103] This fifth embodiment also provides a computer device, such as a smartphone, tablet computer, laptop computer, desktop computer, rack-mount server, blade server, tower server, or cabinet server (including independent servers or server clusters composed of multiple servers), etc., capable of executing programs. Figure 9 As shown, the computer device 01 in this embodiment includes, but is not limited to, a memory 011 and a processor 012 that can be interconnected via a system bus, such as... Figure 9 As shown. It should be noted that, Figure 9 Only a computer device 01 with component memory 011 and processor 012 is shown; however, it should be understood that it is not required to implement all of the components shown, and more or fewer components may be implemented instead.

[0104] In this embodiment, the memory 011 (i.e., the readable storage medium) includes flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, disk, optical disk, etc. In some embodiments, the memory 011 may be an internal storage unit of the computer device 01, such as the hard disk or memory of the computer device 01. In other embodiments, the memory 011 may also be an external storage device of the computer device 01, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 01. Of course, the memory 011 may include both the internal storage unit and its external storage device of the computer device 01. In this embodiment, the memory 011 is typically used to store the operating system and various application software installed on the computer device 01, such as the program code of the file permission management device in Embodiment 3. In addition, memory 011 can also be used to temporarily store various types of data that have been output or will be output.

[0105] In some embodiments, processor 012 may be a central processing unit (CPU), controller, microcontroller, microprocessor, or other data processing chip. This processor 012 is typically used to control the overall operation of computer device 01. In this embodiment, processor 012 is used to run program code stored in memory 011 or process data, such as file permission management devices.

[0106] Example 6

[0107] This embodiment also provides a computer-readable storage medium, such as flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, disk, optical disk, server, App application store, etc., which stores computer programs. When the program is executed by a processor, it implements corresponding functions. The computer-readable storage medium of this embodiment is used to store a file permission management device, and when executed by a processor, it implements the file permission management method of Embodiment 1.

[0108] It should be noted that, in this document, 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. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0109] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0110] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0111] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A method for managing file permissions, characterized in that, The management method is implemented by a server, and the management method includes: The system receives a file permission setting request, a user identifier, and a key corresponding to the user identifier from a first end. The first end is used to create a project file, which includes a file identifier, a file owner identifier, and a file signature ciphertext. The file permission setting request includes the file identifier and permission rules. The permission rules include a permission identifier, the file owner identifier, the file identifier, permission grantor information, permission category, and permission time. The key is used to generate the file signature ciphertext. The file identifier and the permission rules are stored in the permission database, and the user identifier and the corresponding key are stored in the key database; The system receives a file tampering verification request sent from the second end. When the file operator initiates an operation instruction to operate the project file at the second end, it obtains the file signature ciphertext of the project file and the file owner identifier, and generates and sends the file tampering verification request based on the file owner identifier. The key database is queried to find a user identifier that matches the file owner identifier in the file tampering verification request, so as to determine the key corresponding to the file owner identifier; The key corresponding to the file owner identifier is sent to the second end, wherein the second end is used to decrypt the file signature ciphertext using the key corresponding to the file owner identifier, and to verify whether the project file has been tampered with using the decrypted signature plaintext, and to send a file permission query request if it has not been tampered with. Receive the file permission query request sent by the second end, wherein the file permission query request includes the file identifier, the file operator identifier, and the operation instruction; Query the permission database for the permission rule corresponding to the file identifier; The operation permissions corresponding to the operation instructions are determined based on the file operator identifier, the operation instructions, and the permission rules. Specifically, when the first end dynamically adjusts the permission rules, it sends a new file permission setting request to the server. The server updates or adds to the permission rules. When the permission rules change, the operation permissions of the second end for operating the project files change accordingly, thus achieving dynamic adjustment of permissions. The operation permission is issued to the second terminal, wherein the second terminal responds to the operation instruction according to the operation permission.

2. The file permission management method according to claim 1, characterized in that, Also includes: Receive the operation log sent by the second end, wherein the operation log includes the file identifier of the project file being operated on; The operation logs are stored in a log database; Receive a log query request sent by the first end, wherein the log query request includes the file identifier; Query the operation log corresponding to the file identifier in the log database; The retrieved operation logs are sent to the first terminal.

3. The file permission management method according to claim 2, characterized in that, The operation log includes log identifier, file operator information, operation type, and operation time.

4. A method for managing file permissions, characterized in that, The first end is used to create a project file and send a file permission setting request, a user identifier, and a key corresponding to the user identifier to the server. The project file includes a file identifier, a file owner identifier, and a file signature ciphertext. The file permission setting request includes the file identifier and permission rules. The permission rules include a permission identifier, the file owner identifier, the file identifier, permission grantor information, permission category, and permission time. The key is a key used to generate the file signature ciphertext. The server is used to store the file identifier and the permission rules in the permission database, and to store the user identifier and the corresponding key in the key database; The second end is the implementing entity of the management method, and the management method includes: Receive operation instructions for the project file, wherein the file operator initiates the operation instructions for the project file at the second end; The system obtains the encrypted file signature and file owner identifier of the project file, generates and sends a file tampering verification request to the server based on the file owner identifier, wherein the server is also used to query the key database for a user identifier that matches the file owner identifier in the file tampering verification request, so as to determine the key corresponding to the file owner identifier; Receive the key corresponding to the file owner identifier; The encrypted file signature is decrypted using the key corresponding to the file owner's identifier, and the decrypted plaintext signature is used to verify whether the project file has been tampered with. If it has not been tampered with, a file permission query request is sent to the server. The file permission query request includes the file identifier, the file operator identifier, and the operation instruction. When the server receives the file permission query request, it queries the permission rule corresponding to the file identifier in the permission database, and determines the operation permission corresponding to the operation instruction based on the file operator identifier, the operation instruction, and the permission rule. When the first end dynamically adjusts the permission rule, it sends a new file permission setting request to the server. The server updates or adds / deletes the permission rule. When the permission rule changes, the operation permission of the second end to operate the project file changes accordingly, realizing dynamic adjustment of permissions. Receive the operation permissions sent by the server; and Respond to the operation command according to the operation permissions.

5. A file permission management device, characterized in that, The management device is located on the server side, and the management device includes: The first receiving module is used to receive file permission setting requests sent by the first end; The third receiving module is used to receive a user identifier and a key corresponding to the user identifier sent by the first end. The first end is used to create a project file, which includes a file identifier, a file owner identifier, and a file signature ciphertext. The file permission setting request includes the file identifier and permission rules. The permission rules include a permission identifier, the file owner identifier, the file identifier, permission grantor information, permission category, and permission time. The key is a key used to generate the file signature ciphertext. The first storage module is used to store the file identifier and the permission rules in the permission database; The second storage module is used to store the user identifier and the corresponding key in the key database; The fourth receiving module is used to receive a file tampering verification request sent by the second end. The second end is also used to obtain the file signature ciphertext and the file owner identifier of the project file when it receives the operation instruction of the project file, and generate and send the file tampering verification request based on the file owner identifier. The second query module is used to query the key database for a user identifier that matches the file owner identifier in the file tampering verification request, so as to determine the key corresponding to the file owner identifier; The second sending module is used to send the key corresponding to the file owner identifier to the second end. The second end is used to decrypt the file signature ciphertext using the key corresponding to the file owner identifier, and use the decrypted signature plaintext to verify whether the project file has been tampered with. If it has not been tampered with, it sends a file permission query request. The second receiving module is used to receive the file permission query request sent by the second end, wherein the file permission query request includes the file identifier, the file operator identifier, and the operation instruction; The first query module is used to query the permission rules corresponding to the file identifier in the permission database; The determination module is used to determine the operation permission corresponding to the operation instruction based on the file operator identifier, the operation instruction, and the permission rules. Specifically, when the first end dynamically adjusts the permission rules, it sends a new file permission setting request to the server. The server updates or adds to the permission rules. When the permission rules change, the operation permission of the second end to operate the project file changes accordingly, thus achieving dynamic adjustment of permissions. A first sending module is used to send the operation permission to the second terminal, wherein the second terminal responds to the operation instruction according to the operation permission.

6. A file permission management system, characterized in that, include: The first end is used to create a project file and send a file permission setting request, a user identifier, and a key corresponding to the user identifier. The project file includes a file identifier, a file owner identifier, and a file signature ciphertext. The file permission setting request includes the file identifier and permission rules. The permission rules include a permission identifier, the file owner identifier, the file identifier, permission grantor information, permission category, and permission time. The key is a key used to generate the file signature ciphertext. The server is used to receive and parse file permission setting requests, user identifiers and keys corresponding to the user identifiers, store the file identifiers and permission rules in the permission database, and store the user identifiers and corresponding keys in the key database. The second end is used to obtain the file signature ciphertext and file owner identifier of the project file when the operation instruction of the project file is received, and to generate and send a file tampering verification request based on the file owner identifier; The server is also used to receive the file tampering verification request sent by the second end, query the key database for a user identifier that matches the file owner identifier in the file tampering verification request, determine the key corresponding to the file owner identifier, and send the key corresponding to the file owner identifier to the second end; The second end is also used to decrypt the encrypted file signature using the key corresponding to the file owner identifier, and to verify whether the project file has been tampered with using the decrypted plaintext signature. If the file has not been tampered with, the end sends a file permission query request, wherein the file permission query request includes the file identifier, the file operator identifier, and the operation instruction. The server is also used to receive and parse the file permission query request, query the permission rules corresponding to the file identifier in the permission database, determine the operation permission corresponding to the operation instruction according to the file operator identifier, the operation instruction and the permission rules, and issue the operation permission to the second end. When the first end dynamically adjusts the permission rules, it sends a new file permission setting request to the server. The server updates or adds to the permission rules. When the permission rules change, the operation permission of the second end to operate the project file changes accordingly, realizing dynamic adjustment of permissions. The second terminal is also used to respond to the operation command according to the operation permission.

7. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 4.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 4.

Images