Project data permission control method based on multi-source permission relationship aggregation and lazy loading refresh

Abstract

The present application relates to the technical field of data security, and provides a project data permission control method based on multi-source permission relationship aggregation and lazy loading refresh, comprising: collecting project permission relationships of a current user for a target data type from at least two permission sources, and writing into a unified permission relationship table according to source types; reading all project permission relationships of the current user from the permission relationship table, and if no base source permission record is read and a lazy loading trigger condition is met, triggering base permission lazy loading refresh; aggregating all the read project permission relationships into multi-source aggregated project ranges and performing intersection operation to obtain a final accessible project range; if the final accessible project range is an empty set, generating an empty permission sentinel value and inputting into a data query statement, otherwise performing secondary permission verification on single object detail access in addition to list filtering. The present application can realize high-security, high-efficiency and high-reliability enterprise-level project data permission control.

Description

Technical Field

[0001] This invention relates to the field of data security technology, and in particular to a method for controlling project data permissions based on multi-source permission relationship aggregation and lazy loading refresh. Background Technology

[0002] In enterprise-level project management information systems (PMIS), project data is accessed by multiple business entry points, including project ledgers, overviews, expenses, budgets, contracts, and process approvals. The authorization sources for each entry point are inconsistent, including base role permissions, temporary visibility scope of process approvals, and project team member relationships. This multi-source, multi-entry permission structure makes PMIS access control a complex systemic problem.

[0003] Existing technologies typically collapse the permissions from different sources into a single set of project numbers and directly append it to the SQL query conditions. This approach works in scenarios with a single permission source and a small number of projects, but it has the following drawbacks in enterprise-level systems like PMIS:

[0004] 1. Mixed permissions can easily lead to accidental deletion. When authorization relationships from different sources are stored together in the same permission table, refreshing a certain source can easily lead to the accidental deletion of valid authorizations from other sources due to the lack of source boundary markers, resulting in the unexpected loss of legitimate permissions for process approvers or project members.

[0005] 2. High maintenance costs for administrators. Full administrators need to expand permissions for all projects one by one, which requires a large amount of storage and a complete rebuild is required when the organization or project changes, resulting in low refresh efficiency.

[0006] 3. External condition injection risk. If the role condition expression returned by the base is directly entered into the query layer without security validation, it may introduce SQL injection or field privilege escalation risks.

[0007] 4. Inconsistent project identification. Projects exist in various forms such as primary keys, codes, and numbers in different systems. When the identification on the query side and the permission side is not standardized, it can easily lead to permission failures or incorrect access.

[0008] 5. Cold start with no permissions and privilege exceeding limits on empty sets. When a user accesses the site for the first time, permissions are not initialized, resulting in no permissions; if permission is granted immediately for trial purposes, privilege exceeding limits occurs. In dynamic queries, when the permission set is empty, SQL condition concatenation often misinterprets an empty set as "unrestricted," causing ordinary users to query the entire set of items.

[0009] 6. Lack of overlap in multi-dimensional filtering. There is no unified overlap mechanism between view rules, tag filtering, request conditions, and local permissions, resulting in mixed results. Users may see items they do not have permission for in the view, or items they have permission for may not be in the view.

[0010] Chinese patent CN116028963A discloses a permission management method that elevates permission management from "exhaustive data range selection" to a hierarchical authorization model that "configures value ranges according to data dimensions (such as time, region, brand)" to achieve unified permission management across application systems. This method only addresses the problem of permission model abstraction and dimension combination when granting unified authorization across multiple application systems. It does not address fine-grained data permission control issues within a single enterprise application (such as PMIS), such as isolated storage of multiple-source permissions (base role, process approval, project team), cold start lazy loading refresh, prevention of empty permission granting, and dual verification of list and details. Furthermore, it lacks protection mechanisms for scenarios such as permission source conflicts, refresh overwriting, and unauthorized access under empty conditions.

[0011] Chinese patent CN107679414A discloses a data permission management method that pre-defines data permission items into a database table and separates them from the code logic, thereby achieving the generation and centralized invocation of comprehensive permission strings for multiple permission items. This method only addresses the problem of combining permission strings for multiple data permission items under the same business object and invoking them in one go. However, it does not address the isolated storage and source boundary maintenance of permissions from multiple sources, the lazy loading and refresh mechanism during permission cold starts, the sentinel mechanism to prevent accidental release of empty permission sets, or the dual verification for list queries and detail access. Furthermore, its permission item pre-deposition method is statically configured, lacking support for dynamic refreshing of permissions from multiple sources and fine-grained intersection convergence.

