Access control methods and systems, clients, servers, and storage media
By caching permission information on the client side and comparing it with the server's time, the interface is dynamically rendered, solving the problem of difficult user permission updates in existing technologies, improving system security and user experience, and reducing network and server pressure.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- CHINA TELECOM CORP LTD TECHNOLOGY INNOVATION CENTER
- Filing Date
- 2023-08-11
- Publication Date
- 2026-05-26
AI Technical Summary
Existing technologies require technical personnel to modify code when changing user permissions. Users can only update their permissions through user-initiated actions such as logging out of the system or waiting for their login to expire and then logging back in. This results in a poor user experience and security risks.
When a user logs into the system, the system obtains the user's basic information and permission information from the server and caches the permission information on the client. The system dynamically renders the interface by comparing the permission time. The server verifies the permission time difference to update the permission data.
This system eliminates the need for manual user intervention and code modification when user permissions change, improving system security and user experience, reducing network and server load, and preventing security issues caused by malicious tampering.
Smart Images

Figure CN117056952B_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of information technology, and in particular to an access control method and system, a client, a server, and a storage medium. Background Technology
[0002] In previous web systems, permissions were controlled by the backend for a long time. With the separation of frontend and backend architectures, permission control in more and more projects is now being implemented on the frontend.
[0003] RBAC (Role-Based Access Control) is currently the most widely used permission model. The core of this model is to introduce the concept of roles between users and permissions, eliminating the direct association between users and permissions, and instead indirectly granting permissions to users by associating users with roles and roles with permissions, thereby achieving the goal of decoupling users and permissions.
[0004] Two mainstream RBAC-based access control schemes in front-end technology:
[0005] Option 1: The frontend records all permissions and writes all permission information in the frontend project code. After a user logs in, the backend returns the user's role, and the frontend assigns permissions based on the role.
[0006] Option 2: The front-end records the page layout, and the back-end records permissions. After a user logs in, the available permissions are obtained from the back-end, and the page is rendered based on the permissions returned by the back-end. Summary of the Invention
[0007] The inventors discovered through research that both solutions in the related technologies are quite difficult to modify user permissions. They require technical personnel to modify the relevant code, and users can only update their permissions through user-initiated actions such as logging out of the system or waiting for their login to expire and then logging back in.
[0008] In view of at least one of the above technical problems, this disclosure provides an access control method and system, client, server and storage medium. If a user's permissions are changed, the user can directly obtain the latest permission data when making an operation request, and the client can directly render based on the latest permission information without making additional user permission requests.
[0009] According to one aspect of this disclosure, an access control method is provided, comprising:
[0010] When a user logs into the system, the system retrieves the user's basic information and permission information from the server. The permission information includes the first permission time.
[0011] Cache permission information on the client side;
[0012] Render the client interface based on permission information;
[0013] Send an operation request to the server, wherein the operation request includes a first permission time, so that the server can compare the first permission time with the second permission time in the database;
[0014] Receive response data returned by the server, wherein the response data includes an authorization time field;
[0015] The page is rendered based on the response data.
[0016] In some embodiments of this disclosure, rendering the page based on the response data includes:
[0017] If the permission time field is modified, the locally cached permission information is cleared, and the client interface is re-rendered using the new permission information. The response data also includes the new permission information. If the first permission time and the second permission time in the database are different, the server sets the permission time field to modified, updates the permission information, and returns the response data to the client.
[0018] In some embodiments of this disclosure, rendering the page based on the response data includes:
[0019] If the permission time field is empty, it is determined that the permission information has not been updated. The client interface is rendered according to the user request data. The response data also includes the user request data. If the first permission time and the second permission time in the database are the same, the server returns the response data to the client.
[0020] In some embodiments of this disclosure, the permission information further includes menu permission data and button permission data.
[0021] In some embodiments of this disclosure, rendering the client interface based on permission information includes:
[0022] Convert the data format of menu permission data and button permission data, including converting menu permission data into dynamic routing data;
[0023] Combine dynamic routing data and local default routing data into total permission routing data;
[0024] Loop through the total permission routing data and generate a menu bar;
[0025] The prototype mounting method is used to determine whether the button permission data contains the permission required by the button, and the permission button is dynamically rendered.
[0026] In some embodiments of this disclosure, the access control method further includes:
[0027] Receive menu and button permissions for the newly added role selected by the user;
[0028] The menu and button permissions of the newly added role selected by the user are sent to the server so that the server can configure the permissions and generate a second permission time based on the configuration time.
[0029] In some embodiments of this disclosure, the access control method further includes:
[0030] Send a role permission modification request to the server so that the server can modify the role permissions and update the second permission time according to the modified permission time.
[0031] According to another aspect of this disclosure, an access control method is provided, comprising:
[0032] The system receives an operation request sent by the client, wherein the operation request includes a first permission time, which is included in the permission information. The user's basic information and permission information are obtained from the server and cached on the client when the user logs into the system. The permission information is used to render the client interface.
[0033] Compare the first permission time with the second permission time in the database;
[0034] Based on whether the first permission time and the second permission time are the same, the corresponding response data is returned to the client so that the client can render the page according to the response data.
[0035] In some embodiments of this disclosure, returning corresponding response data to the client based on whether the first permission time and the second permission time are the same includes:
[0036] If the first permission time and the second permission time in the database are different, the permission time field is set to "modified" to update the permission information. Response data is then returned to the client, including the user's new permission information and the permission time field. This allows the client to clear the locally cached permission information and re-render the client interface using the new permission information.
[0037] In some embodiments of this disclosure, returning corresponding response data to the client based on whether the first permission time and the second permission time are the same includes:
[0038] If the first permission time and the second permission time in the database are the same, the permission time field is set to empty, and response data is returned to the client. The response data includes user request data and the permission time field, so that the client can render the client interface according to the user request data.
[0039] In some embodiments of this disclosure, the permission information further includes menu permission data and button permission data.
[0040] In some embodiments of this disclosure, the access control method further includes:
[0041] Receive menu permissions and button permissions for the newly added role sent by the client and selected by the user;
[0042] Configure permissions based on the menu and button permissions of the newly added role selected by the user;
[0043] Based on the configured time, a second permission time is generated and stored in the database.
[0044] In some embodiments of this disclosure, the access control method further includes:
[0045] Receive role permission modification requests sent by clients;
[0046] Modify role permissions according to the aforementioned role permission modification request;
[0047] Update the second permission time based on the modified permission time.
[0048] According to another aspect of this disclosure, a client is provided, comprising:
[0049] The information acquisition module is configured to obtain basic user information and permission information from the server when the user logs into the system. The permission information includes the first permission time.
[0050] The information caching module is configured to cache permission information on the client side.
[0051] The interface rendering module is configured to render the client interface based on permission information;
[0052] The operation request sending module is configured to send an operation request to the server, wherein the operation request includes a first permission time so that the server can compare the first permission time with the second permission time in the database;
[0053] The response data receiving module is configured to receive response data returned by the server, wherein the response data includes an authorization time field;
[0054] The interface rendering module is also configured to render the page based on the response data.
[0055] According to another aspect of this disclosure, a client is provided, comprising:
[0056] The client-side memory is configured to store instructions;
[0057] A client processor is configured to execute the instructions, causing the client to perform operations implementing the access control method as described in any of the above embodiments.
[0058] According to another aspect of this disclosure, a server is provided, comprising:
[0059] The operation request receiving module is configured to receive operation requests sent by the client. The operation request includes a first permission time, which is included in the permission information. The user basic information and permission information are obtained from the server and cached on the client when the user logs into the system. The permission information is used to render the client interface.
[0060] The permission verification module is configured to compare the first permission time with the second permission time in the database; and return corresponding response data to the client based on whether the first permission time and the second permission time are the same, so that the client can render the page based on the response data.
[0061] According to another aspect of this disclosure, a server is provided, comprising:
[0062] The server-side storage is configured to store instructions;
[0063] A server-side processor is configured to execute the instructions, causing the server to perform operations implementing the access control method as described in any of the above embodiments.
[0064] According to another aspect of this disclosure, an access control system is provided, including a client as described in any of the above embodiments and a server as described in any of the above embodiments.
[0065] According to another aspect of this disclosure, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores computer instructions that, when executed by a processor, implement the access control method as described in any of the above embodiments.
[0066] In this disclosure, if user permissions are changed, the user can directly obtain the latest permission data when making an operation request. The client can then directly render based on the latest permission information without needing to make additional user permission requests. Users can perform operations on the client based on the latest permissions without being forced to exit the system. Attached Figure Description
[0067] To more clearly illustrate the technical solutions in the embodiments of this disclosure 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 some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0068] Figure 1 This is a schematic diagram of some embodiments of the access control method disclosed herein.
[0069] Figure 2 This is a relationship mapping diagram of the RBAC-based access control system in some embodiments of this disclosure.
[0070] Figure 3 This is a schematic diagram of some other embodiments of the access control method disclosed herein.
[0071] Figure 4 This is a schematic diagram of some embodiments of the access control method disclosed herein.
[0072] Figure 5 This is a schematic diagram of some other embodiments of the access control method disclosed herein.
[0073] Figure 6 This is a schematic diagram of some embodiments of the access control method disclosed herein.
[0074] Figure 7 This is a schematic diagram of some embodiments of the access control method disclosed herein.
[0075] Figure 8 This is a schematic diagram of some embodiments of the client disclosed herein.
[0076] Figure 9 This is a schematic diagram of the structure of some other embodiments of the client disclosed herein.
[0077] Figure 10 This is a schematic diagram of some embodiments of the server-side of this disclosure.
[0078] Figure 11 This is a schematic diagram of the structure of some other embodiments of the server disclosed herein. Detailed Implementation
[0079] The technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit this disclosure or its application or use. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without creative effort are within the scope of protection of this disclosure.
[0080] Unless otherwise specifically stated, the relative arrangement, numerical expressions, and values of the components and steps set forth in these embodiments do not limit the scope of this disclosure.
[0081] At the same time, it should be understood that, for ease of description, the dimensions of the various parts shown in the accompanying drawings are not drawn according to actual scale.
[0082] Techniques, methods, and equipment known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and equipment should be considered part of the specification.
[0083] In all examples shown and discussed herein, any specific values should be interpreted as merely exemplary and not as limitations. Therefore, other examples of exemplary embodiments may have different values.
[0084] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be discussed further in subsequent figures.
[0085] The inventors discovered through research that both approaches in the related technologies are difficult to modify user permissions. Technical personnel are required to modify relevant code, and users can only update permissions through user-initiated actions such as logging out of the system or waiting for their login to expire and then logging back in. If a user's role has increased permissions, the user cannot use the increased permissions in a timely manner, affecting the user experience. Conversely, if a user's role has decreased permissions, certain user functions cannot be restricted in a timely manner, potentially leading to system security issues.
[0086] To implement dynamic permissions and improve performance, permission data must be cached on the client side. The specific reasons are as follows:
[0087] 1) Server-side performance: The user permission data structure is complex, and the data volume increases with the growth of business. For each request, the server has to reread and reassemble this data from the database according to the specified format, which is unnecessary and increases the server load.
[0088] 2) Network Performance: Depending on different business needs, retrieving all user permission data might be set up as a separate interface. If the client does not cache this data, every user action will call this interface, significantly increasing network requests and requiring the re-retrieval of user permission data. This will generate a large number of redundant and useless network requests, increasing the interface load.
[0089] 3) Client-side performance: To ensure the client uses the latest permissions, and assuming there's no cached data to compare permission changes, the client needs to use all the complete permission data in the response for permission rendering (including menu and button permissions) every time it receives a request, significantly increasing the client's workload. Often, even when permissions haven't changed, re-rendering is still necessary. This re-rendering negatively impacts front-end performance and is unnecessary.
[0090] 4) Client-side technology: Current mainstream front-end frameworks such as Vue and React, which are based on JavaScript, store data in memory for their state management libraries. This data disappears with each refresh. Caching technology is needed to cache data locally to avoid errors or blank pages caused by data loss upon refresh. Furthermore, without local caching of the first permission time, permission comparisons are impossible (whether comparing all permission data or permission time, caching is necessary).
[0091] Because the relevant technology includes client-side caching, users can illegally and maliciously tamper with the client's local cache, thereby preventing permission updates and causing security issues.
[0092] When implementing front-end access control using related technologies, if the permissions corresponding to a user's role change, the front-end code needs to be rewritten using hard coding. Furthermore, it's impossible to update the user's latest menu and button permissions in the front-end system in a timely manner, requiring manual user intervention. Local caching is essential in dynamic menus, but users can maliciously tamper with the local cache to skip permission updates, impacting system security, resulting in a poor user experience and low efficiency.
[0093] In view of at least one of the above technical problems, this disclosure provides an access control method and system, a client, a server, and a storage medium, which will be described below through specific embodiments.
[0094] Figure 1 This is a schematic diagram of some embodiments of the access control method of this disclosure. Preferably, this embodiment can be executed by the access control system of this disclosure or the client of this disclosure. The method includes at least one step of steps 11-15, wherein:
[0095] Step 11: If the user is logged into the system, obtain the user's basic information and permission information from the server. The permission information includes the first permission time.
[0096] In some embodiments of this disclosure, the server is a backend or a server.
[0097] In some embodiments of this disclosure, the client is a front-end or a user terminal.
[0098] In some embodiments of this disclosure, the permission information may further include menu permission data and button permission data.
[0099] In some embodiments of this disclosure, the system is an information system.
[0100] In some embodiments of this disclosure, basic user information includes user ID, user role, user login token, etc.
[0101] Figure 2 This is a relationship mapping diagram of the RBAC-based access control system in some embodiments of this disclosure. For example... Figure 2 As shown, user permissions are indirectly granted by associating users with roles and roles with permissions, thereby achieving the goal of decoupling users and permissions. Figure 2 As shown, roles are assigned to users, and corresponding permissions are assigned to roles. Permissions include menu permissions and button permissions.
[0102] Step 12: Cache permission information on the client side.
[0103] In some embodiments of this disclosure, step 12 may include: caching user basic information and permission information on the client side.
[0104] In some embodiments of this disclosure, step 12 may include: caching in the browser's sessionStorage, and for JS-based front-end frameworks, synchronously storing information in a state management library.
[0105] Step 13: Render the client interface based on the permission information.
[0106] In some embodiments of this disclosure, step 13 may include at least one of steps 131-133, wherein:
[0107] Step 131: Convert the menu permission data and button permission data into different data formats, including converting the menu permission data into dynamic routing data.
[0108] Step 132: Merge the dynamic routing data and the local default routing data into the total permission routing data.
[0109] Step 133: Loop through the total permission routing data and generate the menu bar.
[0110] Step 134: Use the prototype mounting method to determine whether the button permission data contains the permission required by the button, and dynamically render the permission button.
[0111] Step 14: Send an operation request to the server, wherein the operation request includes a first permission time so that the server can compare the first permission time with the second permission time in the database.
[0112] In some embodiments of this disclosure, the operation request may be an operation request such as adding, deleting, modifying, or querying.
[0113] Step 15: Receive the response data returned by the server, wherein the response data includes an authorization time field.
[0114] Step 16: Render the page based on the response data.
[0115] In some embodiments of this disclosure, step 16 may include at least one of steps 161-166, wherein:
[0116] Step 161: If the permission time field is modified, clear the locally cached permission information and re-render the client interface using the new permission information. The response data also includes the new permission information. If the first permission time and the second permission time in the database are different, the server sets the permission time field to modified, updates the permission information, and returns the response data to the client.
[0117] In some embodiments of this disclosure, step 161, the step of re-rendering the client interface with new permission information, includes performing step 13 with the new permission information.
[0118] In some embodiments of this disclosure, the new permission information includes a new first permission time, new menu permission data, and new button permission data.
[0119] In some embodiments of this disclosure, when the first permission time and the second permission time in the database are different, the response data does not include the user request data because: after the permission is updated, the permissions involved in the user request data may have changed. For example, if the user's permissions become smaller, the user will not have the permission to request the data. Therefore, the response data does not include the user request data.
[0120] Step 162: If the permission time field is empty, it is determined that the permission information has not been updated. The client interface is rendered according to the user request data. The response data also includes the user request data. If the first permission time and the second permission time in the database are the same, the server returns the response data to the client.
[0121] In some embodiments of this disclosure, the permission control method may further include: receiving menu permissions and button permissions for a newly added role selected by a user (e.g., a parent user); sending the menu permissions and button permissions for the newly added role selected by the user to the server so that the server can configure permissions and generate a second permission time based on the configuration time.
[0122] In some embodiments of this disclosure, the access control method may further include: sending a role permission modification request to the server so that the server can modify the role permissions and update the second permission time according to the modified permission time.
[0123] In the embodiments disclosed above, the server of the information system can generate data such as permission time values based on the user permission configuration time. After the user logs in, permission data is returned, and the system can dynamically render the front-end interface based on the user permission data. When role permissions change, the permission generation module generates new permission time values. The server-side permission verification module compares the first permission time with the second permission time and provides timely feedback on the latest permission data. The front-end can update the permission data promptly and seamlessly and perform dynamic rendering.
[0124] The embodiments disclosed above do not require developers to manually modify the code when permissions change, nor do they require users to manually operate the system. They are highly secure, perform well, and prevent users from maliciously tampering with permissions.
[0125] The embodiments described above can be applied to scenarios requiring access control of information systems in web applications based on front-end and back-end separation. In these embodiments, users can only access and operate on pages, buttons, and data that their roles have the necessary permissions for; users cannot maliciously control permissions.
[0126] Figure 3 This is a schematic diagram of some other embodiments of the access control method of this disclosure. Preferably, this embodiment can be executed by the access control system of this disclosure or the client of this disclosure. The method includes at least one step of steps 30-39, wherein:
[0127] Step 30: The user logs into the information system from the client.
[0128] Step 31: Determine if permission information is in the cache. If no permission information is in the cache, proceed to step 32; otherwise, if no permission information is in the cache, proceed to step 35.
[0129] Step 32: Obtain basic user information.
[0130] In some embodiments of this disclosure, basic user information may include user ID, user role, user login token, etc.
[0131] Step 33: Obtain permission information.
[0132] In some embodiments of this disclosure, the permission information is the current permission information of the user role.
[0133] In some embodiments of this disclosure, the permission information is user role permission information.
[0134] In some embodiments of this disclosure, the permission information includes: user menu permission data, button permission data, and first permission time.
[0135] Step 34: Cache the permission information on the front end (client).
[0136] In some embodiments of this disclosure, step 34 may include: caching user basic information and permission information on the client side.
[0137] In some embodiments of this disclosure, step 34 may include: caching in the browser's sessionStorage, and for JS-based front-end frameworks, synchronously storing information in a state management library.
[0138] Step 35: Render the client interface based on permission information.
[0139] In some embodiments of this disclosure, step 35 may include: rendering the front-end interface based on permission information. Only pages, buttons, and data that the user has permission to access are displayed.
[0140] In some embodiments of this disclosure, step 35 may include: Figure 1 At least one of steps 131-133 in the embodiment.
[0141] In some embodiments of this disclosure, step 35 may include: Figure 4 At least one of steps 382-388 in the embodiment.
[0142] In some embodiments of this disclosure, step 35 may include: menu permission rendering: merging permission routes and default routes to generate dynamic routes for rendering; button permission rendering: setting instructions to determine whether the permissions required for this button are authorized.
[0143] Step 36: The client sends an operation request to the server, wherein the operation request includes a first permission time, so that the server can compare the first permission time with the second permission time in the database.
[0144] In some embodiments of this disclosure, such as Figure 3 As shown, step 36 can be executed if the user's role permissions change.
[0145] In some other embodiments of this disclosure, step 36 can be performed without changing the user's role permissions.
[0146] In some embodiments of this disclosure, the operation request may be an operation request such as adding, deleting, modifying, or querying.
[0147] In some embodiments of this disclosure, step 36 may include: the user can perform corresponding operations under this permission and send an operation request to the server.
[0148] In some embodiments of this disclosure, the server-side permission verification module compares the first permission time in the business request with the second permission time in the database, and returns specific data to the client depending on the situation. Specifically: the latest permission time is stored in the database as the second permission time, and this second permission time is compared with the first permission time in the user request. If the permission time values are the same, the current user permission is the latest permission, and the server returns response data including: user request data, and the permission time field is set to empty. If the first permission time and the second permission time are different, the server returns response data as: the user's latest permission data, and the permission time value is set to "Modified".
[0149] Step 37: The client receives the response data returned by the server; the client interface rendering module checks whether the permission time field in the response data is "Modified" and performs the corresponding rendering processing. Specific steps are steps 38 and 39.
[0150] Step 38: If it is "Modified", then the user's permissions have changed. The client clears the locally cached permission information and uses the permission data (new permission information) in the response data to render the front-end interface, etc.
[0151] Step 39: If it is not "Modified", then the user's permissions have not changed, and the business data (user request data) in the response data is used for rendering.
[0152] To address the technical problems mentioned in related technologies, the present disclosure proposes a front-end and back-end separated information system access control method in the above embodiments. In the access control scheme of the above embodiments of the present disclosure, after a user logs into the system, the current user's access information is obtained. Based on this access information, the front-end is rendered, displaying only front-end elements such as menus and buttons that the user currently has access to. Subsequently, if the user's permissions change, when the user makes an operation request, the latest access data can be directly obtained. The front-end can then directly render based on the latest access information without requiring additional user access requests. The user can operate based on the latest permissions without being forced to exit the system. Users also cannot control or prevent access updates by maliciously tampering with browser cache values. Developers also do not need to manually modify the code.
[0153] The embodiments disclosed above solve the problems that the front end of the information system cannot update user permissions in a timely and seamless manner, and that users can violate permission restrictions by maliciously operating to avoid permission updates, thereby improving system security, overall performance and user experience.
[0154] Figure 4 This is a schematic diagram illustrating some embodiments of the access control method disclosed herein. Preferably, this embodiment can be executed by the access control system or the client of this disclosure. Figure 4 The method of the embodiment (e.g.) Figure 1 Steps 15 and 16 of the embodiment may include at least one of steps 371-389 and step 39, wherein, Figure 3 Step 37 of the embodiment may include Figure 4 At least one of steps 371 to 372 in the embodiment, Figure 3 Step 38 of the embodiment may include Figure 4 At least one of steps 381 to 388 in the embodiment, Figure 3 Step 39 of the embodiment and Figure 4 Step 39 of the embodiment is the same as or similar to that of the embodiment, wherein:
[0155] Step 371: Receive response data returned by the server, wherein the response data includes an authorization time field.
[0156] Step 372: Determine whether the permission time field in the response data is "Modified". If the permission time field is "Modified", proceed to step 381; otherwise, if the permission time field is not "Modified", proceed to step 39.
[0157] Step 381: If the value is "Modified", then the user's permissions have changed. The client clears the locally cached permission information and uses the permission data (new permission information) in the response data to render the front-end interface.
[0158] Step 382: Convert the data format of the menu permission data and button permission data.
[0159] In some embodiments of this disclosure, step 382 may include: converting the acquired permission data into a data format: for menu permission data, converting it into permission routing data `permission_router`; for button permission data, converting it into a `permission_btn` array.
[0160] Step 383: Recursively traverse the menu permission data and convert it into dynamic routing data that meets system requirements.
[0161] In some embodiments of this disclosure, step 383 may include: using the filterAsyncRouter() method, in a recursive manner, converting the permission data string into a component object that meets the system requirements, as the dynamic routing data required for the next step.
[0162] Step 384: Merge the dynamic routing data and the local default routing data into the total permission routing data.
[0163] In some embodiments of this disclosure, step 384 may include: improving the routing.
[0164] In some embodiments of this disclosure, step 384 may include: using the route interceptor `router.beforeEach()` to determine whether local routing data exists during each hop; merging the processed dynamic routing data and some pre-set default routing data locally using the `addRoutes()` method to form the final permission routing data `permission_router`, and storing it in the relevant state management library.
[0165] Step 385: Loop through the total permission routing data and generate the menu bar.
[0166] In some embodiments of this disclosure, step 385 may include: menu rendering.
[0167] In some embodiments of this disclosure, step 385 may include: looping through the data of permission_router using a JS-based front-end framework, and dynamically rendering it. Parameters can be added for judgment based on custom routing requirements.
[0168] Step 386: Use the prototype mounting method to determine whether the button permission data contains the permissions required by the button.
[0169] In some embodiments of this disclosure, step 386 may include: adding a $_has method, which is used to determine whether the permission required by the button exists in the permission_btn data, and attaching the $_has method to the prototype for subsequent calls.
[0170] Step 387: Set the v-has directive, mount it in the inserted phase, and add it to the button that requires authentication.
[0171] In some embodiments of this disclosure, step 387 may include: creating a directive.js file, creating a v-has directive using .directive(), and calling the $_has method mounted on the prototype when an inserted child hook occurs. The v-has directive can be used globally after the directive.js file is included in the main file. Adding the v-has directive to buttons requiring permission control will display the corresponding permission button based on the permission_btn data.
[0172] Step 388, Dynamic Rendering Button.
[0173] Step 39: If it is not "Modified", then the user's permissions have not changed, and the business data (user request data) in the response data is used for rendering.
[0174] The purpose of client-side permission caching in this disclosure is to: 1) avoid calling the permission interface to obtain permission data for each request, thereby reducing network request pressure; 2) avoid the server repeatedly reading and assembling user permission data, thereby reducing server pressure; and 3) avoid unnecessary front-end rendering, thereby reducing rendering pressure and reducing client pressure.
[0175] The inventors discovered through research that while not caching on the client side can theoretically avoid inaccurate permission issues, this comes at the cost of severely impacting server performance, client performance, network performance, and causing user interface crashes or errors. This demonstrates the necessity of client-side permission caching. Since local caching is unavoidable due to the aforementioned performance issues, this disclosure addresses the problems caused by caching.
[0176] This disclosure requires both server-side comparison and client-side caching; neither can be omitted. Server-side comparison helps prevent malicious tampering with the client's local cache, thus avoiding the bypassing of permission updates.
[0177] The starting point of the above embodiments disclosed in this paper is that permissions can be dynamically set, which is different from the current method of hard-coding user role permissions.
[0178] Figure 5This is a schematic diagram of some other embodiments of the access control method disclosed herein. Preferably, this embodiment can be executed by the access control system or the server of this disclosure. The method includes at least one step from steps 51 to 53, wherein:
[0179] Step 51: Receive an operation request sent by the client, wherein the operation request includes a first permission time, which is included in the permission information. The user basic information and permission information are obtained from the server and cached on the client when the user logs into the system. The permission information is used to render the client interface.
[0180] In some embodiments of this disclosure, the permission information includes a first permission time, menu permission data, and button permission data.
[0181] Step 52: Compare the first permission time with the second permission time in the database;
[0182] Step 53: Based on whether the first permission time and the second permission time are the same, return the corresponding response data to the client so that the client can render the page according to the response data.
[0183] In some embodiments of this disclosure, step 53 may include at least one of steps 531 and 532, wherein:
[0184] Step 531: If the first permission time and the second permission time in the database are different, set the permission time field to "modified", update the permission information, and return response data to the client. The response data includes the user's new permission information and the permission time field, so that the client can clear the locally cached permission information and re-render the client interface with the new permission information.
[0185] Step 532: If the first permission time and the second permission time in the database are the same, set the permission time field to empty and return response data to the client. The response data includes user request data and the permission time field, so that the client can render the client interface according to the user request data.
[0186] The above embodiments of this disclosure propose an access control method that achieves timely updates to front-end access control by adding access time limits. The access control generation module generates access time limits based on the role's access configuration time; when a role's access permissions are modified, the access time limits are updated synchronously.
[0187] In the embodiments described above, after receiving a client request, the server extracts the first permission time and compares it with the second permission time in the database, controlling whether to directly return the latest permission.
[0188] In the embodiments described above, the client determines whether to render the front-end interface based on the "Modified" value in the returned data.
[0189] The embodiments disclosed above use a method of recording permission configuration time instead of complete permission data, thereby improving performance.
[0190] The front end of the above embodiments of this disclosure can obtain the latest permissions in a timely manner without having to send a permission request again.
[0191] The above embodiments of this disclosure compare the time values of permissions on the server side to avoid the client from maliciously tampering with the local cache values, which would lead to untimely permission updates.
[0192] In the embodiments disclosed above, users can operate with the latest permissions without being aware of it, and do not need to be forcibly logged out of the system.
[0193] When the permissions of the embodiments described above are changed, developers do not need to modify the code.
[0194] Figure 6 This is a schematic diagram illustrating some embodiments of the access control method disclosed herein. Preferably, this embodiment can be executed by the access control system or the server of this disclosure. The method includes at least one step from steps 61 to 65, wherein:
[0195] Step 61: Add a new role. In the permission configuration module, visually select the menu permissions and button permissions that the current role has. Based on the configured time of the permissions, generate a second permission time.
[0196] In some embodiments of this disclosure, step 61 may include: receiving menu permissions and button permissions of a newly added role selected by the user from the client; configuring permissions according to the menu permissions and button permissions of the newly added role selected by the user; generating a second permission time based on the configuration time, and storing it in the database.
[0197] In some embodiments of this disclosure, step 61 may include: when a new role is added and permissions are configured in the permission configuration module, the permission generation module needs to generate a second permission time based on the time of the configured permissions and store it in the database.
[0198] Step 62: When a role's permissions are modified, the second permission time needs to be updated based on the modified permission time and then updated in the database.
[0199] In some embodiments of this disclosure, step 62 may include: receiving a role permission modification request sent by a client; modifying role permissions according to the role permission modification request; and updating the second permission time according to the modified permission time.
[0200] Step 63: After receiving the client request, the server-side permission verification module compares the first permission time carried in the request with the second permission time in the database.
[0201] Step 64: If the first permission time and the second permission time are the same, it proves that the permission has not changed and the current user's permission is the latest permission. The server returns response data including: user request data (the requested data) and the permission time field is set to empty.
[0202] Step 65: If the first permission time and the second permission time are different, it proves that the permission has changed and the permission data has been updated. The server returns the following response data: the user's latest permission data and the permission time period is set to "Modified".
[0203] The embodiments described above perform comparison and verification on the server side, so even if a user maliciously tampers with the client's first permission data, they cannot prevent permission updates.
[0204] The embodiments of this disclosure use permission configuration or modification time instead of completion permission data for comparison. The embodiments of this disclosure generate permission time values with good performance and require no complex calculations.
[0205] The above embodiments of this disclosure add a permission time, i.e., the latest modification time of the permission, to help verify permission updates in permission control. The permission time generation in the above embodiments of this disclosure is fast and easy to compare, greatly reducing the pressure on the server.
[0206] The embodiments disclosed above compare permission times in the server-side permission verification module, which can effectively and significantly avoid the security problems caused by malicious tampering of locally cached permissions with the permissions responded by the server through the browser when comparing on the client side, making the system think that the permissions have not changed and skip the permission update.
[0207] The method described in the above embodiments of this disclosure can significantly reduce the amount of system computation during the permission comparison process and minimize the number of network requests required to update permissions, thereby greatly improving performance.
[0208] Figure 7 This is a schematic diagram of some embodiments of the access control method of this disclosure. Preferably, this embodiment can be executed by the access control system of this disclosure. Or, the server-side method of this disclosure includes at least one step from steps 701-716, wherein:
[0209] Steps 701 to 703 are steps to configure permissions for the new role.
[0210] Step 701: Add a user and configure role permissions.
[0211] In some embodiments of this disclosure, step 701 may include: the client sending the menu permissions and button permissions of the newly added role selected by the user to the server.
[0212] Step 702: The server generates and saves the second permission time.
[0213] In some embodiments of this disclosure, step 702 may include: the server configuring permissions based on the menu permissions and button permissions of the newly added role selected by the user; generating a second permission time based on the configuration time, and storing it in the database.
[0214] Step 703: The server returns a configuration success message to the client.
[0215] Steps 704 to 706 are steps for modifying permissions.
[0216] Step 704: The client sends a request to the server to modify user role permissions.
[0217] Step 705: The server updates the second permission time based on the modified permission time.
[0218] In some embodiments of this disclosure, step 705 may include: the server modifying role permissions according to the role permission modification request; and updating the second permission time according to the modified permission time.
[0219] Step 706: The server returns a success message to the client.
[0220] Step 707: The client sends a user login request to the server and obtains the user's basic information and permission information from the server.
[0221] In some embodiments of this disclosure, the permission information may include a first permission time, menu permission data, and button permission data.
[0222] In some embodiments of this disclosure, basic user information includes user ID, user role, user login token, etc.
[0223] Step 708: The server returns basic user information and permission information to the client.
[0224] Step 709: Cache user basic information and permission information on the client side.
[0225] Step 710: The client renders the client interface based on the permission information.
[0226] In some embodiments of this disclosure, step 710 may include: Figure 1 At least one of steps 131-133 in the embodiment.
[0227] In some embodiments of this disclosure, step 710 may include: Figure 4 At least one of steps 382-388 in the embodiment.
[0228] Step 711: The client sends an operation request to the server. The operation request includes a first permission time and other fields required by the business interface. The first permission time is the permission time cached by the client. The other fields required by the business interface are other fields required by operation requests such as add, delete, modify, and query.
[0229] Step 712: The server compares the first permission time with the second permission time in the database to determine if they are the same.
[0230] Step 713: If the first permission time and the second permission time in the database are the same, the server sets the permission time field to empty and returns response data to the client. The response data includes user request data and the permission time field.
[0231] Step 714: The client sets the permission time field to empty to determine that the user's permissions have not changed, and renders the client interface based on the user request data in the response data.
[0232] Step 715: If the first permission time and the second permission time in the database are different, the server sets the permission time field to "modified", updates the permission information, and returns response data to the client. The response data includes the user's new permission information and the permission time field.
[0233] Step 716: The client and server determine that the user's permissions have changed based on the modified permission time field, clear the locally cached permission information, and re-render the client interface using the new permission information.
[0234] The embodiments disclosed above reduce server load and improve server performance: they use permission configuration time as a marker to compare permission data. The embodiments disclosed above do not require complex hash transformations of the permission data.
[0235] The embodiments disclosed above improve security by directly comparing the first and second permission times on the server side. Performing the comparison on the server enhances the security of permission comparison. Since client-side caching is unavoidable, users may maliciously tamper with browser permission time values, thereby bypassing system permission restrictions and preventing permission updates. Server-side comparison solves this problem.
[0236] The above embodiments of this disclosure reduce network pressure: if permissions change, the server directly returns the latest permission data, and the client does not need to send network requests again to obtain permissions, effectively reducing the number of network requests and alleviating network pressure.
[0237] The embodiments disclosed above enhance the security of information system access control by effectively and strictly restricting user operations based on the latest permissions. If a user is already logged in and their permissions are modified by a superior user during system use, resulting in the restriction or reduction of some permissions, and this modification is expected to take effect immediately, the method described in this disclosure allows the information system front-end to update user permissions in a timely manner, maximizing the reliability and security of access control.
[0238] The embodiments disclosed above reduce the complexity of user operations: unlike related technical systems, users are not required to log out and log back in to use the latest permissions. Users can operate seamlessly and use the latest permissions promptly in the method described in this application. The advantages of this disclosure are particularly pronounced when user role permissions are expanded.
[0239] The embodiments described above reduce the workload of developers: when role permissions change, developers do not need to manually modify the code.
[0240] The present disclosure will now be described through specific embodiments.
[0241] First type of embodiment
[0242] In this type of embodiment, the relationship between users and permissions is configured.
[0243] According to the permission management method disclosed herein, when a new user is added to the system, a corresponding role is selected for the user, and the permissions required for that role are configured. Role permissions can be modified through a visual checkbox on the page; in the permission configuration module, users can select menu permissions and button permissions.
[0244] The permission configuration module also includes menu data management and button data management units. These two data management units configure the metadata for relevant permissions, including information such as route name, route component, route icon, route path, and button value name.
[0245] Second type of embodiment
[0246] This embodiment describes the front-end implementation process of this access control method. It can be implemented using any JavaScript-based front-end framework; this embodiment uses the Vue framework as an example.
[0247] Users log in to the system after verifying their account and password. The system checks whether the user's basic information and permission information exist in the cache or state management library. If not, the system retrieves the user's basic information and permission information through an interface. The user permission information includes user menu permission data, button permission data, and permission duration.
[0248] The obtained permission information's routes undergo data format conversion. Using the `filterAsyncRouter()` method, a recursive approach is employed to convert the permission data strings into component objects that meet system requirements, serving as the dynamic routing data for the next step. For button permission data, it is converted into a `permission_btn` array. The route interceptor `router.beforeEach()` checks for the existence of local route data at each hop. The processed dynamic route data and some pre-set local default route data are then merged using the `addRoutes()` method into the final permission route data `permission_router`, which is stored in the relevant state management library.
[0249] The `permission_router` data is looped through using a JS-based front-end framework and dynamically rendered. Parameters can be added for custom routing requirements. A `$_has` method is added to determine if the required permission for a button exists in the `permission_btn` data, and this method is mounted to the prototype for subsequent calls. A `directive.js` file is created, using `.directive()` to create a `v-has` directive, which is called in the `$_has` method mounted to the prototype during the `inserted` child hook. The `v-has` directive can be used globally by including the `directive.js` file in the main file. Adding the `v-has` directive to buttons requiring permission control will display the corresponding permission button based on the `permission_btn` data. When a user makes a network request, the first permission time from the local cache or state management library is sent to the server.
[0250] The client-side UI rendering module determines whether permissions have changed and performs corresponding rendering. If the permission time field in the response is "Modified", the user's permissions have changed, and the UI is re-rendered using the permission data in the response. Otherwise, the user's permissions have not changed, and the user request rendering is completed.
[0251] Third type of embodiment
[0252] This type of embodiment is a client-side implementation of the access control method.
[0253] When adding a new role, in the permission configuration module, select the menu permissions and button permissions that the current role has. Simultaneously, based on the above permission data, generate the permission time based on this permission, and store the permission information and permission time in the database.
[0254] When a role's permissions are modified, a new permission time needs to be generated based on the latest permission configuration time and updated in the database.
[0255] After receiving the client's request, the server compares the first permission time carried in the request with the second permission time in the database.
[0256] a) If the two are the same, it proves that the permissions have not changed, and the server returns the requested data and sets the permission time field to empty.
[0257] b) If the two are different, it proves that the permissions have changed, and the server returns the most accurate result.
[0258] New permission data, and set the permission time field to "Modified".
[0259] Fourth type of embodiment
[0260] This type of embodiment compares the first permission time and the second permission time.
[0261] In this disclosure, when adding a new role, the menu and button permissions for the current role are selected in the permission configuration module. Simultaneously, based on the above permission data, a configuration time for this permission is generated, and the permission information and permission time are stored in the database. Depending on project requirements, a specific method or database can be used to generate a 13-digit timestamp "1663653983001" for this operation. This permission time is returned to the client in encrypted form; the encryption method is not limited. An example string transmitted is "C86A48C43A47C335F80AAA278C2C6C8B". The client caches this initial permission time and carries it in subsequent network requests.
[0262] In this disclosure, if a user's permissions change, the server generates a newly created 13-digit timestamp "1663671983000" as the second permission time, which is then stored and encrypted. The encryption method is not limited; for example, the stored second permission time is "0F55658BACD51F231962450AAEC84497". Upon receiving the client request, the server compares the first permission time "C86A48C43A47C335F80AAA278C2C6C8B" with the second permission time "0F55658BACD51F231962450AAEC84497". If they are different, it indicates a change in permissions. The server then returns the latest permission data and sets the permission time field to "Modified".
[0263] The embodiments described above use permission setting time values for comparison. Compared with the hash values (SHA256 or MD5) used in previous related technologies, no additional calculation by the server is required, which improves performance and efficiency and reduces server pressure.
[0264] In the above embodiments of this disclosure, the comparison of the first permission time and the second permission time is performed on the server side. This can minimize the risk of inaccurate comparison results due to malicious modification of permission times by users on the client side, which could prevent the system from updating permissions and causing security impacts. The reliability of server-side verification and comparison is better than client-side verification and comparison, while allowing the client to focus on rendering the interface.
[0265] In the embodiments described above, the client can directly obtain the latest permission information without resending the request. Upon receiving the response, the client determines the permission change through the permission time field. Since the permission time comparison occurs on the server side, the client does not need to resend a request to the server to obtain permissions; it can directly re-render based on the value in the server's response, reducing the number of network requests compared to related technologies.
[0266] Figure 8 These are schematic diagrams illustrating some embodiments of the client-side implementation of this disclosure. For example... Figure 8 As shown, the client disclosed herein may include an information acquisition module 81, an information caching module 82, an interface rendering module 83, an operation request sending module 84, and a response data receiving module 85, wherein:
[0267] The information acquisition module 81 is configured to acquire basic user information and permission information from the server when the user logs into the system. The permission information includes the first permission time.
[0268] In some embodiments of this disclosure, the permission information further includes menu permission data and button permission data.
[0269] Information caching module 82 is configured to cache permission information on the client side.
[0270] The interface rendering module 83 is configured to render the client interface based on permission information.
[0271] In some embodiments of this disclosure, the interface rendering module 83 is configured to convert the menu permission data and button permission data into data formats, including: converting the menu permission data into dynamic routing data; merging the dynamic routing data and the local default routing data into total permission routing data; looping through the total permission routing data to generate a menu bar; and using a prototype mounting method to determine whether the button permission data contains the permissions required by the button, and dynamically rendering the permission button.
[0272] The operation request sending module 84 is configured to send an operation request to the server, wherein the operation request includes a first permission time so that the server can compare the first permission time with the second permission time in the database.
[0273] The response data receiving module 85 is configured to receive response data returned by the server, wherein the response data includes an authorization time field.
[0274] In some embodiments of this disclosure, the interface rendering module 83 is also configured to render the page based on the response data.
[0275] In some embodiments of this disclosure, the interface rendering module 83 can be configured to, after the client obtains user permission information, determine whether to re-render the interface using the permission data in the response based on the "Modified" value in the data responded by the server, so as to only display the menus and operations that the user has permission to.
[0276] In some embodiments of this disclosure, the interface rendering module 83 can be configured to clear the locally cached permission information and re-render the client interface with the new permission information when the permission time field is modified. The response data also includes the new permission information. When the first permission time and the second permission time in the database are different, the server sets the permission time field to modified, updates the permission information, and returns the response data to the client.
[0277] In some embodiments of this disclosure, the interface rendering module 83 can be configured to determine that the permission information has not been updated when the permission time field is empty, and to render the client interface according to the user request data. The response data also includes the user request data. If the first permission time and the second permission time in the database are the same, the server returns the response data to the client.
[0278] In some embodiments of this disclosure, such as Figure 8 As shown, the client may further include a permission configuration request module 86, wherein:
[0279] The permission configuration request module 86 is configured to receive the menu permissions and button permissions of the newly added role selected by the user; send the menu permissions and button permissions of the newly added role selected by the user to the server so that the server can configure the permissions and generate a second permission time based on the configuration time.
[0280] In some embodiments of this disclosure, such as Figure 8 As shown, the client may further include a permission modification request module 87, wherein:
[0281] The permission modification request module 87 is configured to send a role permission modification request to the server so that the server can modify the role permissions and update the second permission time according to the modified permission time.
[0282] In some embodiments of this disclosure, the client of this disclosure can be configured to execute an implementation as described in any of the embodiments above (e.g. Figure 1 , Figure 3 or Figure 4 The access control method described in the embodiment).
[0283] In the above embodiments of this disclosure, when user permissions are updated, the method of updating user permissions on the front end prevents users from maliciously tampering with data to avoid updates, eliminates the need for users to log out of the system, eliminates the need for clients to resend requests to obtain permissions, and replaces the overall permission data with permission time values.
[0284] The embodiments described above in this disclosure use the permission configuration modification time to represent complete permission information.
[0285] The embodiments described above can determine whether user permissions have changed based on the permission time value carried in the network request currently sent to the server.
[0286] In the above embodiments of this disclosure, the client permission information is the first permission time, and the latest server permission information is the second permission time. The first permission time and the second permission time are compared in the server permission verification module, thereby solving the problem that users can maliciously tamper with the local cache through the browser and bypass permission updates, which leads to the insecurity of comparison on the client side.
[0287] In the above embodiments of this disclosure, if the first permission time and the second permission time are different, the server directly returns the latest permission data to the client.
[0288] The client interface rendering module of the above embodiments of this disclosure can re-render the client interface using the latest permission data based on the "Modified" field in the permission time field of the response field.
[0289] The route rendering in the above embodiments of this disclosure combines the default route with the authorized route to generate a dynamic route.
[0290] The button rendering in the above embodiments of this disclosure is as follows: the button is determined by the prototype mounting method.
[0291] Figure 9 This is a schematic diagram illustrating the structure of some other embodiments of the client disclosed herein. For example... Figure 9 As shown, the client disclosed herein may include a client memory 91 and a client processor 92.
[0292] Client memory 91 is used to store instructions. Client processor 92 is coupled to client memory 91 and is configured to execute instructions based on the memory storage, as described in any of the above embodiments (e.g., Figure 1 , Figure 3 or Figure 4 The permission control method described in the example.
[0293] like Figure 9 As shown, the client also includes a client communication interface 93 for exchanging information with other devices. Additionally, the client includes a client bus 94, through which the client processor 92, client communication interface 93, and client memory 91 communicate with each other.
[0294] Client memory 91 may include high-speed RAM, and may also include non-volatile memory, such as at least one disk drive. Client memory 91 may also be a memory array. Client memory 91 may also be divided into blocks, and the blocks may be combined into virtual volumes according to certain rules.
[0295] Furthermore, the client processor 92 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present disclosure.
[0296] The embodiments disclosed above do not require manual user operation, do not require modification of front-end code, do not require the front-end to send additional requests to obtain user permissions, use permission time instead of permission data to reduce server performance consumption, prevent unauthorized users from intercepting the latest permission information and tampering with client data to skip permission update restrictions, render the front-end system in a timely manner based on the latest permissions, and improve security.
[0297] Figure 10These are schematic diagrams illustrating some embodiments of the server-side implementation of this disclosure. For example... Figure 10 As shown, the server disclosed herein may include an operation request receiving module 101 and a permission verification module 102, wherein:
[0298] The operation request receiving module 101 is configured to receive operation requests sent by the client. The operation request includes a first permission time, which is included in the permission information. The user basic information and permission information are obtained from the server and cached on the client when the user logs into the system. The permission information is used to render the client interface.
[0299] In some embodiments of this disclosure, the permission information may further include menu permission data and button permission data.
[0300] The permission verification module 102 is configured to compare the first permission time with the second permission time in the database; and return corresponding response data to the client based on whether the first permission time and the second permission time are the same, so that the client can render the page based on the response data.
[0301] In some embodiments of this disclosure, the permission verification module 102 can be configured to compare the first permission time and the second permission time, and return the corresponding data or the user's latest permission data to the client.
[0302] In some embodiments of this disclosure, the permission verification module 102 can be configured to set the permission time field to "modified" and update the permission information when the first permission time and the second permission time in the database are different, and return response data to the client. The response data includes the user's new permission information and the permission time field, so that the client can clear the locally cached permission information and re-render the client interface with the new permission information.
[0303] In some embodiments of this disclosure, the permission verification module 102 can be configured to set the permission time field to empty and return response data to the client when the first permission time and the second permission time in the database are the same. The response data includes user request data and the permission time field, so that the client can render the client interface according to the user request data.
[0304] In some embodiments of this disclosure, such as Figure 10 As shown, the server disclosed herein may include a permission configuration module 103 and a permission generation module 104, wherein:
[0305] The permission configuration module 103 is configured to receive the menu permissions and button permissions of the newly added role selected by the user from the client; and to configure permissions according to the menu permissions and button permissions of the newly added role selected by the user.
[0306] The permission generation module 104 is configured to generate a second permission time based on the configuration time and store it in the database.
[0307] In some embodiments of this disclosure, the permission configuration module 103 may also be configured to receive a role permission modification request sent by the client and modify the role permissions according to the role permission modification request.
[0308] In some embodiments of this disclosure, the permission generation module 104 may also be configured to update the second permission time based on the modified permission time.
[0309] In some embodiments of this disclosure, the permission configuration module 103 can also be used to configure permissions corresponding to roles, including menu permissions and button permissions. After configuration, a role-permission table is formed. Simultaneously, the permission configuration module also includes menu data management and button data management units. In these two data management units, metadata related to the permissions is configured, including information such as route name, route component, route icon, route path, and button value name.
[0310] In some embodiments of this disclosure, the permission generation module 104 can also be configured to generate permission times for role permissions, including a first permission time and a second permission time. Each time a role permission is configured or modified, this module updates the permission information corresponding to the second permission time in the database.
[0311] In some embodiments of this disclosure, the server-side implementation of this disclosure can be configured to execute any of the embodiments described above (e.g., Figure 5 or Figure 6 The access control method described in the embodiment).
[0312] The embodiments disclosed above do not require the user to exit the system or perform other manual operations. The user operates seamlessly, and the permission control system can render and control according to the latest permissions, thereby improving the user experience.
[0313] The access control system described in the above embodiments of this disclosure can promptly restrict access based on the latest permissions, thereby increasing system security.
[0314] The embodiments disclosed above do not require manual code modification every time permissions are changed, eliminating the need for hard coding and reducing the workload of developers.
[0315] The embodiments disclosed above do not require repeatedly maintaining or sending useless requests, and do not require maintaining long connections to consume resources, thus optimizing performance.
[0316] In the embodiments described above, if the permission verification module detects a change in permissions, the client does not need to send an additional permission request.
[0317] Client-side caching is necessary, and the above embodiments of this disclosure can solve the security problems caused by users maliciously tampering with local caches and skipping permission updates.
[0318] Figure 11 This is a schematic diagram illustrating the structure of some other embodiments of the server-side software disclosed herein. For example... Figure 11 As shown, the server in this disclosure may include a server-side memory 111 and a server-side processor 112.
[0319] Server-side memory 111 is used to store instructions. Server-side processor 112 is coupled to server-side memory 111 and is configured to execute instructions based on the memory storage as described in any of the above embodiments (e.g., Figure 5 or Figure 6 The access control method described in the embodiment).
[0320] like Figure 11 As shown, the server also includes a server communication interface 113 for exchanging information with other devices. Additionally, the server includes a server bus 114, through which the server processor 112, server communication interface 113, and server memory 111 communicate with each other.
[0321] The server-side storage 111 may include high-speed RAM, and may also include non-volatile memory, such as at least one disk storage device. The server-side storage 111 may also be a memory array. The server-side storage 111 may also be divided into blocks, and these blocks may be combined into virtual volumes according to certain rules.
[0322] Furthermore, the server processor 112 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present disclosure.
[0323] Figure 7 Schematic diagrams of some embodiments of the access control system disclosed herein are also provided. For example... Figure 7 As shown, this disclosed access control system may include a client and a server, wherein:
[0324] The client can be any of the embodiments described above (e.g.) Figure 8 or Figure 9The client described in the example).
[0325] The server can be any of the embodiments described above (e.g.) Figure 10 or Figure 11 The server described in the example.
[0326] The above embodiments of this disclosure provide a method, apparatus and system for front-end and back-end separation of information system access control.
[0327] The embodiments described above belong to the field of IT (Information Technology) and computer software development.
[0328] The above embodiments of this disclosure propose a front-end and back-end separated information system permission control method and system. By visually configuring role permissions on the front end, dynamically rendering authorization menus and buttons on the interface, adding permission time values, and adding a comparative analysis module, the front end can achieve seamless and timely permission updates and interface rendering with better performance. This improves system security and ease of use. When permissions change, developers do not need to modify the code, avoiding security problems caused by users maliciously tampering with local cache information and skipping permission updates.
[0329] The above embodiments of this disclosure can be applied to all digital information management systems, regardless of the industry, and this access control method can be used for access control.
[0330] The embodiments disclosed above improve security, increase development efficiency, and enhance user experience.
[0331] The above-described embodiments of this disclosure effectively improve system security, enabling timely rendering of the front end based on the latest permissions, and enhancing the control of information system permissions.
[0332] The embodiments described above reduce the workload for developers, eliminating the need for hard coding.
[0333] The embodiments disclosed above improve the system's front-end rendering performance and optimize network requests.
[0334] The embodiments disclosed above reduce server load and improve performance.
[0335] According to another aspect of this disclosure, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores computer instructions that, when executed by a processor, implement any of the embodiments described above (e.g., Figures 1 to 7 The access control method described in any embodiment.
[0336] In some embodiments of this disclosure, the computer-readable storage medium may be a non-transitory computer-readable storage medium.
[0337] The embodiments disclosed above add new modules and processes to automatically compare, judge, push, and render, thereby completing access control.
[0338] The above embodiments of this disclosure introduce a permission time value to represent the permission configuration or modification time. Changes in the permission time value represent changes in permission data, which reduces the originally large amount of permission data and improves the performance of front-end rendering and back-end computing.
[0339] In the embodiments described above, if the server-side permission verification module finds that the permissions have changed, it will directly return the latest permission data without sending another request, allowing the front-end to focus on rendering.
[0340] The server-side permission comparison and verification in the above embodiments of this disclosure prevents users from tampering with browser data on the client side and thus circumventing permission restrictions.
[0341] The embodiments disclosed above significantly reduce the system computation during the permission comparison process and minimize the number of network requests required to update permissions, thereby improving network performance.
[0342] Those skilled in the art will understand that embodiments of this disclosure can be provided as methods, apparatus, or computer program products. Therefore, this disclosure can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this disclosure can take the form of a computer program product embodied on one or more computer-usable non-transitory storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0343] This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0344] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0345] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0346] The server, client, information acquisition module, information caching module, interface rendering module, operation request sending module, response data receiving module, permission configuration request module, permission modification request module, operation request receiving module, permission verification module, permission configuration module, and permission generation module described above can be implemented as a general-purpose processor, programmable logic controller (PLC), digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, or any suitable combination thereof for performing the functions described in this application.
[0347] This concludes the detailed description of the present disclosure. To avoid obscuring the concept of the disclosure, some details known in the art have not been described. Those skilled in the art will fully understand how to implement the technical solutions disclosed herein based on the above description.
[0348] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware, or by a program instructing the relevant hardware to implement them. The program can be stored in a non-transitory computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.
[0349] The description in this disclosure is provided for illustrative and descriptive purposes only and is not intended to be exhaustive or to limit the disclosure to its forms. Many modifications and variations will be apparent to those skilled in the art. The embodiments were chosen and described in order to better illustrate the principles and practical application of this disclosure and to enable those skilled in the art to understand this disclosure and to design various embodiments with various modifications suitable for a particular purpose.
Claims
1. An access control method, comprising: When a user logs into the system, the system obtains the user's basic information and permission information from the server. The permission information includes the first permission time, and also includes menu permission data and button permission data. Cache permission information on the client side; Rendering the client interface based on permission information, wherein rendering the client interface based on permission information includes: converting the menu permission data and button permission data into data formats, including: converting the menu permission data into dynamic route data; merging the dynamic route data and the local default route data into total permission route data; looping through the total permission route data to generate a menu bar; using a prototype mounting method to determine whether the button permission data contains the permissions required by the button, and dynamically rendering the permission button; Send an operation request to the server, wherein the operation request includes a first permission time, so that the server can compare the first permission time with the second permission time in the database; The server receives response data, which includes a permission time field and new permission information. If the first permission time and the second permission time in the database are different, the server sets the permission time field to "modified", updates the permission information, and returns response data to the client. The page is rendered based on the response data.
2. The access control method according to claim 1, wherein, The step of rendering the page based on the response data includes: If the permission time field has been modified, clear the locally cached permission information and re-render the client interface using the new permission information.
3. The access control method according to claim 1, wherein, The step of rendering the page based on the response data includes: If the permission time field is empty, it is determined that the permission information has not been updated. The client interface is rendered according to the user request data. The response data also includes the user request data. If the first permission time and the second permission time in the database are the same, the server returns the response data to the client.
4. The access control method according to any one of claims 1-3 further includes: Receive menu and button permissions for the newly added role selected by the user; The menu and button permissions of the newly added role selected by the user are sent to the server so that the server can configure the permissions and generate a second permission time based on the configuration time.
5. The access control method according to any one of claims 1-3 further includes: Send a role permission modification request to the server so that the server can modify the role permissions and update the second permission time according to the modified permission time.
6. An access control method, comprising: The system receives an operation request sent by a client. The operation request includes a first permission time, which is included in permission information. The user's basic information and permission information are obtained from the server and cached on the client when the user logs into the system. The permission information is used to render the client interface. Rendering the client interface includes: converting menu permission data and button permission data into different data formats, including: converting menu permission data into dynamic routing data; merging dynamic routing data and local default routing data into total permission routing data; looping through the total permission routing data to generate a menu bar; and using a prototype mounting method to determine whether the button permission data contains the required permissions for the button, and dynamically rendering the permission button. Compare the first permission time with the second permission time in the database; Based on whether the first permission time and the second permission time are the same, corresponding response data is returned to the client so that the client can render the page according to the response data. The step of returning corresponding response data to the client based on whether the first permission time and the second permission time are the same includes: if the first permission time and the second permission time in the database are different, setting the permission time field to "modified", updating the permission information, and returning response data to the client. The response data includes the user's new permission information and the permission time field.
7. The access control method according to claim 6, wherein, If the permission time field has been modified, the client clears the locally cached permission information and re-renders the client interface using the new permission information.
8. The access control method according to claim 6, wherein, The step of returning corresponding response data to the client based on whether the first permission time and the second permission time are the same includes: If the first permission time and the second permission time in the database are the same, the permission time field is set to empty, and response data is returned to the client. The response data includes user request data and the permission time field, so that the client can render the client interface according to the user request data.
9. The access control method according to any one of claims 6-8, wherein, The permission information also includes menu permission data and button permission data.
10. The access control method according to any one of claims 6-8, further comprising: Receive menu permissions and button permissions for the newly added role sent by the client and selected by the user; Configure permissions based on the menu and button permissions of the newly added role selected by the user; Based on the configured time, a second permission time is generated and stored in the database.
11. The access control method according to any one of claims 6-8, further comprising: Receive role permission modification requests sent by clients; Modify role permissions according to the aforementioned role permission modification request; Update the second permission time based on the modified permission time.
12. A client, comprising: The information acquisition module is configured to acquire basic user information and permission information from the server when the user logs into the system. The permission information includes a first permission time and also includes menu permission data and button permission data. The information caching module is configured to cache permission information on the client side. The interface rendering module is configured to render the client interface based on permission information. This rendering includes: converting menu permission data and button permission data into different data formats, including: converting menu permission data into dynamic route data; merging the dynamic route data and local default route data into total permission route data; looping through the total permission route data to generate a menu bar; and using a prototype mounting method to determine if the button permission data contains the required permissions for the button, and dynamically rendering the permitted buttons. The operation request sending module is configured to send an operation request to the server, wherein the operation request includes a first permission time so that the server can compare the first permission time with the second permission time in the database; The response data receiving module is configured to receive response data returned by the server. The response data includes a permission time field and new permission information. If the first permission time and the second permission time in the database are different, the server sets the permission time field to "modified", updates the permission information, and returns the response data to the client. The interface rendering module is also configured to render the page based on the response data.
13. A client, comprising: The client-side memory is configured to store instructions; A client processor is configured to execute the instructions, causing the client to perform operations that implement the access control method as described in any one of claims 1-5.
14. A server, comprising: The operation request receiving module is configured to receive operation requests sent by the client. The operation request includes a first permission time, which is included in permission information. The user's basic information and permission information are obtained from the server and cached on the client when the user logs into the system. The permission information is used to render the client interface. Rendering the client interface includes: converting menu permission data and button permission data into data formats, including: converting menu permission data into dynamic routing data; merging dynamic routing data and local default routing data into total permission routing data; looping through the total permission routing data to generate a menu bar; and using a prototype mounting method to determine whether the button permission data contains the required permissions for the button, and dynamically rendering the permission button. The permission verification module is configured to compare a first permission time with a second permission time in the database; and return corresponding response data to the client based on whether the first permission time and the second permission time are the same, so that the client can render the page based on the response data. The step of returning corresponding response data to the client based on whether the first permission time and the second permission time are the same includes: if the first permission time and the second permission time in the database are not the same, setting the permission time field to "modified", updating the permission information, and returning response data to the client. The response data includes the user's new permission information and the permission time field.
15. A server, comprising: The server-side storage is configured to store instructions; A server-side processor is configured to execute the instructions, causing the server to perform operations that implement the access control method as described in any one of claims 6-11.
16. An access control system, comprising a client as described in claim 12 or 13 and a server as described in claim 14 or 15.
17. A computer-readable storage medium, wherein, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement the access control method as described in any one of claims 1-11.