Authority control method, system and equipment under front-end code monorepo warehouse management and medium

Abstract

The invention relates to the technical field of software version control and code security management, in particular to an authority control method, system and device under front-end code monorepo warehouse management and a medium. The method supports file-level, directory-level and extended-name-level multi-dimensional authority rules, fills the blank of Git native capability, and realizes fine-grained control; the method is realized completely based on a Git hook, does not need additional services or middleware, is compatible with any Git hosting platform, and realizes zero external dependence; permission file modification is ensured to be authorized by an administrator through digital signature, so that a developer is prevented from relaying permission rules privately; the signature verification process is completed at the local hook, an external certificate server does not need to be connected, the security and the offline availability are both considered, and the tamper-resistant capability is enhanced.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of software version control and code security management, in particular to a permission control method, system, device and medium under monorepo large warehouse management of front-end code. BACKGROUND

[0002] In the Monorepo architecture, all developers have write permissions to all directories and files by default, although it simplifies code management, but also brings the following problems: Security risks: developers may mistakenly modify or maliciously tamper with files without permission (such as core modules, sensitive configurations).

[0003] Lack of permission control: Git natively only supports repository-level read-write control, and cannot achieve fine-grained permission management at the file or directory level.

[0004] Depend on manual review: traditional solutions block unauthorized operations through code review or external permission systems (such as LDAP), but cannot block in real time before submission, which is inefficient and easy to miss.

[0005] Existing technologies such as Git LFS, Git submodules, etc. are mainly used to manage large files or sub-repository dependencies, and have nothing to do with permission control; some enterprise-level tools (such as Gerrit) support permission approval, but need to be deployed separately and are decoupled from the Git native process. Therefore, there is an urgent need for a lightweight, deeply integrated file-level permission control solution with Git. SUMMARY

[0006] The present application proposes a permission control method, system, device and medium under monorepo large warehouse management of front-end code to solve the problem of security risks caused by full directory open write permissions in traditional Monorepo environment; by integrating the Hooks mechanism of Git distributed version control system, combining encrypted permission files and fine-grained rule matching, it realizes the code collaboration scenario with high security requirements.

[0007] The present application specifically realizes the following contents: A permission control method under monorepo large warehouse management of front-end code, specifically comprising the following steps: Step S1: initialize permission configuration, generate permission file, and submit to repository root directory; Step S2: call openssl to generate key pair, and sign the permission file according to the key pair to generate a signed file and submit it to the repository root directory; Step S3: according to the obtained git commit command, triggering the Git hook, checking whether the signature of the permission file is valid, if valid, parsing the user mailbox, and judging whether to submit the file according to the set permission matching rule; if invalid, intercepting and listing the unauthorized file path.

[0008] In order to better realize the present application, further, the specific operation of the step S1 is: defining the user permission in JSON format, and generating the permission file; the user permission includes the user mailbox field, the Glb mode field and the administrator identification field.

[0009] In order to better realize the present application, further, the step S2 specifically includes the following steps: Step S21: generating a key pair according to the asymmetric encryption algorithm of openssl; Step S22: encoding the public key, and embedding the encoded public key into the Git hook script; Step S23: calling the private key to encrypt the user information, and updating the permission file content according to the encrypted user information; Step S24: calling the private key to sign the updated permission file, generating a signature file, and submitting to the root directory of the warehouse.

[0010] In order to better realize the present application, further, the step S3 specifically includes the following steps: Step S31: according to the obtained git commit command, triggering the pre-commit hook, reading the encoded public key and decoding according to the obtained hook variable PUBLIC_KEY; Step S32: checking whether the local branch is the latest version of the remote, if not the latest version, then forcibly requiring gitpull to update, returning to step S31 after updating, if the latest version, then executing step S33; Step S33: checking whether the signature of the permission file is valid, if the signature is invalid, then intercepting the submission, and prompting that the signature does not match; if the signature is valid, then parsing the user Git mailbox, calling the public key to decrypt the permission file JSON, and matching with the user list in the permission file; Step S34: detecting whether the permission file exists, if not existing, then intercepting the submission, and prompting that the permission file is lost, if existing, then judging whether to submit the file according to the set permission matching rule.