[0012] Therefore, how to provide a data permission control method that can preserve the boundaries of permission sources, reduce the maintenance costs of full administrators, support cold start lazy loading, prevent the granting of empty permissions, and coordinate with external conditions such as views and labels to converge the project scope has become an urgent technical problem to be solved. Summary of the Invention

[0013] In view of this, in order to overcome the shortcomings of the prior art, the present invention aims to provide a project data permission control method based on multi-source permission relationship aggregation and lazy loading refresh.

[0014] This invention provides a method for controlling project data permissions based on multi-source permission relationship aggregation and lazy loading refresh, the method comprising:

[0015] Step S1: In response to a project data access request or permission refresh request, collect the current user's project permission relationship for the target data type from at least two permission sources, and write it into a unified permission relationship table in isolation according to the source type;

[0016] Step S2: In response to the project data query request initiated by the current user, read all the currently valid project permission relationships of the current user from the permission relationship table. If no base source permission record is read and the lazy loading trigger condition is met, trigger the base permission lazy loading refresh synchronously.

[0017] Step S3: Aggregate all the read project permission relationships into a multi-source aggregated project scope according to the source type, and then perform an intersection operation on the multi-source aggregated project scope, the request-limited project scope, the base view project scope, the tag-filtered project scope, and the inherent project scope of the business entry to obtain the final accessible project scope;

[0018] Step S4: If the final accessible project range is an empty set, generate an empty permission sentinel value that cannot hit any real project and pass it in to the data query statement; otherwise, perform a data query based on the final accessible project range. For single object detail access, perform secondary permission verification based on project code in addition to list filtering.

[0019] Optionally, in the project data permission control method based on multi-source permission relationship aggregation and lazy loading refresh of the present invention, in step S1, the permission sources include base role permissions, process approval visibility permissions and project team permissions. Each project permission relationship includes at least user identifier, data type, project identifier, project code, source type and validity status. When refreshing any source, only the old permission relationships under the same user, the same data type and the same source type are invalidated.

[0020] Optionally, in the project data permission control method based on multi-source permission relationship aggregation and lazy loading refresh of the present invention, in step S1, for administrator users or super role users who have full access to all projects, all projects are not expanded and written into the permission relationship table one by one. Instead, a predefined special project code is written as a full authorization identifier. The full authorization identifier is used to indicate that the user has full access to all projects under the corresponding data type on the local permission side during subsequent queries.

[0021] Optionally, in the project data permission control method based on multi-source permission relationship aggregation and lazy loading refresh of the present invention, in step S1, when the permission source is base role permission and the base role permission is returned in the form of a role condition expression, before converting the role condition expression into the project permission scope, a security check is performed on the role condition expression. The security check includes: detecting and rejecting expressions containing preset high-risk SQL keywords, detecting and rejecting expressions containing comment characters, semicolons, string concatenation characters or union query fragments, checking whether the fields referenced in the expression belong to the pre-configured project field whitelist, and checking whether the expression can be correctly converted into filtering conditions based on project master data; only when the role condition expression passes all security checks is it converted into the corresponding project primary key and project code set, and written into the permission relationship table as the project permission relationship of the base role permission source.

[0022] Optionally, in the project data permission control method based on multi-source permission relationship aggregation and lazy loading refresh of the present invention, in step S1, the project number, external system project identifier and local project primary key returned by different permission sources are uniformly mapped to the project master data of the project management system to generate a unified local project primary key and project code, so that the project identifiers from different systems are stored in the permission relationship table in the same project code form.

[0023] Optionally, in the project data permission control method based on multi-source permission relationship aggregation and lazy loading refresh of the present invention, the lazy loading triggering condition in step S2 is: there is no valid record of any base role permission source for the current user's corresponding data type in the permission relationship table, and the business entry corresponding to the project data query request initiated by the current user is marked as allowing lazy loading in the system configuration; the lazy loading refresh specifically includes: calling the base permission adapter to request the latest role permission range of the current user on the data type from the base permission platform, writing the obtained permission range into the permission relationship table, and setting the old permission relationship under the same base source to invalid, rereading after the refresh is completed, and not allowing access by default when the refresh fails.

