Dynamic data access control method, device and storage medium based on multiple user groups

Abstract

The present application provides a method, device and storage medium for dynamic data access control based on multiple user groups. The method includes: matching the user access domain name with the user group identifier corresponding to the user, and when the match is successful, storing the user group identifier in the browser cache; judging whether the user is logged in based on the identity token, checking whether the user's identity token is valid, and verifying the legitimacy of the page access request; extracting user information from the identity token, and querying user authority information based on the user information, and returning the user authority information to the front end; dynamically configuring the user's data access route based on the user authority information, and after the dynamic registration of user authority is completed, redirecting the front-end application page to the user's start page, so that the user can perform operations that meet the authority requirements based on the start page. The present application reduces the development workload, reduces the complexity and maintenance cost of the system, meets the customization requirements of the user group, and facilitates user authority management.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method, device and storage medium for dynamic data access control based on multiple user groups. Background Art

[0002] With the rapid development of information technology, enterprises have gradually increased their demand for information security and data protection. Modern enterprises usually establish multiple business systems such as permission management systems and approval management systems to meet increasingly complex business needs. These systems need to provide services for different user groups, and at the same time, they must ensure data and configuration isolation between different user groups to protect the data security and privacy of each user group. In addition, these business systems often need to have certain customization capabilities to support different page theme styles and permission settings to meet the specific needs of each user group.

[0003] In the existing technical solutions, the following methods are usually used to achieve service support for multiple user groups: 1. Completely independent system development and deployment: This method involves copying the developed system to other warehouses and redeveloping and deploying it for each user group. Although this approach can achieve data isolation and handle customized requirements of different user groups, it will lead to a significant increase in development workload, making it difficult to ensure business consistency and significantly increase the maintenance cost of the system. 2. Configuration of different routing addresses: By providing different routing addresses for different user groups, although this method attempts to achieve user group isolation through routing management, these different routing addresses may eventually point to the same page. This leads to complex and redundant configuration of routing tables, and makes it difficult to effectively solve the problem of permission management between different user groups. 3. Address bar parameters distinguish user groups: In this method, different user groups are distinguished by carrying user group identification parameters in the address bar. However, the address bar is easy to be tampered with, and it is difficult to ensure that the necessary parameters are correctly carried in each request, which makes permission management easy to be interfered with.

[0004] In summary, in the process of implementing multi-user group services, the existing technology has not yet effectively solved the problem of simplifying routing configuration and preventing address bar tampering while ensuring data and configuration isolation. In addition, the existing solution leads to an increase in development and maintenance workload, reducing the maintainability of the system. Summary of the invention

[0005] In view of this, the embodiments of the present application provide a dynamic data access control method, device and storage medium based on multiple user groups to solve the problems of large development workload, high system complexity and maintenance cost, and susceptibility to interference in permission management in the prior art.

[0006] According to a first aspect of an embodiment of the present application, a dynamic data access control method based on multiple user groups is provided, including: in response to a page access request initiated by a user, obtaining an access domain name of the current page, matching the access domain name with a user group identifier corresponding to the user, and storing the user group identifier in a browser cache when the match is successful; judging whether the user is logged in based on an identity token in the browser cache, and when it is judged that the user is not logged in, initiating a login request, and performing access permission verification based on the information input by the user; when it is judged that the user is logged in, initiating a user permission query request using the identity token to obtain user permission information; checking whether the user's identity token is valid, and performing a legitimacy verification on the user's page access request; when the user's identity token is valid and the legitimacy verification of the user's page access request is passed, extracting user information from the user's identity token, querying user permission information based on the user information, and returning the user permission information to a front end; dynamically configuring the user's data access route based on the user permission information, and after the dynamic registration of the user permission is completed, redirecting the front end application page to the user's start page, so that the user can perform operations that meet the permission requirements based on the start page.

[0007] The second aspect of the embodiment of the present application provides a dynamic data access control device based on multiple user groups, including: a matching module, configured to respond to a page access request initiated by a user, obtain the access domain name of the current page, match the access domain name with the user group identifier corresponding to the user, and when the match is successful, store the user group identifier in the browser cache; a judgment module, configured to judge whether the user is logged in based on the identity token in the browser cache, and when it is judged that the user is not logged in, initiate a login request and verify the access permission based on the information entered by the user; when it is judged that the user is logged in, use the identity token to initiate a user permission query request to obtain the user permission information; a verification module configured to check whether the user's identity token is valid and to verify the legitimacy of the user's page access request; a query module configured to extract user information from the user's identity token when the user's identity token is valid and the legitimacy of the user's page access request is verified, and to query the user's permission information based on the user information, and return the user permission information to the front end; a configuration module configured to dynamically configure the user's data access route based on the user's permission information, and after the dynamic registration of user permissions is completed, redirect the front-end application page to the user's start page, so that the user can perform operations that meet the permission requirements based on the start page.

[0008] According to a third aspect of an embodiment of the present application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the steps of the above method are implemented when the processor executes the program.

[0009] According to a fourth aspect of an embodiment of the present application, a computer-readable storage medium is provided, which stores a computer program, and when the computer program is executed by a processor, the steps of the above method are implemented.

[0010] At least one of the above technical solutions adopted in the embodiments of the present application can achieve the following beneficial effects:

[0011] By responding to the page access request initiated by the user, the access domain name of the current page is obtained, and the access domain name is matched with the user group identifier corresponding to the user. When the match is successful, the user group identifier is stored in the browser cache; according to the identity token in the browser cache, it is determined whether the user is logged in. When it is determined that the user is not logged in, a login request is initiated, and access rights are verified according to the information entered by the user; when it is determined that the user is logged in, a user permission query request is initiated using the identity token to obtain user permission information; check whether the user's identity token is valid, and verify the legitimacy of the user's page access request; when the user's identity token is valid and the legitimacy of the user's page access request is verified, the user information is extracted from the user's identity token, and the user permission information is queried based on the user information, and the user permission information is returned to the front end; according to the user permission information, the user's data access route is dynamically configured, and after the dynamic registration of the user permission is completed, the front-end application page is redirected to the user's start page, so that the user can perform operations that meet the permission requirements based on the start page. This application reduces the development workload, reduces the complexity and maintenance cost of the system, meets the customization needs of user groups, and facilitates user permission management. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0013] Figure 1 It is a flowchart of a dynamic data access control method based on multiple user groups provided in an embodiment of the present application;