[0011] To better realize the present application, further, the specific operation of judging whether to submit the file according to the set permission matching rule in step S34 is: if the permission file exists, judging whether the current user is an administrator, if yes, allowing to submit; otherwise, matching the file path piece by piece according to the Glob mode, if all files are matched, allowing to submit, if there are unmatched files, intercepting the submission, and returning the unauthorized file list.

[0012] To better realize the present application, further, the set permission matching rule further includes setting an independent permission lock for the sensitive file.

[0013] To better realize the present application, further, the specific operation of step S22 is: Base64 encoding the public key, and embedding the encoded public key into the Git hook script.

[0014] Based on the above-mentioned permission control method under the monorepo large warehouse management of the front-end code, to better realize the present application, further, a permission control system under the monorepo large warehouse management of the front-end code is proposed, which is used to execute the above-mentioned permission control method under the monorepo large warehouse management of the front-end code; including a permission configuration unit, an encryption verification unit, and a verification matching unit. The permission configuration unit is used to initialize the permission configuration, generate a permission file, and submit it to the warehouse root directory. The encryption verification unit is used to call openssl to generate a key pair, sign the permission file according to the key pair, generate a signature file, and submit it to the warehouse root directory. The verification matching unit is used to trigger the Git hook according to the obtained git commit command, verify whether the permission file signature is valid, if yes, parse the user mailbox, judge whether to submit the file according to the set permission matching rule; if not, intercept and list the unauthorized file path.

[0015] Based on the above-mentioned permission control method under the monorepo large warehouse management of the front-end code, to better realize the present application, further, an electronic device is proposed, including a memory and a processor; the memory stores a computer program; when the computer program is executed on the processor, the above-mentioned permission control method under the monorepo large warehouse management of the front-end code is realized.

[0016] Based on the above-mentioned permission control method under the monorepo large warehouse management of the front-end code, to better realize the present application, further, a computer readable storage medium is proposed, which stores computer instructions; when the computer instructions are executed on the above-mentioned electronic device, the above-mentioned permission control method under the monorepo large warehouse management of the front-end code is realized.

[0017] The present application has the following beneficial effects: (1) The present application supports multi-dimensional permission rules at the file level, directory level, and extension level, fills the gap in the native capabilities of Git, and achieves fine-grained control.

[0018] (2) The present application is completely based on Git hooks and does not require additional services or middleware, is compatible with any Git hosting platform (GitHub, GitLab, etc.), and achieves zero external dependencies.

[0019] (3) The present application encrypts the permission file to ensure that the rules cannot be forged, combines the forced verification of the hook script to form a closed-loop security protection, and achieves dynamic tamper-proofing.

[0020] (4) The present application optimizes the time complexity of the permission matching algorithm to O(n), is suitable for super-large Monorepo repositories, and achieves low performance overhead.

[0021] (5) The present application ensures that the modification of the permission file must be authorized by the administrator through digital signature, prevents developers from privately relaxing permission rules, and completes the signature process in the local hook without connecting to an external certificate server, which balances security and offline availability and enhances tamper resistance. BRIEF DESCRIPTION OF DRAWINGS

[0022] Figure 1 The present application provides a front-end code monorepo large repository management permission control method overall flow diagram. DETAILED DESCRIPTION

[0023] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. It should be understood that the described embodiments are only a part of the embodiments of the present application, not all the embodiments, and therefore should not be considered as limiting the scope of protection. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without making creative efforts fall within the scope of protection of the present application.

[0024] In the description of the present application, it should be noted that unless otherwise explicitly specified and limited, the terms "set", "connected", "connected" should be understood broadly, for example, it can be fixedly connected, or it can be detachably connected, or integrally connected; it can be mechanically connected, or it can be electrically connected; it can be directly connected, or it can be indirectly connected through an intermediate medium, or it can be connected inside two elements. For those of ordinary skill in the art, the specific meaning of the above terms in the present application can be understood according to the specific circumstances.

[0025] Example 1: The embodiment provides a permission control method under a front-end code monorepo large warehouse management, and specifically comprises the following steps. Step S1: initializing permission configuration, generating a permission file, and submitting the permission file to a warehouse root directory.