[0024] Optionally, in the project data permission control method based on multi-source permission relationship aggregation and lazy loading refresh of the present invention, in step S3, if the current user's aggregated project scope includes a full authorization identifier, the current user's local permission side is regarded as having the full project scope in the intersection operation. However, the full authorization identifier does not bypass the constraints of the request-limited project scope, the base view project scope, the tag-filtered project scope, and the inherent project scope of the business entry. The current user can only access projects that simultaneously meet all external filtering conditions.

[0025] Optionally, in the project data permission control method based on multi-source permission relationship aggregation and lazy loading refresh of the present invention, in step S3, the requested limited project scope is the set of projects explicitly specified by the current user in the request parameters when initiating the project data query request; the base view project scope is the set of viewable projects limited by the rules of the base view where the current user is currently located; the tag-filtered project scope is the set of projects associated with the tag dimension selected by the current user during the query; the inherent project scope of the business entry is the accessible project scope constraint defined by the business entry itself; when performing the intersection operation, if any necessary scope among the requested limited project scope, the base view project scope, or the inherent project scope of the business entry is empty, the final accessible project scope is directly determined to be an empty set.

[0026] Optionally, in the project data permission control method based on multi-source permission relationship aggregation and lazy loading refresh of the present invention, in step S4, the empty permission sentinel value is a preset special code value that does not exist in the project master data of the project management system. This special code value is different from the project codes of all real projects. When the final accessible project range is an empty set, the data access layer passes the empty permission sentinel value as the matching condition of the project code when concatenating the structured query language query conditions, so that the query result is always empty.

[0027] Optionally, in the project data permission control method based on multi-source permission relationship aggregation and lazy loading refresh of the present invention, step S4, the secondary permission verification specifically includes: if the current user requests access to the details of a single business object, after reading the business object from the database, extracting the project code to which the business object belongs; matching the extracted project code with the current user's final accessible project range in the corresponding data type; if the match fails and the current user's aggregated project range does not contain a full authorization identifier, then the return of the business object's details information is refused; if the match succeeds or contains a full authorization identifier, then the return of details information is allowed.

[0028] The project data permission control method based on multi-source permission relationship aggregation and lazy loading refresh of the present invention has the following beneficial technical effects: it realizes closed-loop control of the entire link of permission writing, reading, convergence and review, which can solve the complexity of multi-source permission management in enterprise-level PMIS, avoid the spread of permission vulnerabilities in a single link to the entire query link, and completely eliminate the risks of empty permission overreach and single object bypass while ensuring that multi-source permissions do not interfere with each other and cold start availability. It achieves highly secure, efficient and reliable enterprise-level project data permission control, and significantly improves the integrity and reliability of permission control. Attached Figure Description

[0029] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0030] Figure 1 This is a flowchart illustrating the project data permission control method based on multi-source permission relationship aggregation and lazy loading refresh according to an exemplary embodiment 1 of the present invention.

[0031] Figure 2 This is a schematic diagram illustrating the process of writing and activating the full authorization identifier according to an exemplary embodiment 1 of the present invention;

[0032] Figure 3 This is a flowchart illustrating the security verification of the base role condition expression in the method of Exemplary Embodiment 1 of the present invention;

[0033] Figure 4 This is a schematic diagram illustrating the process of triggering and executing lazy loading refresh of base permissions according to an exemplary embodiment 1 of the present invention;

[0034] Figure 5 This is a schematic diagram illustrating the constraint process of the full authorization identifier in the intersection operation according to Exemplary Embodiment 1 of the present invention;

[0035] Figure 6 This is a flowchart illustrating the generation of null permission sentinel values ​​and the prevention of accidental SQL injection in the method of exemplary embodiment 1 of the present invention.

[0036] Figure 7 This is a flowchart illustrating the secondary permission verification process for single-object details access according to an exemplary embodiment 1 of the present invention. Detailed Implementation

[0037] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0038] It should be noted that, in the absence of conflict, the following embodiments and features can be combined with each other; and, based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0039] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.

[0040] Example 1