[0014] Figure 2 This is a schematic diagram of a process in which multiple user groups share a front-end service provided by an embodiment of the present application;

[0015] Figure 3 It is a schematic diagram of the overall business process provided by the embodiment of the present application;

[0016] Figure 4 This is a schematic diagram of a user login verification process provided by an embodiment of the present application;

[0017] Figure 5 This is a schematic diagram of the user authority acquisition process provided by an embodiment of the present application;

[0018] Figure 6 is a structural diagram of a dynamic data access control device based on multiple user groups provided in an embodiment of the present application;

[0019] Figure 7 It is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0020] In the following description, specific details such as specific system structures, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to prevent unnecessary details from obstructing the description of the present application.

[0021] With the development of information technology, enterprises have an increasing demand for information security and data protection. Within an enterprise, multiple business systems are usually established to meet different business needs, such as permission management systems, approval management systems, etc. These business systems usually need to be provided to different user groups, and data and configuration isolation between different user groups must be maintained, and data security and privacy for all user groups must be ensured. At the same time, in order to meet the needs of different user groups, these business systems may need to have certain customization capabilities to support different page theme styles and page permission sets.

[0022] The core of this type of business scenario is that a software application instance needs to provide services to multiple different user groups. The existing technical solutions mainly include the following:

[0023] 1. Relying on the completed system, copying the code to other warehouses, completely re-developing and deploying independently, although it can solve the problem of data isolation and processing differences between different groups of households, the development workload will increase, and business consistency is difficult to ensure, which will increase additional maintenance costs.

[0024] 2. Providing different routing addresses to different user groups, and different routes will point to the same page, will lead to redundant routing table configuration, and the permission issues between different user groups will be difficult to handle.

[0025] 3. User groups are distinguished by carrying user group identification parameters in the address bar, but the address bar is easy to be tampered with, the parameters are difficult to ensure that they are always carried, and the permission issues between different user groups are difficult to handle.

[0026] Therefore, while ensuring data and configuration isolation, simplifying the routing table configuration, preventing address bar tampering, reducing development workload, and increasing system maintainability are important issues facing current technology.

[0027] In view of the problems existing in the above-mentioned prior art, the embodiment of the present application provides a dynamic data access control method based on multiple user groups, which aims to solve the data isolation and security access problems of multiple user group services in enterprises, and ensures the data security and access isolation of different user groups through a series of technical implementation steps. This application binds the domain names of different user groups accessing services to the deployed services through Nginx ingress technology, ensuring that different user groups access services through their own domain names, isolating from the entry level, and preventing the possibility of address bar parameters and routes being tampered with by other means. By configuring different user group identifiers tentantId and access domain name mapping relationships on the front end, the Referer parameter will be automatically carried when the browser is used to initiate a request, and the token information also includes tentantId, which is then compared with the different user group identifiers tentantId and access domain name mapping relationships configured on the server to prevent the possibility of users having unauthorized access. The server isolates the user group data through different user group identifiers tentantId, thereby realizing a method for multiple user groups to share front-end instances.

[0028] The contents of the technical solution of the present application are described in detail below with reference to the accompanying drawings and specific embodiments.

[0029] Figure 1 It is a flowchart of a dynamic data access control method based on multiple user groups provided in an embodiment of the present application. Figure 1 The dynamic data access control method based on multiple user groups can be executed by a data access control system. Figure 1 As shown, the dynamic data access control method based on multiple user groups may specifically include:

[0030] S101, in response to a page access request initiated by a user, obtaining an access domain name of the current page, matching the access domain name with a user group identifier corresponding to the user, and storing the user group identifier in a browser cache when the match succeeds;

[0031] S102, judging whether the user is logged in based on the identity token in the browser cache, and when judging that the user is not logged in, initiating a login request, and performing access rights verification based on the information input by the user; when judging that the user is logged in, initiating a user rights query request using the identity token to obtain user rights information;

[0032] S103, checking whether the user's identity token is valid, and verifying the legitimacy of the user's page access request;

[0033] S104, when the user's identity token is valid and the legitimacy verification of the user's page access request is passed, the user information is extracted from the user's identity token, and the user authority information is queried based on the user information, and the user authority information is returned to the front end;

[0034] S105, dynamically configure the user's data access route according to the user authority information, and after the dynamic registration of the user authority is completed, redirect the front-end application page to the user's start page, so that the user can perform operations that meet the authority requirements based on the start page.

[0035] In some embodiments, before obtaining the access domain name of the current page in response to the page access request initiated by the user, the method further includes:

[0036] In the system configuration file, a corresponding access domain name is set for each user group, and an access domain name mapping relationship is established between the user group and the access domain name. The access domain names corresponding to different user groups are bound to the deployed services so that the controller can route different domain name requests to the corresponding services according to the access domain name mapping relationship, where each service is encapsulated in one or more containers.

[0037] Specifically, in order to respond to the page access request initiated by the user and obtain the access domain name of the current page, the system first needs to set a corresponding access domain name for each user group and establish a mapping relationship between the user group and the access domain name. The following is a detailed description of the process of multiple user groups sharing front-end services in conjunction with the accompanying drawings and specific embodiments. Figure 2 Schematic diagram of the process of multiple user groups sharing front-end services provided by the embodiment of the present application, such as Figure 2 As shown, the embodiment of the present application establishes an access domain name mapping relationship between user groups and access domain names, and binds access domain names corresponding to different user groups to deployed services, which may include the following contents:

[0038] First, set the access domain name in the system configuration file, that is, in the system configuration file, set the corresponding access domain name for each user group in advance. The following is an example configuration:

[0039] {

[0040] "tenant1":"tenant1.company.com",

[0041] "tenant2":"tenant2.company.com"

[0042] }