[0026] The specific operation of the step S1 is that a user permission is defined in a JSON format, and a permission file is generated; the user permission comprises a user mailbox field, a Glb mode field and an administrator identifier field.

[0027] Step S2: calling openssl to generate a key pair, signing the permission file according to the key pair, generating a signature file, and submitting the signature file to the warehouse root directory.

[0028] The step S2 specifically comprises the following steps. Step S21: generating a key pair according to an asymmetric encryption algorithm based on openssl; Step S22: encoding a public key and embedding the encoded public key into a Git hook script; The specific operation of the step S22 is that the public key is Base64 encoded, and the encoded public key is embedded into the Git hook script.

[0029] Step S23: encrypting user information by calling a private key, and updating the content of the permission file according to the encrypted user information; Step S24: calling the private key to sign the updated permission file, generating a signature file, and submitting the signature file to the warehouse root directory.

[0030] Step S3: triggering a Git hook according to the obtained git commit command, checking whether the signature of the permission file is valid, if the signature is valid, parsing a user mailbox, and judging whether a file is submitted according to a set permission matching rule; if the signature is invalid, intercepting and listing a file path exceeding the permission.

[0031] The step S3 specifically comprises the following steps. Step S31: triggering a pre-commit hook according to the obtained git commit command, reading the encoded public key and decoding the public key according to the obtained hook variable PUBLIC_KEY; Step S32: checking whether a local branch is the latest version of a remote version, if the local branch is not the latest version, forcibly requiring gitpull to be updated, returning to the step S31 after the update, and if the local branch is the latest version, performing the step S33; Step S33: checking whether the signature of the permission file is valid, if the signature is invalid, intercepting the submission, and prompting that the signature does not match; if the signature is valid, parsing a user Git mailbox, calling the public key to decrypt the permission file JSON, and matching the user list in the permission file; Step S34: Detect whether the permission file exists, if not, intercept the submission, and prompt the loss of the permission file, if exists, judge whether to submit the file according to the set permission matching rule.

[0032] The specific operation of judging whether to submit the file according to the set permission matching rule in step S34 is: if the permission file exists, it is judged whether the current user is an administrator, if yes, the submission is allowed, otherwise, the file path is matched according to the Glob mode, if all files are matched, the submission is allowed, if there are unmatched files, the submission is intercepted, and the unauthorized file list is returned.

[0033] The set permission matching rule further includes setting independent permission lock for sensitive files.

[0034] Working principle: the embodiment solves the security risk caused by the full directory open write permission in the traditional Monorepo environment by integrating the hook (Hooks) mechanism of the Git distributed version control system, combining the encrypted permission file and the fine-grained rule matching, and is suitable for code collaboration scenarios with high security requirements.

[0035] Embodiment 2: This embodiment is based on the above-mentioned embodiment 1, as shown in a specific embodiment. Figure 1

[0036] This embodiment aims to realize the following functions by the collaborative design of Git hook and encrypted permission file without destroying the distributed characteristics of Git: (1) File-level write permission control: dynamically match the user-modifiable directory / file according to the Glob mode.

[0037] (2) Real-time submission interception: complete permission verification before the code is submitted to the remote repository to prevent unauthorized operations.

[0038] (3) Anti-tampering mechanism: protect the permission file through asymmetric encryption to ensure the security of the rule.

[0039] The embodiment specifically includes the following steps: Step S1: initialization configuration.

[0040] Encrypted permission file: define user permissions in JSON format, including user email, Glob mode, administrator identifier and other fields; all fields are encrypted using a private key.

[0041] Step S2: asymmetric encryption and verification.

[0042] Generate key pair: the administrator generates an RSA key pair through openssl, the private key is held by the administrator, and the public key is embedded in the pre-commit hook script of the repository.​

[0043] The specific process of managing script writing update permission file is as follows: “?Developer email

; split multiple

; split multiple

; split multiple

Developer email

Permission file path

[0044] The key pair management mechanism of this embodiment is to generate a 2048 key pair using RSA algorithm, and the private key is held by the administrator himself; the public key is encoded by Base64 and hard-coded into the Git hook script, ensuring that the client does not need to access the private key to verify the signature.