[0041] Exemplary embodiment 1 of the present invention provides a method for controlling project data permissions based on multi-source permission relationship aggregation and lazy loading refresh. Figure 1 This is a flowchart illustrating the project data permission control method based on multi-source permission relationship aggregation and lazy loading refresh according to an exemplary embodiment 1 of the present invention. Figure 1 As shown, in this embodiment, the method of the present invention is implemented in the following manner:

[0042] Step S1: In response to a project data access request or permission refresh request, collect the current user's project permission relationship for the target data type from at least two permission sources, and write it into a unified permission relationship table in isolation according to the source type.

[0043] In this embodiment, the permission sources include base role permissions, workflow approval visibility permissions, and project team permissions. Each project permission relationship includes at least user identifier, data type, project identifier, project code, source type, and validity status. When refreshing any source, only the old permission relationships under the same user, the same data type, and the same source type will be invalidated.

[0044] This embodiment sets a source type field in the permission relationship and precisely invalidates permissions according to three dimensions: user, data type, and source type during refresh. This ensures that permissions from different sources are isolated from each other during the writing and refresh process. The refresh operation of any source will not accidentally delete the valid authorizations written by other sources. This effectively solves the problem of permission overwriting in the traditional mixed-write mode, ensures the stable existence of temporary permissions for process approval and project team permissions when the base permissions are refreshed on a large scale, and improves the reliability of multi-source permission coexistence.

[0045] Figure 2 This is a schematic diagram illustrating the process of writing and activating the full authorization identifier according to Exemplary Embodiment 1 of the present invention, as follows: Figure 2As shown in this embodiment, for administrator users or super users who have full access to all items, all items are not expanded and written into the permission relationship table one by one. Instead, a predefined special item code is written as a full authorization identifier. The full authorization identifier is used to indicate in subsequent queries that the user has full access to all items under the corresponding data type on the local permission side.

[0046] This embodiment reduces the storage complexity of full authorization from O(n) to O(1) by setting a full authorization identifier for administrators or super users instead of storing all projects one by one, significantly reducing the storage pressure on the permission relationship table. At the same time, since there is no need to rebuild administrator permissions when the organizational structure or project data changes, the permission refresh time is reduced from tens of minutes or even hours to milliseconds, significantly improving operational efficiency.

[0047] Figure 3 This is a flowchart illustrating the security verification of the base role condition expression in the method of Exemplary Embodiment 1 of the present invention, as shown below. Figure 3 As shown in this embodiment, when the permission source is a base role permission and the base role permission is returned in the form of a role condition expression, a security check is performed on the role condition expression before converting it into a project permission scope. This security check includes: detecting and rejecting expressions containing preset high-risk SQL keywords, detecting and rejecting expressions containing comment characters, semicolons, string concatenation characters, or union query fragments, checking whether the fields referenced in the expression belong to the pre-configured project field whitelist, and checking whether the expression can be correctly converted into filtering conditions based on project master data. Only when the role condition expression passes all security checks is it converted into the corresponding project primary key and project code set, and the project permission relationship from which the base role permission comes is written into the permission relationship table.

[0048] By setting multi-layered security checks on the base role condition expressions, security threats such as SQL injection, field privilege escalation, and condition bypass are blocked at the source. This ensures that only safe and legal condition expressions can be converted into the project's permission scope, significantly reducing the security risks caused by abnormal or malicious input from external permission platforms and improving overall security protection capabilities.

[0049] In this embodiment, the project number, external system project identifier, and local project primary key returned from different permission sources are uniformly mapped to the project master data of the project management system, generating a unified local project primary key and project code, so that project identifiers from different systems are stored in the permission relationship table in the same project code format.

[0050] This embodiment maps project numbers, external system identifiers, and local primary keys returned from different sources to the project master data in a unified manner. This allows cross-system permission data to be compared under a unified reference system, avoiding permission failures or incorrect hits due to inconsistent project identifiers. It eliminates data heterogeneity barriers in multi-system integration environments, ensures the accuracy of permission judgment, and improves the stability of cross-system permission collaboration.

[0051] Step S2: In response to the project data query request initiated by the current user, read all currently valid project permission relationships of the current user from the permission relationship table. If no base source permission record is read and the lazy loading trigger condition is met, trigger the base permission lazy loading refresh synchronously.