[0043] This configuration ensures that each user group has a unique access domain name, through which different user groups can be identified and distinguished.

[0044] Furthermore, a mapping relationship between user groups and access domain names is established so that the system can accurately identify user groups based on the domain names accessed. This mapping relationship is globally configured in the system to ensure that all services can be accessed.

[0045] Furthermore, Kubernetes is used for container orchestration, and each service is encapsulated in one or more containers for deployment. The use of Kubernetes simplifies the deployment and management of services and improves the scalability and reliability of the system. Each service only needs to be deployed once to provide services to multiple user groups. Through containerization technology, high availability and isolation of services can be ensured.

[0046] Furthermore, Nginx is used as an Ingress controller to bind the access domain names of different user groups to the deployed services. The Nginx Ingress controller is responsible for routing external requests to the correct service container. For example, when accessing tenant1.company.com, Nginx routes the request to the service container corresponding to tenant1; when accessing tenant2.company.com, it routes the request to the service container corresponding to tenant2.

[0047] Through the above configuration, the user groups are isolated at the access level, preventing the risk of address bar parameters and routes being tampered with. Different user groups access services through their own domain names, ensuring that each user group can only access authorized data and services, thereby ensuring data security and privacy.

[0048] For example, in a specific example, the mapping relationship between different user groups and access domain names is configured in the project, and Kubernetes container orchestration is used for service deployment. Each service only needs to be deployed once. The domain names of different user groups accessing services are bound to the deployed services through Nginx ingress technology, ensuring that different user groups access services through their own domain names. This completes the isolation of user group access entry level and prevents address bar parameters and routes from being tampered with.

[0049] A. The mapping relationship between user groups and access domain names is configured as follows:

[0050] {

[0051] "tenant1":"tenant1.company.com", / / User group 1 access domain name

[0052] "tenant2":"tenant2.company.com" / / User group 2 access domain name

[0053] }

[0054] B. Multiple user groups share front-end services, such as Figure 1 As shown in the figure, the tenant1 and tenant2 user groups access the service through tenant1.company.com and tenant2.company.com respectively. The Nginx Ingress controller routes the request to the corresponding service container based on the access domain name. These containers run in the Kubernetes cluster and provide isolated service access for their respective user groups.

[0055] Furthermore, in order to ensure that the server can correctly process requests initiated by different user groups through their respective domain names and perform necessary access rights verification, the server of this embodiment also needs to configure the mapping relationship between user groups and access domain names, and also needs to configure on the server to verify whether the access rights are correct.

[0056] For example, the server needs to configure the same user group and domain name mapping as the front-end. Therefore, the server can identify which user group the requests initiated from domain names such as tenant1.company.com and tenant2.company.com belong to. This mapping relationship enables the server to immediately identify which user group the request is initiated from by checking the source domain name of the request when it receives the request. This is the basis for implementing data processing and access control based on user groups.

[0057] Furthermore, the server not only needs to identify the user group of the request, but also needs to verify whether the request has the corresponding access rights. This can be achieved through various mechanisms, such as role-based access control (RBAC), token verification (such as JWT), or other security policies. When a request arrives at the server, the user group is first determined based on the domain name. The server then checks whether the request carries valid authentication information (such as a JWT token) and verifies whether this information authorizes the user to access the requested resource.

[0058] In some embodiments, in response to a page access request initiated by a user, obtaining an access domain name of the current page, and matching the access domain name with a user group identifier corresponding to the user include:

[0059] Obtain the user's page access request, use the predetermined object to obtain the access domain name of the current page, and compare the obtained access domain name with the pre-configured access domain name mapping relationship; when the access domain name matches the access domain name configured by any user group, determine that the page access request comes from the user group, and obtain the user group identifier corresponding to the user group to which the user belongs.

[0060] Specifically, in order to respond to a page access request initiated by a user, the system needs to obtain the access domain name of the current page and match the access domain name with the user group ID corresponding to the user. When a user enters a URL in a browser and initiates a page access request, the system will first capture the request. This request may be initiated by the user directly entering a URL or clicking a link.

[0061] Furthermore, when the user requests a page to load, the system uses the window.location object provided by the browser to obtain the domain name of the current page. The window.location object contains the complete URL information of the current document, and the host attribute provides the domain name part.

[0062] Furthermore, after the system obtains the access domain name of the current page, it compares it with the pre-configured mapping relationship between user groups and access domain names. These mapping relationships are usually stored in the system configuration file, which predefines the access domain name corresponding to each user group. For example, tenant1 corresponds to tenant1.company.com, and tenant2 corresponds to tenant2.company.com.

[0063] During the comparison process, if the access domain name obtained matches an item in the configuration file, the system can confirm that the access request comes from the corresponding user group. For example, if the domain name currently accessed is tenant1.company.com, the system will determine that the request comes from user group tenant1.

[0064] Furthermore, the system extracts the identifier (tenantId) of the user group based on the matching results. This tenantId is pre-configured and is used to uniquely identify different user groups. The system stores the extracted tenantId in the browser's cache, such as using cookies, so that the identifier can be used for user authentication and permission management in subsequent processes.

[0065] For example, in a specific example, a user enters a specific domain name (such as tenant1.company.com) in a browser and initiates a request. The system captures the request and starts processing.

[0066] First, get the domain name: At the initial stage of loading the page requested by the user, the system uses the window.location object to get the domain name currently being visited. window.location.host returns the domain name portion of the current page.

[0067] Next, compare the access domain name with the pre-configured mapping relationship: the system compares the access domain name obtained with the pre-configured user group and domain name mapping relationship. For example, the mapping relationship can be:

[0068] tenant1:tenant1.company.com

[0069] tenant2:tenant2.company.com

[0070] The system checks each item in the mapping relationship one by one to find the user group identifier (tenantId) that matches the currently accessed domain name.

[0071] Then, confirm the user group and store the tenantId: When the system confirms that the current access domain name matches the configuration of a user group, extract the corresponding user group identifier (tenantId). For example, when the access domain name is tenant1.company.com, the tenantId is tenant1.