[0045] The permission file signing process is that after the permission file is generated, the administrator uses the private key to select the RSA-SHA256 signature algorithm to sign the permission file, generating a signature file; the original permission file and the signature file are submitted to the root directory of the repository.

[0046] The client signature verification process is that when the hook script is executed, the local public key is read and decoded, and the public key is used to verify the validity of the signature file, detect whether the permission file has been modified and the signature has been lost, and if tampered with or lost, the submission is blocked.

[0047] Step S3: permission verification.

[0048] When the developer executes git commit, the pre-commit hook is triggered, the Base64 encoded public key is read from the hook variable PUBLIC_KEY and decoded; Use the public key to verify the signature consistency of the permission file and the signature file, if the signature file is missing or the signature verification fails, record the security event log and forcibly terminate the submission; The hook script automatically decrypts the permission file (decrypts the permission content using the public key), extracts the current user email and the modified file list.

[0049] If the user is an administrator or the file matches the permission rules, the submission is successful; otherwise, an error is returned and the unauthorized file path is listed.

[0050] Maintenance and update: Permission update: After the administrator modifies the permission file, it is re-signed and pushed to the repository, and all clients automatically synchronize.

[0051] Emergency fuse: deleting the permission file can globally disable non-administrator submissions, suitable for security incident response.

[0052] The hook types of this embodiment include embedding pre-commit (before local submission), pre-push (before pushing to remote), and other key nodes.

[0053] The verification process of this embodiment includes upstream synchronization detection: checking whether the local branch is the latest version from the remote, and if it is not the latest version, forcibly requiring git pull to avoid submission covering conflicts; user identity binding: parsing the user.email in the global configuration of Git and matching it with the user list in the permission file, using the public key to decrypt the permission file JSON; file change scanning: extracting the modified file list of this submission through git diff; permission rule matching: if the user is an administrator, directly pass; otherwise, match the file path one by one according to the Glob pattern, and the unmatched files will be intercepted; set independent permission lock for sensitive files (such as package.json), which need additional authorization.

[0054] When processing error codes and logs, this embodiment returns detailed error information (such as unauthorized file list, permission rule reference) when intercepting. Degradation strategy: when the permission file decryption fails, all non-administrator submissions are prohibited by default to ensure security.

[0055] Working principle: This embodiment first combines asymmetrically encrypted permission files with Git native hooks to implement a proactive defense mechanism of "submission verification", and the hook and encryption are deeply integrated; after updating the permission file, developers do not need to restart or reconfigure, and the new rules will be automatically applied next time the submission is submitted, realizing dynamic rule effect; through the Glob pattern, it can flexibly adapt to complex repository structures of multiple projects and multiple modules, support thousands of team collaboration, and this embodiment is suitable for monorepo or other front-end projects that want to use the client to control file-level write permissions.

[0056] The other parts of this embodiment are the same as those of the above-mentioned embodiment 1, and will not be described again.

[0057] Embodiment 3: The embodiment is based on any one of the above embodiments 1-2, and proposes a permission control system under monorepo large warehouse management of front-end code, for executing the above permission control method under monorepo large warehouse management of front-end code; including a permission configuration unit, an encryption verification unit, and a verification matching unit. The permission configuration unit is configured to initialize permission configuration, generate a permission file, and submit the permission file to a warehouse root directory. The encryption verification unit is configured to call openssl to generate a key pair, sign the permission file according to the key pair, generate a signature file, and submit the signature file to the warehouse root directory. The verification matching unit is configured to trigger a Git hook according to the obtained git commit command, verify whether the permission file signature is valid, parse a user mailbox if the permission file signature is valid, determine whether to submit a file according to a set permission matching rule, and if not, intercept and list an unauthorized file path.

[0058] The embodiment also proposes an electronic device including a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed on the processor, the above permission control method under monorepo large warehouse management of front-end code is implemented.

[0059] The embodiment also proposes a computer readable storage medium, wherein the computer readable storage medium stores computer instructions, and when the computer instructions are executed on the above electronic device, the above permission control method under monorepo large warehouse management of front-end code is implemented.