[0052] This embodiment sets lazy loading trigger conditions and a refresh failure denial policy to automatically trigger base permission refresh when the user visits for the first time or when the cache is missing. This effectively solves the problem of no permissions during cold starts and avoids access anomalies caused by uninitialized permissions. At the same time, the design of strictly denying refresh failures eliminates the risk of unauthorized permissions caused by default authorization in pursuit of a good first-screen experience, achieving a reasonable balance between user experience and data security.

[0053] Figure 4 This is a schematic diagram illustrating the process of triggering and executing lazy loading refresh of base permissions according to an exemplary embodiment 1 of the present invention, as follows: Figure 4 As shown, in this embodiment, the lazy loading trigger condition is: there is no valid record of any base role permission source for the current user's corresponding data type in the permission relationship table, and the business entry corresponding to the project data query request initiated by the current user is marked as allowing lazy loading in the system configuration; lazy loading refresh specifically includes: calling the base permission adapter to request the latest role permission range of the current user on the data type from the base permission platform, writing the obtained permission range into the permission relationship table, and setting the old permission relationship under the same base source to invalid. After the refresh is completed, it is reread, and if the refresh fails, it is not allowed by default.

[0054] Step S3: Aggregate all the read project permission relationships into a multi-source aggregated project scope according to the source type. Then, perform an intersection operation on the multi-source aggregated project scope, the request-limited project scope, the base view project scope, the tag-filtered project scope, and the inherent project scope of the business entry to obtain the final accessible project scope.

[0055] Figure 5 This is a schematic diagram illustrating the constraint process of the full authorization identifier in the intersection operation according to Exemplary Embodiment 1 of the present invention, as follows: Figure 5As shown in this embodiment, if the current user's aggregated project scope includes a full authorization identifier, the current user's local permissions are considered to have the full project scope in the intersection operation. However, the full authorization identifier does not bypass the constraints of the request-limited project scope, the base view project scope, the tag-filtered project scope, and the inherent project scope of the business entry. The current user can only access projects that simultaneously meet all external filtering conditions.

[0056] This embodiment retains the constraints of request-limited project scope, base view project scope, tag-filtered project scope, and inherent project scope of business entry while the full authorization identifier is in effect. This ensures that administrators with full permissions are still subject to reasonable restrictions from external filtering conditions such as view rules and business entry, preventing the full authorization identifier from being abused as a universal key to bypass all permission controls, and achieving an organic combination of full permissions and scenario-based constraints.

[0057] In this embodiment, the requested project scope is the set of projects explicitly specified by the current user in the request parameters when initiating a project data query request; the base view project scope is the set of viewable projects limited by the rules of the base view where the current user is currently located; the tag-filtered project scope is the set of projects associated with the tag dimension selected by the current user during the query; the inherent project scope of the business entry is the accessible project scope constraint defined by the business entry itself; when performing the intersection operation, if any necessary scope among the requested project scope, the base view project scope, or the inherent project scope of the business entry is empty, the final accessible project scope is directly determined to be an empty set.

[0058] This embodiment avoids the performance overhead caused by invalid intersection operations by determining whether the necessary range is empty before performing the intersection operation and terminating the operation in advance. At the same time, it unifies the convergence of the request range, view range, tag range and business entry range to ensure that users can only access items that meet all dimensional constraints at the same time. This effectively solves the problem of multiple filtering conditions taking effect separately and mixed results in traditional solutions, and improves the accuracy of permission filtering and query efficiency.

[0059] Step S4: If the final accessible project range is an empty set, generate an empty permission sentinel value that cannot hit any real project and pass it in to the data query statement; otherwise, perform a data query based on the final accessible project range. For single object detail access, perform secondary permission verification based on project code in addition to list filtering.

[0060] Figure 6 This is a schematic diagram illustrating the process of generating null permission sentinel values ​​and preventing accidental SQL injection in the method of Exemplary Embodiment 1 of the present invention, as follows: Figure 6As shown, in this embodiment, the empty permission sentinel value is a preset special code value that does not exist in the project master data of the project management system. This special code value is different from the project codes of all real projects. When the final accessible project range is an empty set, the data access layer passes the empty permission sentinel value as the matching condition of the project code when concatenating the structured query language query conditions, so that the query result is always empty.