[0072] Finally, the system stores this tenantId in the browser's cookie to ensure that this identifier can be used for verification and management in subsequent requests.

[0073] Through the method of the present embodiment described above, the system can effectively identify the user group at the page access request stage, and perform subsequent identity authentication and permission management based on the user group identifier. This method ensures the isolation of user groups and data security, and effectively prevents unauthorized access.

[0074] In some embodiments, when it is determined that the user is not logged in, a login request is initiated, and access rights verification is performed based on the information entered by the user, including:

[0075] When the user's identity token does not exist in the browser cache, it is determined that the user is not logged in, and the user is redirected to the login page. The user name and password entered by the user are obtained, and a login request is constructed based on the user name, password, user group ID, and request header parameters.

[0076] The login request is sent to the server, so that the server can determine whether the access domain name in the request header parameter is consistent with the access domain name of the login request based on the pre-configured access domain name mapping relationship. If they are consistent, the access permission verification is passed. If they are inconsistent, an error message is returned to the front end, and the server logs in again.

[0077] Specifically, by obtaining whether the browser cache cookie contains token information, it is determined whether the current user is logged in. If the user identity information token does not exist, it means that the current user is not logged in, and it automatically jumps to the login page to guide the user to log in. The overall business process and user login verification process of the embodiment of the present application are described in detail below in conjunction with the accompanying drawings and specific embodiments. Figure 3 is a schematic diagram of the overall business process provided by the embodiment of the present application, Figure 4 Schematic diagram of the user login verification process provided by the embodiment of the present application, such as Figure 3 to Figure 4 As shown, the user login verification process of the embodiment of the present application may include the following contents:

[0078] The system determines whether the user is logged in by checking whether the cookie in the browser cache contains the user's identity token. If the token is not found, the system determines that the user is not logged in. When it is determined that the user is not logged in, the system will initiate a login request and verify access rights based on the information entered by the user.

[0079] Furthermore, when the system determines that the user is not logged in, the system automatically redirects the user to the login page. The user enters his / her username and password in the login page for identity authentication. After the user enters his / her username and password in the login page, he / she clicks the login button to submit the login information.

[0080] Furthermore, the front-end page uses the axios request library to construct a login request, which includes parameters such as username, password, and user group ID (tenantId). The request header parameter Referer is also added by default to the request, indicating the access domain name of the current user group. The login request is sent to the server for further verification.

[0081] Furthermore, after receiving the login request, the server extracts the tenantId, user name and password in the request. The server verifies whether the Referer parameter in the request header is consistent with the tenantId in the login request based on the access domain name mapping relationship pre-configured by the system.

[0082] Furthermore, if the access domain name in the Referer parameter is consistent with the tenantId in the login request, the server considers that the access permission verification is passed. If not, the server returns an error message to the front end, which prompts the user to log in again and restarts the process of matching the access domain name with the user group identifier corresponding to the user in the above embodiment.

[0083] Furthermore, the server further verifies whether the username and password are correct. If the username and password are correct, the server generates a JWT (JSON Web Token) token containing the user information and tenantId. The server returns the generated JWT token to the front end. After the front end receives the JWT token, it stores it in the browser's cookie so that it can be used for authentication in subsequent requests. After successful login, the system continues to execute subsequent business processes.

[0084] For example, in a specific example, the process of user login verification may include the following steps:

[0085] Step A. Enter the login page, enter the user name and password, and click the login button to log in.

[0086] Step B. The front-end page initiates a request to the back-end service through the axios request library, and passes in the username, password, and tenantId parameters. The request will add the request header parameter Referer by default, which is the domain name accessed by the current user group.

[0087] Step C. The server processes the request and receives the tenantId, username, and password.

[0088] Step D. Obtain the tenantId corresponding to the Referer parameter through the pre-configured mapping relationship, and compare it with the received tenantId parameter. If they are exactly the same, it means that the access rights are correct and the subsequent process continues to execute; otherwise, it means that the access rights are incorrect, and an error message is returned to the front-end page. After the front-end determines the error message, it forces the page to be refreshed and restarts the process of matching the access domain name with the user group identifier corresponding to the user in the aforementioned embodiment.

[0089] Step E. The server determines whether the user name and password are correct. If they are correct, the server generates a token using jwt (JSON Web Token) with the user information, which must include tenantId, and returns it to the front end. After the front end obtains the token information, it stores the token information in the browser cache cookie and continues the process from step 5. Otherwise, the login fails and an error message is returned to the front end page, requiring the user to re-enter the account and password information.

[0090] Through the method of the above embodiment, the system can ensure that each user login request undergoes strict identity authentication and permission verification, thereby enhancing the security of the service and the protection of user data. This method not only ensures the isolation of user groups and data security, but also improves the user experience, ensuring that users can log in smoothly and safely and access their authorized resources.

[0091] In some embodiments, when it is determined that the user has logged in, a user authority query request is initiated using the identity token to obtain user authority information, including:

[0092] When the user's identity token exists in the browser cache, it is determined that the user has logged in, and a user permission query request is generated using the identity token, and the user permission query request is sent to the server;

[0093] The server is used to verify the validity of the identity token. Once the validity verification is passed, the user permission information is queried based on the user ID in the identity token, and the queried user permission information is returned to the front end so that the front end can adjust the interface display based on the user permission information.

[0094] Specifically, when it is determined that the user has logged in, the system uses the identity token to initiate a user permission query request to obtain the user's permission information. The system checks whether the cookie in the browser cache contains the user's identity token. If the token exists, it is determined that the user has logged in.

[0095] Furthermore, when the system confirms that the user has logged in, it generates a user permission query request using the identity token stored in the browser cache. This request contains the user's token, which is used for back-end verification and permission query. The front-end system sends the user permission query request to the server. The request carries the user's identity token as the basis for identity verification and permission query.

[0096] Furthermore, after receiving the permission query request, the server first verifies the validity of the identity token. The verification content includes checking whether the token has not been tampered with and whether it is within the validity period. If the verification passes, the permission query continues; if the verification fails, an error message is returned and the process is terminated.