[0060] The other parts of the embodiment are the same as any one of the above embodiments 1-2, and will not be described again.

[0061] The above is only a preferred embodiment of the present application, and does not limit the present application in any form. Any simple modification or equivalent change based on the technical essence of the present application to the above embodiment falls within the protection scope of the present application.

Claims

1. A permission control method under a front-end code monorepo large warehouse management, characterized in that, Specifically comprising the following steps: Step S1: initializing the permission configuration, generating a permission file, and submitting to the repository root directory; Step S2: calling openssl to generate a key pair, signing the permission file according to the key pair, generating a signature file, and submitting to the repository root directory; Step S3: triggering the Git hook according to the obtained git commit command, checking whether the permission file signature is valid, if valid, parsing the user mailbox, and judging whether to submit the file according to the set permission matching rule; if invalid, intercepting and listing the unauthorized file path.

2. The method of claim 1, wherein the monorepo is a front-end code monorepo. The specific operation of the step S1 is: defining the user permission in JSON format, generating a permission file; the user permission includes a user mailbox field, a Glb mode field, and an administrator identifier field.

3. The method of claim 1, wherein the monorepo is a front-end code monorepo. The step S2 specifically comprises the following steps: Step S21: generating a key pair according to the asymmetric encryption algorithm of openssl; Step S22: encoding the public key and embedding the encoded public key into the Git hook script; Step S23: encrypting the user information by calling the private key, and updating the permission file content according to the encrypted user information; Step S24: calling the private key to sign the updated permission file, generating a signature file, and submitting to the repository root directory.

4. The method of claim 2, wherein the method is characterized by, The step S3 specifically comprises the following steps: Step S31: triggering the pre-commit hook according to the obtained git commit command, reading and decoding the encoded public key according to the obtained hook variable PUBLIC_KEY; Step S32: checking whether the local branch is the latest version of the remote, if not, forcing git pull to update, returning to step S31 after updating, if it is the latest version, executing step S33; Step S33: checking whether the permission file signature is valid, if the signature is invalid, intercepting the submission and prompting that the signature does not match; if the signature is valid, parsing the user Git mailbox, calling the public key to decrypt the permission file JSON, and matching with the user list in the permission file; Step S34: detecting whether the permission file exists, if not, intercepting the submission and prompting that the permission file is missing, if it exists, judging whether to submit the file according to the set permission matching rule.

5. The method of claim 4, wherein the monorepo is a front-end code monorepo. The specific operation of judging whether to submit the file according to the set permission matching rule in step S34 is: if the permission file exists, judging whether the current user is an administrator, if yes, allowing to submit; otherwise, matching the file path according to the Glob mode one by one, if all the files are matched, allowing to submit, if there are unmatched files, intercepting the submission and returning the unauthorized file list.

6. The method of claim 5, wherein the method is a method of permission control under a front-end code monorepo management. The set permission matching rule further comprises setting independent permission lock for sensitive files.

7. The method of claim 3, wherein the method is characterized by, The specific operation of the step S22 is: Base64 encoding the public key and embedding the encoded public key into the Git hook script.

8. A permission control system under monorepo management of front-end code, configured to execute the permission control method under monorepo management of front-end code according to claim 1. It comprises a permission configuration unit, an encryption verification unit, and a check matching unit; The permission configuration unit is used for initializing the permission configuration, generating a permission file, and submitting to the repository root directory; The encryption verification unit is configured to call openssl to generate a key pair, sign an authority file according to the key pair, and generate a signature file to be submitted to a repository root directory; The check matching unit is configured to trigger a Git hook according to the obtained git commit command, check whether the signature of the authority file is valid, parse a user mailbox if the signature is valid, and determine whether to submit a file according to a set authority matching rule; if the signature is invalid, intercept and list a file path exceeding the authority.

9. An electronic device, comprising: The computer readable storage medium stores computer instructions; when the computer instructions are executed on the electronic device as claimed in claim 9, the authority control method under the monorepo large warehouse management of the front-end code is realized.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer instructions; when the computer instructions are executed on the electronic device as claimed in claim 9, the authority control method under the monorepo large warehouse management of the front-end code is realized.

Images