Permission filtering method, device and equipment and computer readable storage medium
By loading permission rules into the SaaS service and binding the user list to obtain the interface and aspect, and using AOP technology for permission filtering, the problem of implementing permission control without intruding on business code is solved, achieving code maintainability and scalability, while meeting the diverse permission needs of different customers.
Patent Information
- Application Number
- CN202511090345.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-08-05
- Publication Date
- 2025-11-11
AI Technical Summary
In SaaS services, existing technologies struggle to implement access control without intruding on business code, resulting in fragmented code, difficulty in modification, and an inability to balance access control with code maintainability and scalability.
By preloading permission rules and binding the user list retrieval interface to aspects, AOP technology is used to intercept and filter the original user list, and a visible user list is generated according to the permission rules, thus achieving permission filtering.
Without modifying the business code, permission filtering and business logic were separated, ensuring code maintainability and scalability, meeting the diverse data permission needs of customers in different business sectors, and reducing database pressure and interface response time.
Smart Images
Figure CN120929157A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer technology, and in particular to a permission filtering method, apparatus, device, and computer-readable storage medium. Background Technology
[0002] In SaaS (Software as a Service) services, different business customers have diverse data permission requirements (such as visibility to all employees, visibility within departments, and differentiated permissions for franchisees). If these requirements are implemented in the business code, various situations need to be considered, resulting in scattered code, difficulty in modification, and susceptibility to problems. It is difficult to balance permission control with code maintainability and scalability.
[0003] Therefore, how to provide a method for implementing access control without intruding on business logic is a technical problem that urgently needs to be solved. Summary of the Invention
[0004] In view of this, the purpose of the present invention is to provide a permission filtering method, apparatus, device and computer-readable storage medium, which solves the problem in the prior art of how to implement permission control methods without intruding on business code.
[0005] To address the aforementioned technical problems, this invention provides a permission filtering method, comprising:
[0006] Preload the permission rules and bind the user list retrieval interface to the aspect;
[0007] When a request to retrieve the user list is received, the business logic of the user list retrieval interface is executed to obtain the original user list.
[0008] The original user list is intercepted by the aforementioned interface, and filtered according to the permission rules, and the filtered list of visible users is returned.
[0009] Optionally, permission rules are preloaded, and the user list retrieval interface is bound to the aspect, including:
[0010] Load and parse the permission rules; the permission rules include global rules for data permissions for customers in different business formats;
[0011] Add permission filtering annotations to the user list retrieval interface and configure the aspect for the user list retrieval interface.
[0012] Optionally, the original user list is intercepted through the aforementioned aspect, and the original user list is filtered according to the permission rules to return the filtered list of visible users, including:
[0013] By intercepting the original user list through the aforementioned face and parsing the call request, the current user's identity information can be determined;
[0014] Determine whether the target user list exists in the current user's cache; the target user list is determined based on the current user's identity information and the permission rules;
[0015] If they exist, the original user list is filtered according to the target user list, and the filtered visible user list is returned.
[0016] If the target user list does not exist, the target user list is determined based on the current user identity information and the permission rules. The original user list is then filtered based on the target user list, and the filtered visible user list is returned. Simultaneously, the target user list is written to the cache.
[0017] Optionally, after writing the target user list to the cache, the method further includes:
[0018] When a change is detected in the current user identity information and / or the permission rules, the target user list in the cache is cleared;
[0019] And / or, set a cache duration, and when the cache duration is reached, clear the target user list from the cache.
[0020] Optionally, before intercepting the original user list through the aforementioned aspect, filtering the original user list according to the permission rules, and returning the filtered list of visible users, the method further includes:
[0021] Configure the super administrator parameters in advance for the user list retrieval interface;
[0022] Accordingly, the interception of the original user list through the aforementioned aspect, the filtering of the original user list according to the permission rules, and the return of the filtered visible user list include:
[0023] By intercepting the original user list through the aforementioned aspect and parsing the call request, the parameter value of the super administrator parameter is obtained;
[0024] When the parameter value is true, the original user list is returned directly;
[0025] When the parameter value is false, the original user list is filtered according to the permission rules, and the filtered visible user list is returned.
[0026] Optionally, the original user list is intercepted through the aforementioned aspect, and the original user list is filtered according to the permission rules to return the filtered list of visible users, including:
[0027] By intercepting the original user list through the aforementioned face and parsing the call request, the current user's identity information can be determined;
[0028] Based on the current user's identity information, determine whether the current user is a designated person who can see all users;
[0029] If so, return the original user list;
[0030] If not, then determine whether there is a uniformly public department or user;
[0031] If they exist, return the personnel within the organizational structure, as well as the departments or users that are publicly available.
[0032] If not found, return the personnel within the organizational structure.
[0033] Optionally, the original user list is intercepted through the aforementioned aspect, and the original user list is filtered according to the permission rules to return the filtered list of visible users, including:
[0034] By intercepting the original user list through the aforementioned face and parsing the call request, the current user's identity information can be determined;
[0035] Based on the current user's identity information, determine whether the current user is a designated person within a visible organizational structure;
[0036] If so, return to the personnel within the organizational structure;
[0037] If not, determine whether there are hidden departments or personnel;
[0038] If they exist, return all personnel from the original user list except for the hidden department or personnel.
[0039] If it does not exist, return the original user list.
[0040] The present invention also provides a permission filtering device, comprising:
[0041] The configuration module is used to preload permission rules and bind the user list retrieval interface to the aspect;
[0042] The execution module is used to execute the business logic of the user list retrieval interface to obtain the original user list when a call request for the user list retrieval interface is received.
[0043] The filtering module is used to intercept the original user list through the interface, filter the original user list according to the permission rules, and return the filtered visible user list.
[0044] The present invention also provides a permission filtering device, comprising:
[0045] Memory, used to store computer programs;
[0046] A processor for implementing the permission filtering method described above when executing the computer program.
[0047] The present invention also provides a computer-readable storage medium storing computer-executable instructions, which, when loaded and executed by a processor, implement the permission filtering method described above.
[0048] As can be seen, this invention pre-loads permission rules and binds the user list retrieval interface to an aspect. When a call request to the user list retrieval interface is received, the business logic of the user list retrieval interface is executed to obtain the original user list. The aspect intercepts the original user list and filters it according to the permission rules, returning the filtered visible user list. This method does not require modification of the interface's business code, achieving separation of permission filtering and business logic. In other words, it achieves data permission control without intruding on business code, while solving problems such as scattered business code and difficulty in modification, ensuring code maintainability and scalability, and ultimately meeting the diverse data permission needs of customers in different business sectors.
[0049] In addition, the present invention also provides a permission filtering device, apparatus, and computer-readable storage medium, which also have the above-mentioned beneficial effects. Attached Figure Description
[0050] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.
[0051] Figure 1 A flowchart of a permission filtering method provided in an embodiment of the present invention;
[0052] Figure 2 A flowchart illustrating a specific permission filtering method provided in an embodiment of the present invention;
[0053] Figure 3 A flowchart illustrating a permission filtering method provided in an embodiment of the present invention;
[0054] Figure 4 A flowchart illustrating another permission filtering method provided in an embodiment of the present invention;
[0055] Figure 5 This is a schematic diagram of the structure of a permission filtering device provided in an embodiment of the present invention;
[0056] Figure 6 This is a schematic diagram of the structure of a permission filtering device provided in an embodiment of the present invention. Detailed Implementation
[0057] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0058] In SaaS services, different business types have different needs. Some require all company personnel to be able to see the information, while others only allow visibility to personnel within their own department. Still others have franchisees who must be able to see only the franchisees themselves, while headquarters staff must be able to see them. Furthermore, the visible personnel vary across different modules and pages; for example, some global configurations require visibility to all users. In short, the requirements are diverse, and implementing them all in the business logic code would require considering various scenarios, resulting in fragmented code that is difficult to modify and prone to errors.
[0059] To address the aforementioned issues and achieve a technical effect that supports rich organizational structure visibility rules for enterprises without affecting existing business logic, this invention provides a permission filtering method. Please refer to [link / reference needed] for details. Figure 1 , Figure 1 A flowchart illustrating a permission filtering method provided in an embodiment of the present invention. The method may include:
[0060] S101: Preload permission rules and bind the user list retrieval interface to the aspect.
[0061] The execution subject in this embodiment is the terminal. This embodiment is not limited to any particular type of terminal, as long as it can perform the permission filtering operation. It should be noted that the aspect in this embodiment is a combination of advice and pointcut. Simply put, it centralizes and manages cross-cutting concerns scattered in various places. Advice specifies the concrete operation to be performed at a particular join point. Common advice types include before, after, around, after returning, and after throwing. Pointcut defines which join points will trigger the corresponding advice. Precise matching can be achieved using conditions such as method name and parameter type. The specific implementation of the aspect can be AOP (Aspect-Oriented Programming). As a programming paradigm, AOP can separate cross-cutting concerns such as permission filtering from the core business logic, making the code structure clearer and improving code maintainability and reusability. In other words, this embodiment can use AOP technology to directly modify the return values of specific interfaces that require permission filtering, thereby achieving data permission filtering. This allows for fine-grained data permission control without intruding on business logic code, while maintaining code maintainability and extensibility.
[0062] Furthermore, the aforementioned pre-loading of permission rules and binding of the user list retrieval interface to the aspect can specifically include the following steps:
[0063] S11: Load and parse permission rules; permission rules include global rules for data permissions for customers in different business sectors.
[0064] In this embodiment, global rules for data permissions for different business types of customers are pre-configured. After configuration, the interface can display personnel according to the rules. Different business types of customers here refer to customer groups belonging to different business types, business models, or industry categories. The essence of business type here is the classification of customer business attributes. For example, in the enterprise service scenario: (1) From the industry perspective, there may be retail business type customers (such as supermarkets, e-commerce), manufacturing business type customers (such as electronics factories, automobile factories), service industry type customers (such as catering, logistics), etc.; (2) From the business model perspective, there may be chain business type customers (such as chain hotels, chain restaurants), single business type customers (such as independent clothing stores, local law firms), etc. Different business types of customers may have different business needs, organizational structures, and permission management logic (for example, chain business type customers may need cross-store permission control, while single business type customers are more concerned about departmental permissions). That is to say, the permission rules in this embodiment cover the diverse needs of different business types of customers for data permissions, such as visibility to all employees, visibility within departments, and franchisee permission differentiation, etc., and store them in the system's rule storage module.
[0065] S12: Add permission filtering annotations to the user list retrieval interface and configure aspects for the user list retrieval interface.
[0066] In this embodiment, permission filtering annotations are added to the target interfaces that need to be filtered (i.e., the user list retrieval interface) in advance, and aspects are configured for these target interfaces. In this way, the aspects know which interfaces to focus on.
[0067] S102: When a request to retrieve the user list is received, the business logic of the user list retrieval interface is executed to obtain the original user list.
[0068] When the user list retrieval interface receives a call request from a user, it executes its business logic normally and retrieves the results from the database. This query process is only affected by the interface's business conditions (such as department, position, etc.), does not consider permission restrictions, and consists of unfiltered raw data.
[0069] S103: Intercept the original user list through an interface, filter the original user list according to the permission rules, and return the filtered list of visible users.
[0070] After the user list retrieval interface completes its business logic, the interface intercepts the returned original user list and filters it according to permission rules, returning the filtered list of visible users to the user. This embodiment does not limit the permission rules. For example, permission rules can include main rules, hidden rules, and supplementary rules. Hidden rules have the highest priority, followed by supplementary rules, and main rules have the lowest priority. Main rule 1 allows members to see only members within the organizational structure by default, with the overall priority being: business parameters (referring to the `superOperation` parameter) > supplementary rules > main rule 1; main rule 2 allows members to see all members by default, with the overall priority being: supplementary rules > main rule 2 (regardless of business parameters). Supplementary rules can be understood as rules further supplemented based on the above main rules (basic rules), and this embodiment does not limit the number of supplementary rules.
[0071] Furthermore, the above-mentioned interception of the original user list by an interface, and the filtering of the original user list according to the permission rules, and the return of the filtered visible user list, may specifically include the following steps:
[0072] S21: By intercepting the original user list through an interface and parsing the call request, the identity information of the current user is determined;
[0073] S22: Determine if the target user list exists in the current user's cache; the target user list is determined based on the current user's identity information and permission rules;
[0074] S23: If it exists, filter the original user list based on the target user list and return the filtered list of visible users;
[0075] S24: If not, determine the target user list based on the current user identity information and permission rules, filter the original user list based on the target user list, return the filtered visible user list, and write the target user list to the cache.
[0076] It should be noted that the specific operations for filtering the original user list according to the permission rules include: determining the target user list based on the current user's identity information and the permission rules, and filtering the original user list based on the target user list. In other words, in this embodiment, the interface parses the call request, determines the current user's identity information, and determines the target user list based on the identity information and pre-configured permission rules. This target user list can be understood as a global permission list, independent of the specific interface's business logic, and only represents the theoretically all user range that the current user can view.
[0077] This embodiment first checks if the target user list exists in the current user's cache. If it exists, the target user list can be directly used to filter the original user list. If it does not exist, the target user list needs to be generated based on the current user's identity information and permission rules. This target user list is then used to further filter the original user list, and the target user list needs to be stored in the current user's cache. For example, on the first query, the system needs to calculate the target user list based on the enterprise configuration (which may involve time-consuming operations such as multi-table joins and rule parsing), and cache the results for 5 minutes. Subsequent requests within the same 5 minutes can directly retrieve the target user list from the cache without repeated calculations, reducing database pressure and interface response time, and improving user experience.
[0078] This embodiment takes into account that the calculation of the target user list (based on the enterprise's configured permission rules and the current user's identity information) involves complex logic (such as cross-department permissions, role inheritance, etc.), and frequent calculations would consume a lot of CPU and database resources. Therefore, after each calculation, the data is stored in the current user's cache. In this way, when filtering permissions, the data can be retrieved from the cache, thereby improving efficiency and reducing calculation time and resource consumption.
[0079] Furthermore, after writing the target user list to the cache as described above, the following steps may also be included: S25: when a change is detected in the current user identity information and / or permission rules, the target user list in the cache is cleared; and / or, S26: a cache duration is set, and when the cache duration is reached, the target user list in the cache is cleared.
[0080] This embodiment further considers that the current user identity information and / or permission rules may change dynamically (e.g., a user is reassigned, permission rules are modified). If the cache is not updated in time, it will lead to the return of expired data, which violates the original intention of permission control. Therefore, when this embodiment detects a change in the current user identity information and / or permission rules, it clears the target user list in the cache to avoid permission errors caused by cache expiration (e.g., a user has been demoted but can still see sensitive data). Furthermore, this embodiment allows setting the cache duration. This embodiment does not limit the specific cache duration; the specific setting can be determined based on the data request frequency.
[0081] The permission filtering method provided in this embodiment of the invention preloads permission rules and binds the user list retrieval interface to an aspect. When a call request to the user list retrieval interface is received, the business logic of the user list retrieval interface is executed to obtain the original user list. The aspect intercepts the original user list and filters it according to the permission rules, returning the filtered visible user list. This method does not require modification of the interface's business code, achieving separation of permission filtering and business logic. In other words, it achieves data permission control without intruding on business code, while solving problems such as scattered business code and difficulty in modification, ensuring code maintainability and scalability, and ultimately meeting the diverse data permission needs of customers in different business sectors. Furthermore, without changing the original business logic (i.e., without modifying the original interface call methods one by one), it only requires writing a permission filtering method based on its own configured permission rules and binding this method to the corresponding target interface to filter user permissions on the target interface's return value. This can easily and efficiently meet the permission needs of customers in different business sectors and application scenarios. If a new user joins the original organizational structure, or a new user temporarily joins the original organizational structure, or an existing user leaves the original organizational structure, or if a user's viewing permissions are modified based on their department, role, or position and any changes thereto, the system can automatically retrieve the target user list from the cache for the same request, eliminating the need for repeated calculations, reducing database load and API response time, and improving user experience.
[0082] See Figure 2 As shown, this embodiment of the invention discloses a specific permission filtering method. Compared with the previous embodiment, this embodiment further explains and optimizes the technical solution.
[0083] S201: Preload permission rules and bind the user list retrieval interface to the aspect.
[0084] It should be noted that the specific steps of step S201 can be referred to step S101 of the above embodiment, and will not be repeated here.
[0085] S202: When a request to retrieve the user list interface is received, the business logic of the user list retrieval interface is executed to obtain the original user list.
[0086] It should be noted that the specific steps of step S202 can be referred to step S102 of the above embodiment, and will not be repeated here.
[0087] S203: Intercept the original user list by aspect and parse the call request to obtain the parameter value of the super administrator parameter; if the parameter value is true, proceed to step 204; if the parameter value is false, proceed to step S205.
[0088] It is understood that this embodiment pre-configures the super administrator parameter (superOperation parameter) for the user list retrieval interface. When the aspect parses the call request, it obtains the super administrator parameter value. If the parameter value is true, step 204 is executed; if the parameter value is false, step S205 is executed. This parameter value can indicate whether the current user is an enterprise super administrator. Of course, the aspect can also parse the call request to obtain the current user's identity information, and determine whether the current user is an enterprise super administrator based on the current user's identity information.
[0089] S204: Return the original user list directly.
[0090] Specifically, if the current user is a super administrator, the original user list will be returned. That is, all users will be returned.
[0091] S205: Filter the original user list according to the permission rules and return the filtered list of visible users.
[0092] Specifically, if the current user is not a super administrator, the user list is filtered according to the permission rules, and the filtered list of visible users is returned.
[0093] The permission rules in this embodiment include main rules and supplementary rules. Main rules are the foundational rules. Supplementary rules are further additions to the main rules, designed to increase or decrease the number of visible users. This embodiment does not limit the number of supplementary rules. Supplementary rules have a higher priority than main rules.
[0094] The following provides two specific examples of filtering the original user list according to permission rules and returning the filtered list of visible users. Of course, this embodiment is not limited to the following examples:
[0095] Example 1 can be used as a reference. Figure 3 , Figure 3 This is a flowchart illustrating a permission filtering method provided in an embodiment of the present invention. Specifically, it includes:
[0096] S31: Determine whether the current user is a designated person who can see all users based on the current user's identity information; if yes, proceed to step S32; otherwise, proceed to step S33.
[0097] S32: Returns the original user list;
[0098] S33: Determine whether there is a unified and publicly available department or user; if so, proceed to step S34; if not, proceed to step S35.
[0099] S34: Returns the personnel within the organizational structure, as well as the departments or users that are publicly disclosed in a unified manner;
[0100] S35: Return to personnel within the organizational structure.
[0101] As can be seen from steps S31-S35, this process is a gradual reduction of the visible scope. The call request is parsed to determine the current user's identity information. Based on this identity information, it is determined whether the current user is a designated member of the visible list. If so, the visible list is all personnel (i.e., the original user list). If not, it is further determined whether there are uniformly public departments / users. If so, the current user is visible to personnel within the organizational structure permissions plus uniformly public departments / users; otherwise, the user is visible to personnel within the organizational structure permissions.
[0102] It is understandable that the main rule corresponding to the above process is that members are visible to people within the organizational structure by default; the supplementary rules include two: Sub-rule 1.1 and Sub-rule 1.2. Sub-rule 1.1 (optional): "Specified members can see everyone". Departments / roles / personnel can be selected, such as the Human Resources Department and Training Department being able to see all employees in the company (i.e., without setting permissions for all stores, they can still see everyone); Sub-rule 1.2 (optional): "Public departments / members": Departments / personnel can be selected, meaning they can be seen by everyone in the company. For example, support or regulatory departments such as the Information Department and Security Department can be seen by all employees in the company.
[0103] Example 2 can be referenced. Figure 4 , Figure 4 A flowchart illustrating another permission filtering method provided in an embodiment of the present invention. Specifically, it includes:
[0104] S41: Determine whether the current user is a designated person within the visible organizational structure based on the current user's identity information; if yes, proceed to step S42; otherwise, proceed to step S43.
[0105] S42: Return to personnel within the organizational structure;
[0106] S43: Determine if there are any hidden departments or personnel; if they exist, proceed to step S44; if they do not exist, proceed to step S45.
[0107] S44: If it exists, return all people in the original user list except for the hidden departments or people;
[0108] S45: Return the original list of users.
[0109] As can be seen from steps S41-S45, this process is a gradual increase in the visibility scope. The call request is parsed to determine the current user's identity information, and it is determined whether the current user is a designated member who is only visible within the organizational structure. If so, the current user can only see people within the organizational structure. If not, it is further determined whether there are any departments / members hidden from the user. If so, the current user can see everyone in the original user list except for those hidden departments / members. If not, the current user can see everyone (i.e., the original user list).
[0110] Understandably, the main rule corresponding to the above process is that members are visible to everyone by default; Sub-rule 2.1 (optional): "Specify members to be visible only to those within their organizational structure permissions." This allows for mixed selection of departments / roles / personnel, such as franchise owners / employees only being visible to their own department members. Sub-rule 2.2 (optional): "Hidden departments / members": This allows for mixed selection of departments / personnel, visible only to super administrators. For example, senior executives such as the general manager can be hidden in the address book and not viewed.
[0111] The permission filtering method provided in this embodiment of the invention proceeds as follows: S201: Preload permission rules and bind the user list retrieval interface to the aspect. S202: When a call request to the user list retrieval interface is received, execute the business logic of the user list retrieval interface to obtain the original user list. S203: Intercept the original user list through the aspect and parse the call request to obtain the parameter value of the super administrator parameter; if the parameter value is true, proceed to step 204; if the parameter value is false, proceed to step S205. S204: Directly return the original user list. S205: Filter the original user list according to the permission rules and return the filtered visible user list. This method does not require modification of the interface's business code, achieving separation of permission filtering and business logic. In other words, it achieves data permission control without intruding on business code, while solving problems such as scattered business code and difficulty in modification, ensuring code maintainability and extensibility, and ultimately meeting the diverse data permission needs of customers in different business formats. Furthermore, this method can achieve fine-grained data permission control without intruding on business code, while maintaining code maintainability and extensibility.
[0112] The permission filtering device provided in the embodiments of the present invention will be described below. The permission filtering device described below can be referred to in correspondence with the permission filtering method described above.
[0113] Please refer to the details. Figure 5 , Figure 5 A schematic diagram of a permission filtering device provided in an embodiment of the present invention may include:
[0114] Configuration module 100 is used to preload permission rules and bind the user list retrieval interface to the aspect;
[0115] The execution module 200 is used to execute the business logic of the user list retrieval interface to obtain the original user list when it receives a call request for the user list retrieval interface;
[0116] The filtering module 300 is used to intercept the original user list through the interface, filter the original user list according to the permission rules, and return the filtered visible user list.
[0117] Based on the above embodiments, the configuration module 100 may include:
[0118] The permission rule recording unit is used to load and parse the permission rules; the permission rules include global rules for data permissions for customers of different business types;
[0119] The interface configuration unit is used to add permission filtering annotations to the user list retrieval interface and configure the aspect for the user list retrieval interface.
[0120] Based on the above embodiments, the permission filtering module may further include:
[0121] The parameter configuration module is used to pre-configure the super administrator parameters for the user list retrieval interface;
[0122] Accordingly, the filter module 300 may include:
[0123] The first parsing unit is used to intercept the original user list through the aspect and to parse the call request to obtain the parameter value of the super administrator parameter;
[0124] The first return unit is used to directly return the original user list when the parameter value is true;
[0125] The second return unit is used to filter the original user list according to the permission rules when the parameter value is false, and return the filtered visible user list.
[0126] Based on the above embodiments, the filtering module 300 may include:
[0127] The second parsing unit is used to intercept the original user list through the face and to parse the call request to determine the current user's identity information;
[0128] The first judgment unit is used to determine whether the target user list exists in the current user's cache; the target user list is determined based on the current user's identity information and the permission rules;
[0129] The third result unit is used to filter the original user list according to the target user list if it exists, and return the filtered visible user list.
[0130] The fourth result unit is used to determine the target user list based on the current user identity information and the permission rules if the target user list does not exist, filter the original user list based on the target user list, return the filtered visible user list, and write the target user list to the cache.
[0131] Based on the above embodiments, the permission filtering device may further include:
[0132] The first clearing module is used to clear the target user list in the cache when it is detected that the current user identity information and / or the permission rules have changed;
[0133] And / or, a second clearing module is used to set a cache duration, and when the cache duration is reached, clear the target user list in the cache.
[0134] Based on any of the above embodiments, the permission filtering module 300 may include:
[0135] The third parsing unit is used to intercept the original user list through the face and to parse the call request to determine the current user's identity information;
[0136] The second judgment unit is used to determine whether the current user is a designated person who can see all users based on the current user identity information;
[0137] The third return unit is used to return the original user list if the condition is met.
[0138] The third judgment unit is used to determine whether there is a uniformly disclosed department or user if no;
[0139] The fourth return unit is used to return personnel within the organizational structure, as well as the uniformly disclosed departments or users, if they exist.
[0140] The fifth return unit is used to return the personnel within the organizational structure if they do not exist.
[0141] Based on any of the above embodiments, the permission filtering module 300 may include:
[0142] The fourth parsing unit is used to intercept the original user list through the face and to parse the call request to determine the current user's identity information;
[0143] The fourth judgment unit is used to determine whether the current user is a designated person within the visible organizational structure based on the current user's identity information.
[0144] The sixth return unit is used to return personnel within the organizational structure if the condition is met.
[0145] The fifth judgment unit is used to determine whether there is a hidden department or personnel if no;
[0146] The seventh return unit is used to return all personnel in the original user list except for the hidden departments or personnel, if they exist.
[0147] The eighth return unit is used to return the original user list if it does not exist.
[0148] It should be noted that the order of the modules and units in the above-mentioned permission filtering device can be changed without affecting the logic.
[0149] The permission filtering device provided in this embodiment of the invention uses a configuration module 100 to preload permission rules and bind the user list retrieval interface to an aspect; an execution module 200, when receiving a call request for the user list retrieval interface, executes the business logic of the user list retrieval interface to obtain the original user list; and a filtering module 300, through the aspect, intercepts the original user list and filters it according to the permission rules, returning the filtered visible user list. The entire device does not require modification of the interface's business code, achieving separation of permission filtering and business logic. In other words, it achieves data permission control without intruding on business code, while solving problems such as scattered business code and difficulty in modification, ensuring code maintainability and scalability, and ultimately meeting the diverse data permission needs of customers in different business sectors.
[0150] The permission filtering device provided in the embodiments of the present invention will be described below. The permission filtering device described below and the permission filtering method described above can be referred to each other.
[0151] Please refer to Figure 6 , Figure 6 A schematic diagram of a permission filtering device provided in an embodiment of the present invention may include:
[0152] Memory 10 is used to store computer programs;
[0153] Processor 20 is used to execute computer programs to implement the above-described permission filtering method.
[0154] The memory 10, processor 20, and communication interface 31 all communicate with each other through the communication bus 32.
[0155] In this embodiment of the invention, the memory 10 is used to store one or more programs. The programs may include program code, which includes computer operation instructions. In this embodiment of the invention, the memory 10 may store programs for implementing the following functions:
[0156] Preload the permission rules and bind the user list retrieval interface to the aspect;
[0157] When a request to retrieve the user list is received, the business logic of the user list retrieval interface is executed to obtain the original user list.
[0158] The original user list is intercepted by an interface, and filtered according to permission rules, and the filtered list of visible users is returned.
[0159] In one possible implementation, the memory 10 may include a program storage area and a data storage area, wherein the program storage area may store the operating system and applications required for at least one function; and the data storage area may store data created during use.
[0160] Furthermore, memory 10 may include read-only memory and random access memory, providing instructions and data to the processor. A portion of the memory may also include NVRAM. The memory stores operating systems and operating instructions, executable modules, or data structures, or subsets thereof, or extended sets thereof, wherein the operating instructions may include various operating instructions for implementing various operations. The operating system may include various system programs for implementing various basic tasks and handling hardware-based tasks.
[0161] Processor 20 can be a central processing unit (CPU), an application-specific integrated circuit, a digital signal processor, a field-programmable gate array, or other programmable logic device. Processor 20 can be a microprocessor or any conventional processor. Processor 20 can call programs stored in memory 10.
[0162] Communication interface 31 can be an interface for the communication module, used to connect with other devices or systems.
[0163] Of course, it should be noted that, Figure 6The structure shown does not constitute a limitation on the permission filtering device in the embodiments of the present invention. In practical applications, the permission filtering device may include more than Figure 6 More or fewer components as shown, or combinations of certain components.
[0164] The following describes the computer-readable storage medium provided in the embodiments of the present invention. The computer-readable storage medium described below and the permission filtering method described above can be referred to in correspondence.
[0165] The present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the above-described permission filtering method.
[0166] The computer-readable storage medium may include various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0167] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.
[0168] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.
[0169] Finally, it should be noted that in this document, relationships such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations 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 process, method, article, or apparatus.
[0170] The above provides a detailed description of the permission filtering method, apparatus, device, and computer-readable storage medium provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.
Claims
1. A permission filtering method, characterized in that, include: Preload the permission rules and bind the user list retrieval interface to the aspect; When a request to retrieve the user list is received, the business logic of the user list retrieval interface is executed to obtain the original user list. The original user list is intercepted by the aforementioned interface, and filtered according to the permission rules, and the filtered list of visible users is returned.
2. The permission filtering method according to claim 1, characterized in that, Preload permission rules and bind the user list retrieval interface to the aspect, including: Load and parse the permission rules; the permission rules include global rules for data permissions for customers in different business formats; Add permission filtering annotations to the user list retrieval interface and configure the aspect for the user list retrieval interface.
3. The permission filtering method according to claim 1, characterized in that, The original user list is intercepted through the aforementioned aspect, and filtered according to the aforementioned permission rules. The filtered list of visible users is then returned, including: By intercepting the original user list through the aforementioned face and parsing the call request, the current user's identity information can be determined; Determine whether the target user list exists in the current user's cache; the target user list is determined based on the current user's identity information and the permission rules; If they exist, the original user list is filtered according to the target user list, and the filtered visible user list is returned. If the target user list does not exist, the target user list is determined based on the current user identity information and the permission rules. The original user list is then filtered based on the target user list, and the filtered visible user list is returned. Simultaneously, the target user list is written to the cache.
4. The permission filtering method according to claim 3, characterized in that, After writing the target user list to the cache, the process also includes: When a change is detected in the current user identity information and / or the permission rules, the target user list in the cache is cleared; And / or, set a cache duration, and when the cache duration is reached, clear the target user list from the cache.
5. The permission filtering method according to claim 1, characterized in that, Before intercepting the original user list through the aforementioned aspect, filtering the original user list according to the aforementioned permission rules, and returning the filtered list of visible users, the process further includes: Configure the super administrator parameters in advance for the user list retrieval interface; Accordingly, the interception of the original user list through the aforementioned aspect, the filtering of the original user list according to the permission rules, and the return of the filtered visible user list include: By intercepting the original user list through the aforementioned aspect and parsing the call request, the parameter value of the super administrator parameter is obtained; When the parameter value is true, the original user list is returned directly; When the parameter value is false, the original user list is filtered according to the permission rules, and the filtered visible user list is returned.
6. The permission filtering method according to any one of claims 1 to 4, characterized in that, The original user list is intercepted through the aforementioned aspect, and filtered according to the aforementioned permission rules. The filtered list of visible users is then returned, including: By intercepting the original user list through the aforementioned face and parsing the call request, the current user's identity information can be determined; Based on the current user's identity information, determine whether the current user is a designated person who can see all users; If so, return the original user list; If not, then determine whether there is a uniformly public department or user; If they exist, return the personnel within the organizational structure, as well as the departments or users that are publicly available. If not found, return the personnel within the organizational structure.
7. The permission filtering method according to any one of claims 1 to 4, characterized in that, The original user list is intercepted through the aforementioned aspect, and filtered according to the aforementioned permission rules. The filtered list of visible users is then returned, including: By intercepting the original user list through the aforementioned face and parsing the call request, the current user's identity information can be determined; Based on the current user's identity information, determine whether the current user is a designated person within a visible organizational structure; If so, return to the personnel within the organizational structure; If not, determine whether there are hidden departments or personnel; If they exist, return all personnel from the original user list except for the hidden department or personnel. If it does not exist, return the original user list.
8. A permission filtering device, characterized in that, include: The configuration module is used to preload permission rules and bind the user list retrieval interface to the aspect; The execution module is used to execute the business logic of the user list retrieval interface to obtain the original user list when a call request for the user list retrieval interface is received. The filtering module is used to intercept the original user list through the interface, filter the original user list according to the permission rules, and return the filtered visible user list.
9. A permission filtering device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the permission filtering method as described in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when loaded and executed by a processor, implement the permission filtering method as described in any one of claims 1 to 7.