[0097] Furthermore, the server queries the corresponding user permission information based on the user ID (such as tenantId) in the verified identity token. User permission information is usually stored in a database or permission management system. The server returns the queried user permission information to the front-end system. The permission information includes the resources, function modules, operation permissions, etc. that the user can access.

[0098] Furthermore, after receiving the user authority information, the front-end system dynamically adjusts the user interface according to the information, for example, showing or hiding specific function buttons, adjusting the navigation menu, etc., to ensure that the user can only see and operate the authorized parts.

[0099] Through the method of the above embodiment, the system can ensure that each user access request undergoes strict identity authentication and permission verification, thereby enhancing the security of the service and the protection of user data. This method not only ensures the isolation of user groups and data security, but also improves the user experience, ensuring that users can log in smoothly and safely and access their authorized resources.

[0100] In some embodiments, checking whether the user's identity token is valid and verifying the legitimacy of the user's page access request includes:

[0101] Check the structure and signature of the identity token, and verify the timestamp of the identity token to determine whether the identity token is valid; if the identity token is valid, initiate a page access request to the server, so that the server can extract the user group ID, identity token, and request header parameters from the page access request;

[0102] According to the pre-configured access domain name mapping relationship, the access domain name in the request header parameter is converted into the corresponding user group ID, and the user group ID is extracted from the identity token. The user group ID in the page access request, the user group ID corresponding to the request header parameter and the user group ID in the identity token are compared. When the user group IDs are consistent, the page access request is verified to be a legal request. When any user group ID is inconsistent, the page access request is verified to be an illegal request.

[0103] Specifically, the system needs to check whether the user's identity token is valid and verify the legitimacy of the user's page access request. The following is a detailed description of the user permission acquisition process after login in conjunction with the accompanying drawings and specific embodiments. Figure 5 is a schematic diagram of a user rights acquisition process provided by an embodiment of the present application, such as Figure 5 As shown, the process of obtaining user rights after logging in in the embodiment of the present application may include the following contents:

[0104] The system first checks the structure and signature of the identity token to confirm whether the token information is correct and has not been tampered with. Check the timestamp of the identity token to ensure that the token is within the validity period. If the token has expired or the signature is incorrect, the system determines that the token is invalid and returns an error message to the front-end page. After the front-end determines the error message, it redirects the user to the login page.

[0105] Furthermore, when the system confirms that the identity token is valid, the front-end initiates a page access request to the server through the axios request library. The request contains the user's token and tenantId parameters, and adds the request header parameter Referer by default to indicate the domain name accessed by the current user group.

[0106] Furthermore, after receiving the page access request, the server extracts the tenantId, token, and Referer parameters in the request. The server parses the token and obtains the tenantId and user information contained in the token. During the parsing process, the server uses a preset key or algorithm to decrypt and verify the token.

[0107] Furthermore, the server converts the access domain name in the Referer parameter into a corresponding tenantId according to a pre-configured access domain name mapping relationship.

[0108] Furthermore, the tenantId in the page access request, the tenantId corresponding to the Referer parameter, and the tenantId parsed from the token are compared. If the three tenantIds are consistent, the server determines that the page access request is a legitimate request and continues to execute the subsequent process; otherwise, an error message is returned to the front-end page, and the front-end forces a page refresh after determining the error message, and re-executes the process from step 3.

[0109] For example, in a specific example, the process of the system checking whether the user's identity token is valid and verifying the legitimacy of the user's page access request may include the following:

[0110] First, check the correctness of the token information: The system first checks the structure and signature of the token to ensure that the token has not been tampered with. Use the preset key to decrypt the token and verify the signature. Check the timestamp of the token to confirm that the token is within the validity period. If the token has expired or the signature verification fails, the system determines that the token is invalid.

[0111] Next, initiate a page access request: the front-end system sends a request to the server through the axios request library, passing the token and tenantId parameters. The request contains the Referer header information, indicating the domain name accessed by the current user group.

[0112] Secondly, the server processes the request: After receiving the request, the server extracts and parses the token, obtains the tenantId and user information contained in the token, and further obtains the tenantId and Referer parameters in the request.

[0113] Then, get the tenantId corresponding to the Referer: the server converts the access domain name in the Referer header into the corresponding tenantId according to the preset mapping relationship. The mapping relationship is pre-configured in the system to ensure that each access domain name has a unique corresponding tenantId.

[0114] Finally, compare the user group identifier: compare the tenantId in the request, the tenantId converted by Referer, and the tenantId parsed by token. If the three are consistent, the server determines that the request is legal and continues to process; if they are inconsistent, an error message is returned, and the front end is forced to refresh the page and re-execute the verification process.

[0115] Through the method of the present embodiment described above, the system can effectively verify the legitimacy of the user's identity token and page access request, which not only ensures the isolation of user groups and data security, but also prevents users from operating beyond their authority, thereby improving the security and reliability of the system.

[0116] In a further example, when the user's identity token is valid and the user's page access request passes the legitimacy verification, the user information is extracted from the user's identity token, and the user authority information is queried based on the user information, and the user authority information is returned to the front end. Specifically, the process of querying user authority information and dynamically registering the current user can access the route in this embodiment may include the following:

[0117] When the user's identity token is verified to be valid and the legitimacy of the user's page access request is verified, the system will extract the user information from the user's identity token and query the user's permission information based on the user information.

[0118] When the system verifies that the user's identity token is valid and the legitimacy of the user's page access request is verified, the system will continue the subsequent processing flow.

[0119] The server parses the token and extracts the user's basic information from it. This information usually includes the user's unique identifier (such as user ID), user group identifier (tenantId), and other related user attributes.

[0120] The server queries the user's permission information based on the user information extracted from the token. Permission information is usually stored in a permission management database or system, including the resources, function modules, and operation permissions that the user is authorized to access.

[0121] The server packages the queried user permission information into a response message and returns it to the front-end system. After receiving the permission information, the front-end system adjusts the display and functions of the user interface based on the information.