[0061] This embodiment ensures that SQL queries always generate explicit no-result conditions when a user has no accessible items by setting a null permission sentinel value that is different from the codes of all real projects. This fundamentally solves the privilege escalation vulnerability in traditional dynamic SQL where an empty set is misinterpreted as "unrestricted" and returns the full data. It does not rely on additional judgments at the application layer and directly guarantees the security of null permissions at the data access layer. It is a lightweight and reliable anti-allowing solution.

[0062] Figure 7 This is a flowchart illustrating the single-object details access secondary permission verification method according to Exemplary Embodiment 1 of the present invention, as follows: Figure 7 As shown in this embodiment, the secondary permission verification specifically includes: if the current user requests access to the details of a single business object, after reading the business object from the database, the project code to which the business object belongs is extracted; the extracted project code is matched with the current user's final accessible project range in the corresponding data type; if the match fails and the current user's aggregated project range does not contain a full authorization identifier, the details information of the business object is refused to be returned; if the match is successful or contains a full authorization identifier, the details information is allowed to be returned.

[0063] This embodiment constructs a two-layer protection system of list filtering and detail verification by adding a secondary permission check based on the project code after the details data is read and before it is returned. Even if the list query permission conditions fail to take effect due to an unexpected vulnerability, the secondary verification at the details layer can still block unauthorized access, effectively preventing the risk of bypassing list filtering to access single object data by directly accessing the details URL or constructing parameters, and significantly improving the defense-in-depth capability.

[0064] Example 2

[0065] Exemplary Example 2 of the present invention provides a project data permission control method based on multi-source permission relationship aggregation and lazy loading refresh. In this embodiment, the method of the invention is further described in detail in conjunction with an enterprise-level PMIS system. The system is used to run the method of the invention, specifically, it is executed in the following manner:

[0066] Step 1: Data representation of permission relationships

[0067] The system uses a unified data permission relationship table to record the authorization relationships between personnel and project data. Each record includes at least the user ID, data type, project primary key, project code, source type, validity status, creation time, and update time. The data type distinguishes different business data such as projects, contracts, budgets, and expenses; the source type distinguishes base permissions, process permissions, project team permissions, or subsequent extended sources; and the validity status supports soft failures and historical tracking.

[0068] For project data permissions, the system prioritizes the project master data as the standardization benchmark. When an external system or base returns a project number, it is first converted into the local project primary key and project code; when the local business relationship only provides the project primary key, the project code is also filled back, thus ensuring that permission queries and business queries use the same project representation.

[0069] Step 2: Source Isolation Refresh

[0070] When the system refreshes permission relationships for a specific source, it first identifies the old relationships based on the user, data type, and source type, and only invalidates old relationships under the same source. Then, it writes the newly collected permission relationships. For example, a base permission refresh only updates records with the source type "base," and does not invalidate temporary project permissions generated during the workflow approval process, nor does it invalidate permissions generated by project team member relationships. This avoids the accidental deletion of legitimately visible projects by workflow approvers or project members due to "base refresh failure or scope reduction."

[0071] Step 3: Expressing full administrator privileges

[0072] For full project authorizations returned by PMIS administrators, super project roles, or base servers, the system does not write all projects to the permission relationship table one by one. Instead, it writes a special project code as a full authorization identifier. During a query, if this identifier is detected, it is assumed that the user has full project access capability on the local permission side. This full capability does not equate to bypassing all restrictions. In actual queries, the full authorization identifier only indicates that the project set is no longer narrowed down through the local permission table; request conditions, base view scope, tag filtering scope, and business entry rules still need to be superimposed. For example, when a user queries in a certain view, even with a full authorization identifier, they can only query projects allowed by the rules of that view.

[0073] Step 4: Safe conversion of base role conditions

[0074] The base permission platform may return a role condition expression describing the scope of items a user can access. This invention incorporates a security verification step before converting this expression, including at least the following processing:

[0075] 1. Verify whether the expression contains high-risk keywords such as delete, update, insert, merge, truncate, or execute.

[0076] 2. Check for dangerous segments such as semicolons, comment characters, concatenation characters, and union queries.

[0077] 3. Verify whether the field belongs to the whitelist of allowed project fields.

[0078] 4. Verify whether the expression can be converted into project master data filtering conditions.

[0079] Only those conditions that pass the above validation will be entered into the project master data query and converted into local project permission relationships. Conditions that fail the validation will be rejected or downgraded to empty permission results.