[0122] The front-end system uses the user permission information returned from the server to dynamically register the routes that the current user can access. This step ensures that the user can only access the pages and function modules within their permission range.

[0123] After dynamic registration is complete, the front-end system redirects the user to a start page that the user has permission to access. For example, this can be the user's personal dashboard, workspace, or other specified start page.

[0124] After the user is directed to the authorized page, he can continue to execute other business processes. The front-end system ensures that the user's operations are limited to the authorized scope based on the user's permission information.

[0125] Through the method of the present embodiment described above, the system can ensure accurate control of user access rights, dynamically adjust the user interface, and provide users with a personalized operating experience. This method not only improves the security and flexibility of the system, but also enhances the user experience.

[0126] In some embodiments, the method further comprises:

[0127] A corresponding business logic branch is configured for each user group ID, wherein each business logic branch contains the business requirements and operation permissions corresponding to the user group of the corresponding user group ID; when processing a user's page access request, the operation of the business logic branch corresponding to the user group ID is executed according to the user group ID corresponding to the user group to which the user belongs.

[0128] Specifically, in order to meet the specific business requirements and operation permissions of different user groups, this embodiment also includes configuring a corresponding business logic branch for each user group identifier (tenantId). The specific implementation steps are as follows:

[0129] First, configure the corresponding business logic branches for each user group ID (tenantId). These branches contain the business requirements and operation permissions corresponding to the user group. For example, user group tenant1 may need permission to access sales data and generate reports; user group tenant2 may need permission to access inventory management and purchase orders.

[0130] Furthermore, when a user initiates a page access request, the system verifies the validity of the user identity token through the aforementioned method and confirms the user's legitimate access request. The system determines the user group to which the user belongs based on the parsed tenantId. For example, the user group ID corresponding to tenant1 is tenant1.

[0131] Furthermore, based on the user's tenantId, the system executes the corresponding business logic branch. This means that the system will process user requests based on the specific needs of the user group. For example: if the tenantId is tenant1, the business logic of user group tenant1 is executed, allowing the user to access and operate sales data. If the tenantId is tenant2, the business logic of user group tenant2 is executed, allowing the user to access inventory management functions.

[0132] Furthermore, the server processes the user request and returns the corresponding business data according to the executed business logic branch. The system ensures that the business data corresponds to the user group identifier, thereby meeting the specific needs of the user group.

[0133] Furthermore, when processing other business requests, the system repeats the above-mentioned embodiment to check the validity of the user identity token and the legitimacy of the page access request to ensure that each request is strictly verified. According to the tenantId in the request, the system obtains the business data under the corresponding user group and returns it to the front-end page.

[0134] Through the method of the present embodiment described above, the system can effectively execute the corresponding business logic according to the user group identifier (tenantId), ensuring that the user's request is processed correctly and safely. This method improves the flexibility and security of the system and meets the specific needs and operation permissions of different user groups.

[0135] According to the technical solution provided in the embodiment of the present application, the embodiment of the present application can realize that the business system provides services to different user groups at the same time, and ensures the isolation of data and configuration between different user groups, thereby ensuring data security and privacy. The technical solution of the present application has at least the following advantages:

[0136] 1. Multi-user group data isolation and security: The technical solution of this application configures the mapping relationship between different user groups and access domain names, and uses Kubernetes and Nginx Ingress technology to ensure that different user groups access services through their own domain names. This isolation mechanism at the access entry level can effectively prevent the data and configurations between different user groups from being confused, and ensure the data security and privacy of each user group.

[0137] 2. Efficient identity authentication and permission management: By introducing the identity token mechanism into the system, the user's login status and access rights are strictly verified and managed. Every time the user initiates a request, the system checks the validity of the token to ensure the legitimacy of the request and dynamically allocates permissions based on the user's tenantId. This method ensures that users can only access their authorized data and functions to prevent unauthorized operations.

[0138] 3. Customization capability: The system configures corresponding business logic branches according to the specific needs of different user groups, and executes corresponding business logic when processing user requests. User groups are distinguished by tenantId and differentiated business processing capabilities are provided for them, so that the system can flexibly meet the personalized needs of each user group.

[0139] 4. Reduce development workload: This technical solution uses containerization technology to encapsulate services in a Kubernetes cluster for management and deployment. Each service only needs to be deployed once to provide services to multiple user groups. The Nginx Ingress controller is responsible for routing requests from different user groups to the corresponding service instances. This method simplifies the system development and deployment process and reduces development workload.

[0140] 5. Improve system maintainability: Through the centrally managed mapping relationship and dynamically configured routing mechanism, the system can be maintained and updated more easily. Any modification to the user group configuration only needs to be adjusted in the configuration file, without making large-scale changes to the overall system architecture. The containerized deployment method further enhances the flexibility and scalability of the system.

[0141] 6. Enhanced user experience: After the user logs in, the system dynamically adjusts the front-end interface according to their permissions and provides a customized operation interface that matches the user's role and permissions. By dynamically registering user-accessible routes and jumping to the authorized start page, the continuity and consistency of the user experience is ensured.

[0142] Therefore, to sum up, the method of multiple user groups sharing front-end instances in the present application not only solves the data isolation and security problems in the multi-user group business system, but also provides efficient identity authentication and permission management, while reducing the workload of development and maintenance, improving the flexibility and maintainability of the system, and ultimately enhancing the user experience.

[0143] The following is an embodiment of the device of the present application, which can be used to execute the embodiment of the method of the present application. For details not disclosed in the embodiment of the device of the present application, please refer to the embodiment of the method of the present application.

[0144] Figure 6 Schematic diagram of the structure of a dynamic data access control device based on multiple user groups provided in an embodiment of the present application. Figure 6 As shown, the dynamic data access control device based on multiple user groups includes:

[0145] The matching module 601 is configured to respond to a page access request initiated by a user, obtain an access domain name of the current page, match the access domain name with a user group identifier corresponding to the user, and store the user group identifier in a browser cache when the match succeeds;

[0146] The judgment module 602 is configured to judge whether the user is logged in according to the identity token in the browser cache, and when it is judged that the user is not logged in, initiate a login request and perform access permission verification according to the information input by the user; when it is judged that the user is logged in, initiate a user permission query request using the identity token to obtain user permission information;

[0147] Verification module 603, configured to check whether the user's identity token is valid and to verify the legitimacy of the user's page access request;

[0148] The query module 604 is configured to extract user information from the user's identity token when the user's identity token is valid and the legitimacy verification of the user's page access request is passed, query user authority information based on the user information, and return the user authority information to the front end;

[0149] Configuration module 605 is configured to dynamically configure the user's data access route according to the user's authority information, and after the dynamic registration of user authority is completed, redirect the front-end application page to the user's start page so that the user can perform operations that meet the authority requirements based on the start page.

[0150] In some embodiments, Figure 6 The establishment module 606 responds to the page access request initiated by the user and before obtaining the access domain name of the current page, sets the corresponding access domain name for each user group in the system configuration file, and establishes an access domain name mapping relationship between the user group and the access domain name, and binds the access domain names corresponding to different user groups to the deployed services, so that the controller can route different domain name requests to the corresponding services according to the access domain name mapping relationship, wherein each service is encapsulated in one or more containers.

[0151] In some embodiments, Figure 6 The matching module 601 obtains the user's page access request, uses a predetermined object to obtain the access domain name of the current page, and compares the obtained access domain name with the pre-configured access domain name mapping relationship; when the access domain name matches the access domain name configured by any user group, it is determined that the page access request comes from the user group, and the user group identifier corresponding to the user group to which the user belongs is obtained.

[0152] In some embodiments, Figure 6 When the user's identity token does not exist in the browser cache, the judgment module 602 judges that the user is not logged in, redirects the user to the login page, obtains the user name and password entered by the user, and constructs a login request according to the user name, password, user group ID and request header parameters; sends the login request to the server, so that the server determines whether the access domain name in the request header parameter is consistent with the access domain name of the login request according to the pre-configured access domain name mapping relationship. When it is judged to be consistent, the access permission verification is passed. When it is judged to be inconsistent, an error message is returned to the front end, and the server logs in again.

[0153] In some embodiments, Figure 6The judgment module 602 determines that the user has logged in when there is a user identity token in the browser cache, generates a user permission query request using the identity token, and sends the user permission query request to the server; uses the server to verify the validity of the identity token, and when the validity verification passes, queries the user permission information based on the user identifier in the identity token, and returns the queried user permission information to the front end, so that the front end can adjust the interface display according to the user permission information.

[0154] In some embodiments, Figure 6 The verification module 603 checks the structure and signature of the identity token, and verifies the timestamp of the identity token to determine whether the identity token is valid; when the identity token is determined to be valid, a page access request is initiated to the server, so that the server extracts the user group identifier, the identity token and the request header parameter from the page access request; according to the pre-configured access domain name mapping relationship, the access domain name in the request header parameter is converted into the corresponding user group identifier, and the user group identifier is extracted from the identity token, and the user group identifier in the page access request, the user group identifier corresponding to the request header parameter and the user group identifier in the identity token are compared; when the user group identifiers are consistent, the page access request is verified to be a legal request; when any user group identifier is inconsistent, the page access request is verified to be an illegal request.

[0155] In some embodiments, Figure 6 The configuration module 605 configures a corresponding business logic branch for each user group identifier, wherein each business logic branch contains the business requirements and operation permissions corresponding to the user group with the corresponding user group identifier; when processing a user's page access request, the operation of the business logic branch corresponding to the user group identifier is executed according to the user group identifier corresponding to the user group to which the user belongs.

[0156] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0157] Figure 7 Schematic diagram of the structure of the electronic device 7 provided in the embodiment of the present application. Figure 7 As shown, the electronic device 7 of this embodiment includes: a processor 701, a memory 702, and a computer program 703 stored in the memory 702 and executable on the processor 701. When the processor 701 executes the computer program 703, the steps in the above-mentioned method embodiments are implemented. Alternatively, when the processor 701 executes the computer program 703, the functions of the modules / units in the above-mentioned device embodiments are implemented.

[0158] Exemplarily, the computer program 703 may be divided into one or more modules / units, which are stored in the memory 702 and executed by the processor 701 to complete the present application. The one or more modules / units may be a series of computer program instruction segments capable of completing specific functions, which are used to describe the execution process of the computer program 703 in the electronic device 7.

[0159] The electronic device 7 may be a desktop computer, a notebook, a PDA, a cloud server, or other electronic device. The electronic device 7 may include, but is not limited to, a processor 701 and a memory 702. Those skilled in the art will appreciate that Figure 7 It is only an example of the electronic device 7 and does not constitute a limitation of the electronic device 7. It may include more or fewer components than shown in the figure, or a combination of certain components, or different components. For example, the electronic device may also include input and output devices, network access devices, buses, etc.

[0160] The processor 701 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc.

[0161] The memory 702 may be an internal storage unit of the electronic device 7, for example, a hard disk or memory of the electronic device 7. The memory 702 may also be an external storage device of the electronic device 7, for example, a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the electronic device 7. Further, the memory 702 may also include both an internal storage unit of the electronic device 7 and an external storage device. The memory 702 is used to store computer programs and other programs and data required by the electronic device. The memory 702 may also be used to temporarily store data that has been output or is to be output.

[0162] The technicians in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In practical applications, the above-mentioned function allocation can be completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated in a processing unit, or each unit can exist physically separately, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.

[0163] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0164] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0165] In the embodiments provided in the present application, it should be understood that the disclosed devices / computer equipment and methods can be implemented in other ways. For example, the device / computer equipment embodiments described above are only schematic. For example, the division of modules or units is only a logical function division. There may be other division methods in actual implementation. Multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0166] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0167] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0168] If the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and the computer program can implement the steps of the above-mentioned various method embodiments when executed by the processor. The computer program may include computer program code, which may be in source code form, object code form, executable file or some intermediate form. Computer-readable media may include: any entity or device capable of carrying computer program code, recording medium, U disk, mobile hard disk, disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium, etc.