[0080] Step 5: Lazy loading refresh on the query side

[0081] When a user initiates a query for a project list or details, the system first reads the currently valid permission relationships. If it finds that the user does not have a base source permission record, and the business entry allows lazy loading refresh, it synchronously calls the base permission adapter to refresh the current user's permissions.

[0082] After lazy loading and refreshing, the system reads the permission relationships again. If the refresh fails, the failure status is retained, and restricted query logic is entered; access is not granted by default simply because the base is unavailable. For ordinary users, an empty permission sentinel is written when the final result is empty; for users with valid permissions from other sources, they can still access items explicitly authorized by those sources.

[0083] Step Six: Convergence of the Intersection of Permission Ranges

[0084] The system will uniformly include the following scopes into the project scope convergence module:

[0085] 1. The scope of projects obtained by aggregating user permissions from multiple sources.

[0086] 2. Items, item codes, or collections of items explicitly specified in the request parameters.

[0087] 3. The scope of the project returned by the base view rules.

[0088] 4. The scope of projects obtained by tag filtering.

[0089] 5. The scope of projects limited by the business entry point itself.

[0090] The range convergent calculates the intersection according to the principles of "the more specific, the higher the priority; no permission is allowed; and administrators are still subject to external filtering constraints." If any necessary range is empty, the final result is empty; if an optional capability call fails, such as due to a tag interface exception, only that optional range is downgraded to empty or skipped, depending on the degradation strategy of the business entry point.

[0091] Step 7: Setting up a Sentinel with No Permissions

[0092] To prevent dynamic SQL from failing to generate restrictions when the set is empty, this embodiment sets an empty permission sentinel. When a regular user has no accessible items, or when there are no items after multiple range intersections, the permission binder will not pass an empty set, but instead pass a special value that will not hit the actual item. The business query configuration can always generate restrictions where the item code is not equal to the actual data when concatenating query conditions, thus returning an empty result and preventing an empty set from being misinterpreted as "no restriction required".

[0093] Step 8: Secondary Verification of Details

[0094] For interfaces such as project details, project budget, project expenses, and project contract lookup, the system performs permission filtering in the list and a secondary verification after reading the details. The verification method involves extracting the project code of the details object and matching it with the user's current permission scope. If no match is found and the user does not have the full authorization identifier, the details will not be returned.

[0095] Step Nine: Coordination of Scheduled Refresh, Manual Refresh, and Lazy Loading

[0096] The system supports three refresh modes: scheduled refresh, manual refresh by administrators, and lazy refresh during queries. Scheduled refresh is used to maintain the freshness of most user permission relationships; manual refresh is used to investigate permission anomalies or handle organizational changes; lazy refresh is used to solve cold start problems when a user visits for the first time or when the cache is not initialized. All three refresh modes reuse the source isolation failure mechanism, so the failure of one mode will not break the permission relationships of other sources.

[0097] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of various embodiments or some parts of embodiments.

[0098] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for controlling project data permissions based on multi-source permission relationship aggregation and lazy loading refresh, characterized in that, The method includes: Step S1: In response to a project data access request or permission refresh request, collect the current user's project permission relationship for the target data type from at least two permission sources, and write it into a unified permission relationship table in isolation according to the source type; Step S2: In response to the project data query request initiated by the current user, read all the currently valid project permission relationships of the current user from the permission relationship table. If no base source permission record is read and the lazy loading trigger condition is met, trigger the base permission lazy loading refresh synchronously. Step S3: Aggregate all the read project permission relationships into a multi-source aggregated project scope according to the source type, and then perform an intersection operation on the multi-source aggregated project scope, the request-limited project scope, the base view project scope, the tag-filtered project scope, and the inherent project scope of the business entry to obtain the final accessible project scope; Step S4: If the final accessible project range is an empty set, generate an empty permission sentinel value that cannot hit any real project and pass it in to the data query statement; otherwise, perform a data query based on the final accessible project range. For single object detail access, perform secondary permission verification based on project code in addition to list filtering.

2. The project data permission control method based on multi-source permission relationship aggregation and lazy loading refresh according to claim 1, characterized in that, In step S1, the permission sources include base role permissions, workflow approval visibility permissions, and project team permissions. Each project permission relationship must include at least user identifier, data type, project identifier, project code, source type, and validity status. When refreshing any source, only the old permission relationships under the same user, the same data type, and the same source type will be invalidated.