[0169] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. A dynamic data access control method based on multiple user groups, characterized in that: include: In response to a page access request initiated by a user, obtaining an access domain name of the current page, matching the access domain name with a user group identifier corresponding to the user, and storing the user group identifier in a browser cache when the match succeeds; Determine whether the user is logged in based on the identity token in the browser cache, and if it is determined that the user is not logged in, initiate a login request and perform access rights verification based on the information entered by the user; When it is determined that the user has logged in, a user authority query request is initiated using the identity token to obtain user authority information; Check whether the user's identity token is valid and verify the legitimacy of the user's page access request; When the user's identity token is valid and the legitimacy verification of the user's page access request is passed, the user information is extracted from the user's identity token, and the user authority information is queried based on the user information, and the user authority information is returned to the front end; According to the user authority information, the data access route of the user is dynamically configured, and after the dynamic registration of user authority is completed, the front-end application page is redirected to the user's start page, so that the user can perform operations that meet the authority requirements based on the start page; The step of checking whether the user's identity token is valid and verifying the legitimacy of the user's page access request includes: Check the structure and signature of the identity token, and verify the timestamp of the identity token to determine whether the identity token is valid; when the identity token is determined to be valid, initiate a page access request to the server, so that the server extracts the user group identifier, the identity token, and the request header parameters from the page access request; According to the pre-configured access domain name mapping relationship, the access domain name in the request header parameter is converted into a corresponding user group identifier, and the user group identifier is extracted from the identity token. The user group identifier in the page access request, the user group identifier corresponding to the request header parameter and the user group identifier in the identity token are compared. When the user group identifiers are consistent, the page access request is verified to be a legal request. When any user group identifier is inconsistent, the page access request is verified to be an illegal request.

2. The method according to claim 1, characterized in that Before obtaining the access domain name of the current page in response to the page access request initiated by the user, the method further includes: A corresponding access domain name is set for each user group in the system configuration file, and an access domain name mapping relationship is established between the user group and the access domain name, and the access domain names corresponding to different user groups are bound to the deployed services, so that the controller can route different domain name requests to the corresponding services according to the access domain name mapping relationship, wherein each of the services is encapsulated in one or more containers.

3. The method according to claim 2, characterized in that The step of obtaining the access domain name of the current page in response to the page access request initiated by the user, and matching the access domain name with the user group identifier corresponding to the user, includes: Obtain the user's page access request, use a predetermined object to obtain the access domain name of the current page, and compare the obtained access domain name with the pre-configured access domain name mapping relationship; when the access domain name matches the access domain name configured by any user group, determine that the page access request comes from the user group, and obtain the user group identifier corresponding to the user group to which the user belongs.

4. The method according to claim 1, characterized in that: When it is determined that the user is not logged in, a login request is initiated, and access permission verification is performed based on the information input by the user, including: When the identity token of the user does not exist in the browser cache, it is determined that the user is not logged in, the user is redirected to the login page, and the user name and password entered by the user are obtained, and a login request is constructed according to the user name, password, user group identifier and request header parameters; The login request is sent to the server, so that the server determines whether the access domain name in the request header parameter is consistent with the access domain name of the login request based on the pre-configured access domain name mapping relationship. When it is judged to be consistent, the access permission verification is passed. When it is judged to be inconsistent, an error message is returned to the front end, and the server logs in again.

5. The method according to claim 1, characterized in that When it is determined that the user has logged in, a user authority query request is initiated using the identity token to obtain user authority information, including: When the identity token of the user exists in the browser cache, it is determined that the user has logged in, a user authority query request is generated using the identity token, and the user authority query request is sent to the server; The server is used to verify the validity of the identity token. When the validity verification is passed, the user authority information is queried according to the user identifier in the identity token, and the queried user authority information is returned to the front end so that the front end can adjust the interface display according to the user authority information.

6. The method according to claim 1, characterized in that The method further comprises: A corresponding business logic branch is configured for each user group identifier, wherein each of the business logic branches contains the business requirements and operation permissions corresponding to the user group of the corresponding user group identifier; when processing the page access request of the user, the operation of the business logic branch corresponding to the user group identifier is executed according to the user group identifier corresponding to the user group to which the user belongs.

7. A dynamic data access control device based on multiple user groups, characterized in that: include: A matching module is configured to respond to a page access request initiated by a user, obtain an access domain name of the current page, match the access domain name with a user group identifier corresponding to the user, and when a match is successful, store the user group identifier in a browser cache; A judgment module is configured to judge whether the user is logged in according to the identity token in the browser cache, and when it is judged that the user is not logged in, initiate a login request and perform access rights verification according to the information input by the user; When it is determined that the user has logged in, a user authority query request is initiated using the identity token to obtain user authority information; A verification module, configured to check whether the identity token of the user is valid and to verify the legitimacy of the page access request of the user; A query module is configured to extract user information from the user's identity token when the user's identity token is valid and the legitimacy verification of the user's page access request is passed, query user authority information based on the user information, and return the user authority information to the front end; A configuration module is configured to dynamically configure the data access route of the user according to the user authority information, and after the dynamic registration of the user authority is completed, redirect the front-end application page to the user's start page, so that the user can perform operations that meet the authority requirements based on the start page; Among them, the verification module is used to check the structure and signature of the identity token, and verify the timestamp of the identity token to determine whether the identity token is valid; when the identity token is determined to be valid, a page access request is initiated to the server, so that the server extracts the user group identifier, identity token and request header parameters from the page access request; according to the pre-configured access domain name mapping relationship, the access domain name in the request header parameter is converted into a corresponding user group identifier, and the user group identifier is extracted from the identity token, and the user group identifier in the page access request, the user group identifier corresponding to the request header parameter and the user group identifier in the identity token are compared. When the user group identifiers are consistent, the page access request is verified to be a legal request, and when any user group identifier is inconsistent, the page access request is verified to be an illegal request.

8. An electronic device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images