3. The project data permission control method based on multi-source permission relationship aggregation and lazy loading refresh according to claim 1, characterized in that, In step S1, for administrator users or super users who have full access to all items, instead of expanding all items one by one and writing them into the permission relationship table, a predefined special item code is written as a full authorization identifier. The full authorization identifier is used to indicate in subsequent queries that the user has full access to all items under the corresponding data type on the local permission side.

4. The project data permission control method based on multi-source permission relationship aggregation and lazy loading refresh according to claim 1, characterized in that, In step S1, when the permission source is a base role permission and the base role permission is returned in the form of a role condition expression, a security check is performed on the role condition expression before converting it into a project permission scope. This security check includes: detecting and rejecting expressions containing preset high-risk SQL keywords, detecting and rejecting expressions containing comment characters, semicolons, string concatenation characters, or union query fragments, checking whether the fields referenced in the expression belong to the pre-configured project field whitelist, and checking whether the expression can be correctly converted into filtering conditions based on project master data. Only when the role condition expression passes all security checks is it converted into the corresponding project primary key and project code set, and the project permission relationship from which the base role permission comes is written into the permission relationship table.

5. The project data permission control method based on multi-source permission relationship aggregation and lazy loading refresh according to claim 1, characterized in that, In step S1, the project number, external system project identifier, and local project primary key returned from different permission sources are uniformly mapped to the project master data of the project management system to generate a unified local project primary key and project code, so that project identifiers from different systems are stored in the permission relationship table in the same project code format.

6. The project data permission control method based on multi-source permission relationship aggregation and lazy loading refresh according to claim 1, characterized in that, In step S2, the lazy loading trigger condition is: there is no valid record of any base role permission source for the current user's corresponding data type in the permission relationship table, and the business entry corresponding to the project data query request initiated by the current user is marked as allowing lazy loading in the system configuration; Lazy loading refresh specifically includes: calling the base permission adapter to request the latest role permission range of the current user in terms of data type from the base permission platform, writing the obtained permission range into the permission relationship table, and setting the old permission relationship under the same base source to invalid. After the refresh is completed, it is reread, and if the refresh fails, it is not allowed by default.

7. The project data permission control method based on multi-source permission relationship aggregation and lazy loading refresh according to claim 1, characterized in that, In step S3, if the current user's aggregated project scope includes a full authorization identifier, the current user's local permissions are considered to have the full project scope in the intersection operation. However, the full authorization identifier does not bypass the constraints of the request-limited project scope, the base view project scope, the tag-filtered project scope, and the inherent project scope of the business entry. The current user can only access projects that simultaneously meet all external filtering conditions.

8. The project data permission control method based on multi-source permission relationship aggregation and lazy loading refresh according to claim 1, characterized in that, In step S3, the request-limited project scope is the set of projects explicitly specified by the current user in the request parameters when initiating the project data query request; the base view project scope is the set of viewable projects limited by the rules of the base view where the current user is currently located; the tag-filtered project scope is the set of projects associated with the tag dimension selected by the current user during the query; the business entry inherent project scope is the accessible project scope constraint defined by the business entry itself; when performing the intersection operation, if any necessary scope among the request-limited project scope, the base view project scope, or the business entry inherent project scope is empty, the final accessible project scope is directly determined to be an empty set.

9. The project data permission control method based on multi-source permission relationship aggregation and lazy loading refresh according to claim 1, characterized in that, In step S4, the empty permission sentinel value is a preset special code value that does not exist in the project master data of the project management system. This special code value is different from the project codes of all real projects. When the final accessible project range is an empty set, the data access layer passes the empty permission sentinel value as the matching condition of the project code when concatenating the structured query language query conditions, so that the query result is always empty.

10. The project data permission control method based on multi-source permission relationship aggregation and lazy loading refresh according to claim 1, characterized in that, In step S4, the secondary permission verification specifically includes: if the current user requests access to the details of a single business object, after reading the business object from the database, the project code to which the business object belongs is extracted; the extracted project code is matched with the current user's final accessible project range in the corresponding data type; if the match fails and the current user's aggregated project range does not contain a full authorization identifier, the return of the business object's details information is refused; if the match succeeds or contains a full authorization identifier, the return of details information is allowed.

Images