Page access permission control method, control device, control system and storage medium

Abstract

The application relates to a page access permission control method, a control device, a control system and a storage medium. The method comprises the following steps: for a logged-in user, in the case that the user triggers a menu of a target page, determining, by a front end, whether a routing path of the target page is located in permission data of the user cached by the front end; in the case that the routing path of the target page is located in the permission data of the user, sending, by the front end, a permission verification request containing an identity of the user and a routing name of the target page to a back end to obtain a verification result from the back end; and in the case that the verification result represents no access permission, intercepting, by the front end, the routing of the target page to stay in a current page, so that in the case that an administrator modifies permission data of the user stored in a database of the back end, page access permission changes can take effect in real time even if the user does not log in again. The method solves the problem that in the prior art, page access permission changes cannot take effect in real time without requiring the user to log in.

Description

Technical Field

[0001] This application relates to the field of page access permission control technology, and in particular to a page access permission control method, control device, control system and storage medium. Background Technology

[0002] Web (World Wide Web) application systems consist of a front-end and a back-end. Front-end access control is a core technology for ensuring the security and data isolation of web application systems. Traditional role-based access control (RBAC) is currently the most widely used front-end access control method.

[0003] The traditional role-based access control process is as follows: After a user logs in successfully, the front end retrieves the user's permission data from the back end and caches the user's permission data on the front end. When the user triggers the page's menu (attempting to access the page), the front end verifies whether the user has permission to access the page based on the cached permission data. If the verification passes, the route is allowed to redirect and the page is rendered.

[0004] However, the above solution only retrieves and caches user permission data to the front end when a user logs in. Subsequently, if the user does not log in again, the front end will not actively fetch the latest user permission data from the back end. Therefore, when the administrator updates the user's permission data on the back end (such as revoking access permissions for a page), the permission data cached on the front end for logged-in users will not be refreshed accordingly. This means that even if a user's access permission to a certain page has been revoked, the user can still continue to access that page if they do not log in again. For example, in the scenario of revoking permissions upon employee departure, at 09:00, employee Zhang San logs in and obtains access to "Financial Reports". At 10:00, the administrator deletes Zhang San's account permissions on the back end. At 10:01, Zhang San can still access the "Financial Reports" page normally (the permission data cached on the front end has not expired). At 10:30, Zhang San continues to download financial data (there is a risk of data leakage).

[0005] In summary, existing technologies cannot achieve real-time effectiveness of page access permission changes without requiring user login, posing a risk of data leakage. Summary of the Invention

[0006] This application provides a page access permission control method, a page access permission control device, a page access permission control system, and a computer-readable storage medium to solve the problem in the prior art that page access permission changes cannot take effect in real time without requiring user login.

[0007] Firstly, this application provides a page access permission control method applied to a front-end. The method includes: upon receiving a successful login receipt from a back-end, sending a permission acquisition request containing the user's identity identifier to the back-end to obtain the user's permission data from the back-end. The permission data includes a page permission list, which at least includes: the page's routing path and the page's routing name; if the user triggers a menu on a target page, determining whether the target page's routing path is within the user's permission data; if the target page's routing path is within the user's permission data, sending a permission verification request containing the user's identity identifier and the target page's routing name to the back-end to obtain a verification result from the back-end; if the verification result indicates that access is granted, allowing access to the target page's routing to redirect to the target page; if the verification result indicates that access is denied, blocking access to the target page's routing to remain on the current page.

[0008] Optionally, after sending a permission acquisition request containing the user's identity identifier to the backend, and before determining whether the routing path of the target page is located in the user's permission data, the method further includes: registering the routing path in the user's permission data to the routing list of the routing manager, so as to display the menu of the page to which the routing path in the user's permission data belongs.

[0009] Optionally, after allowing the route to the target page to redirect to the target page, the method further includes: when the user triggers the module of the target page, injecting the user's identity and the route name of the target page into the business request corresponding to the module, sending the business request to the backend, the backend being used to return a preset error code to the frontend if there is no access permission; upon receiving the preset error code, popping up a prompt window, and when the confirmation button in the prompt window is triggered, forcibly refreshing the page, sending another permission acquisition request containing the user's identity to the backend to obtain the user's permission data from the backend, and registering the route path in the user's permission data to the route list again.

[0010] Optionally, the page permission list includes: a module permission list for the page, wherein the module permission list includes at least: the name of the module and the permission identifier of the module, wherein the value of the permission identifier includes a third preset value indicating that there is operation permission and a fourth preset value indicating that there is no operation permission. Allowing the routing of the target page to jump to the target page includes: when the permission identifier of the module in the module permission list is the third preset value, controlling the module to be displayed on the target page and activating the function of the module on the target page; when the permission identifier of the module in the module permission list is the fourth preset value and the modifier of the module is the first preset modifier, controlling the module to be hidden on the target page; when the permission identifier of the module in the module permission list is the fourth preset value and the modifier of the module is the second preset modifier, controlling the module to be displayed and disabling the function of the module on the target page.

[0011] Secondly, this application provides a page access permission control method, which is applied to a backend. The method includes: upon receiving a permission acquisition request sent by the frontend, retrieving and returning the user's permission data from a database to the frontend based on the user's identity identifier in the permission acquisition request, the permission data including a page permission list, the page permission list including at least: the page's routing path and the page's routing permission identifier, the value of the permission identifier including a first preset value indicating permission access and a second preset value indicating no permission access; upon receiving a permission verification request sent by the frontend, determining whether the value of the target page's routing permission identifier in the user's permission data in the database is the first preset value, and determining whether the value of the target page's routing permission identifier in the user's permission data in the database is the second preset value, based on the user's identity identifier and the target page's routing name in the permission verification request; if the target page's routing permission identifier is the first preset value, returning a verification result indicating permission access to the frontend, and if the target page's routing permission identifier is the second preset value, returning a verification result indicating no permission access to the frontend.

[0012] Optionally, if the routing permission identifier of the target page is the first preset value, a verification result indicating access permission is returned to the front end; if the routing permission identifier of the target page is the second preset value, a verification result indicating no access permission is returned to the front end. The method then includes: upon receiving a service request from the front end, determining whether the value of the routing permission identifier of the target page in the user's permission data in the database is the second preset value based on the user's identity identifier and the route name of the target page in the service request; and if the routing permission identifier of the target page is the second preset value, returning a preset error code to the front end.

[0013] Optionally, the page permission list includes: a page identifier. After determining whether the value of the route permission identifier of the target page in the user's permission data in the database is the second preset value based on the user's identity identifier and the route name of the target page in the business request, the method further includes: generating an audit log. The audit log includes: the user's identity identifier, the page identifier in the user's permission data, the parameters of the business in the business request, the address of the interface receiving the business request, the IP address that initiated the business request, and the timestamp of receiving the business request. The parameters include: the identifier of the operation object and the operation type.

[0014] Thirdly, this application provides a page access permission control device applied to a front-end. The device includes: a first acquisition unit, configured to send an access permission request containing the user's identity identifier to the back-end upon receiving a successful login receipt from the back-end, to acquire the user's access permission data from the back-end. The access permission data includes a page access permission list, which at least includes the page's routing path and the page's routing name; a determination unit, configured to determine whether the routing path of the target page is located in the user's access permission data when the user triggers the menu of the target page; a first verification unit, configured to send an access permission verification request containing the user's identity identifier and the target page's routing name to the back-end when the target page's routing path is located in the user's access permission data, to acquire a verification result from the back-end; and a control unit, configured to allow the route of the target page to redirect to the target page when the verification result indicates that access is granted, and to block the route of the target page to remain on the current page when the verification result indicates that access is denied.

[0015] Fourthly, this application also provides a page access permission control system, the system comprising: a front-end, the front-end being configured to implement any of the page access permission control methods described above; and a back-end, the back-end being configured to implement the steps of any of the page access permission control methods described above.

[0016] Fifthly, this application also provides a computer-readable storage medium storing a permissioned computer program, which, when executed by a processor, implements the steps of any of the page access permission control methods described above.

[0017] In this embodiment, for logged-in users, when a user triggers the menu of the target page, the front-end determines whether the route path of the target page is located in the user's permission data cached on the front-end. If the route path is located in the user's permission data, the front-end sends a permission verification request containing the user's identity and the route name of the target page to the back-end to obtain the verification result. If the verification result indicates that the user has permission, the front-end allows the route to the target page to redirect to the target page. If the verification result indicates that the user does not have permission, the front-end blocks the route to the target page to remain on the current page. Thus, even if the user does not log in again, the page access permission change can take effect in real time if the administrator modifies the user's permission data stored in the back-end database. This solves the problem in the prior art that it is impossible to achieve real-time effect of page access permission changes without requiring the user to log in, and avoids the risk of data leakage. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0021] Figure 1 A flowchart illustrating a page access control method applied to the front end, provided as an embodiment of this application; Figure 2A flowchart illustrating a page access permission control method applied to the backend, provided as an embodiment of this application; Figure 3 A structural block diagram of a page access permission control device applied to a front end, provided in an embodiment of this application; Figure 4 This is a structural block diagram of a page access permission control device applied to the backend, provided as an embodiment of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] The following disclosure provides numerous different embodiments or examples for implementing various structures of the invention. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of the invention. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0024] The following are explanations of the terms used: Identity Token (qscToken): This is a unique authentication token generated by the backend for the user. It is used as the identity credential for all subsequent requests sent from the frontend to the backend. When the user enters their account and password on the login page, the frontend sends an authentication request containing the account and password to the backend. The backend verifies the validity of the account and password. If valid, the backend generates the user's identity token and returns it to the frontend along with the login success receipt.

[0025] The page menu is the visual navigation entry point for the page.

[0026] Route Manager: Only renders the menu of the page to which the route path in the route manager's route list belongs.

[0027] To address the technical problem that existing technologies cannot achieve real-time effectiveness of page access permission changes without requiring user login, this application provides a page access permission control method, a page access permission control device, a page access permission control system, and a computer-readable storage medium. These solutions resolve the issue of existing technologies being unable to achieve real-time effectiveness of page access permission changes without requiring user login, thus avoiding the risk of data leakage.

[0028] Figure 1 This application provides a page access permission control method, which is applied to the front end, such as... Figure 1 As shown, the above method includes: Step S101: Upon receiving a successful login receipt from the backend, send a permission acquisition request containing the user's identity identifier to the backend to obtain the user's permission data from the backend. The aforementioned permission data includes: a page permission list, which includes at least: the page's route path and the page's route name; For example, a user's login success receipt contains the user's identity identifier.

[0029] For example, the page permission list includes: the page name, the page route name (page identifier), the page route path, and the page route permission identifier. For example, as shown in Table 1, the name of the platform video review page is "Platform Video Review", the page route name is "VideoAudit", the page route path is "audit", and the page route permission identifier is "enable:1". Here, 1 is the value of the page permission identifier, indicating that the user has permission to access the platform video review page. The same applies to the video task allocation page.

[0030] Table 1

[0031] For example, the backend database stores user permission data bound to the user's identity identifier. When the backend receives a permission acquisition request sent by the frontend, it retrieves the user's permission data from the database and returns it to the frontend based on the user's identity identifier in the permission acquisition request.

[0032] Step S102: When the user triggers the menu of the target page, determine whether the routing path of the target page is located in the user's permission data. For example, when a user triggers the menu of the target page, that is, when the user clicks the menu of the target page, the menu of the target page is bound to the routing path of the target page. Therefore, when the user clicks the menu of the target page, the front end can obtain the routing path of the target page, and thus determine whether the routing path of the target page is in the user's permission data.

[0033] Step S103: If the routing path of the target page is located in the user's permission data, send a permission verification request containing the user's identity identifier and the routing name of the target page to the backend to obtain the verification result from the backend. For example, when the backend receives the permission verification request sent by the frontend, it determines whether the value of the route permission identifier of the target page in the user's permission data in the database is the first preset value, and whether the value of the route permission identifier of the target page in the user's permission data in the database is the second preset value, based on the user's identity identifier and the route name of the target page in the permission verification request. If the value of the route permission identifier of the target page in the user's permission data in the database is the first preset value, the backend returns a verification result indicating that the user has permission to access the device to the frontend; if the value of the route permission identifier of the target page in the user's permission data in the database is the second preset value, the backend returns a verification result indicating that the user does not have permission to access the device to the frontend. For example, the first preset value is 1 and the second preset value is 0.

[0034] For example, the route name of each target page in the database is bound to the route permission identifier of that target page. When the backend receives the permission verification request sent by the frontend, it can find the user's permission data in the database based on the user's identity identifier in the permission verification request, and find the route permission identifier of the target page from the user's permission data based on the route name of the target page in the permission verification request.

[0035] Step S104: If the verification result indicates that the user has access rights, allow the route to the target page to jump to the target page; if the verification result indicates that the user does not have access rights, block the route to the target page to stay on the current page.

[0036] For example, in the scenario of revoking permissions upon employee departure, the timeline is as follows: 09:30 - The administrator deletes Zhang San's access permissions for the platform video review page on the backend. The value of the permission identifier in Zhang San's permission data in the database is immediately updated (from the first preset value to the second preset value). 09:31 - Zhang San clicks the menu on the platform video review page. The frontend determines whether the route path of the platform video review page is located in the user's permission data cached on the frontend. If the route path of the video review page is located in Zhang San's permission data, the frontend sends a permission verification request to the backend containing Zhang San's identity identifier and the route name of the video review page. The backend, based on Zhang San's identity identifier, queries Zhang San's permission data from the database. Based on the route name of the platform video review page, it queries Zhang San's permission data in the database and finds that the route permission identifier of the platform video review page is the second preset value 0. It determines that Zhang San no longer has permission to access the platform video review page and returns a verification result indicating no access permission to the frontend. The frontend intercepts the route of the target page to stay on the current page. Zhang San does not need to log in again, and the permission change takes effect immediately, thereby further avoiding the risk of data leakage.

[0037] In the above embodiments, for logged-in users, when a user triggers the menu of the target page, the front-end determines whether the route path of the target page is located in the user's permission data cached on the front-end. If the route path of the target page is located in the user's permission data, the front-end sends a permission verification request containing the user's identity and the route name of the target page to the back-end to obtain the verification result. If the verification result indicates that the user has permission, the front-end allows the route to the target page to redirect to the target page. If the verification result indicates that the user does not have permission, the front-end blocks the route to the target page to remain on the current page. Thus, even if the administrator modifies the user's permission data stored in the back-end database, the page access permission change can take effect in real time, even if the user does not log in again. This solves the problem in the prior art that it is impossible to achieve real-time effect of page access permission changes without requiring the user to log in, and avoids the risk of data leakage.

[0038] In an optional embodiment, after step S101 and before step S102, the method further includes: Register the route path in the user's permission data to the route manager's route list to display the menu of the page to which the route path in the user's permission data belongs.

[0039] For example, since only the menus of pages whose routes belong to the route paths in the route manager's route list are displayed and seen by the user, registering the route paths in the user's permission data to the route manager's route list ensures that the front end only displays the menus of the pages whose route paths belong to the user's permission data. This prevents the user from seeing the menus of pages for which they do not have permission, thereby preventing the user from clicking on the menus of pages for which they do not have permission, and further preventing the user from accessing pages for which they do not have permission.

[0040] In an optional embodiment, after allowing the route to the target page in step S104 to redirect to the target page, the method further includes: When the aforementioned user triggers the module of the aforementioned target page, the user's identity and the route name of the aforementioned target page are injected into the business request corresponding to the aforementioned module, and the aforementioned business request is sent to the aforementioned backend. The aforementioned backend is used to return a preset error code to the aforementioned frontend in the absence of access rights. For example, a module can be a page element such as a button, input box, switch, or selector.

[0041] For example, when the backend receives a business request sent by the frontend, it determines whether the value of the route permission identifier of the target page in the user's permission data in the database is the second preset value based on the user's identity identifier and the route name of the target page in the business request; if the value of the route permission identifier of the target page in the user's permission data in the database is the second preset value, it returns a preset error code to the frontend.

[0042] For example, when the backend receives a business request from the frontend, it determines whether the value of the route permission identifier of the target page in the user's permission data in the database is a first preset value based on the user's identity identifier and the route name of the target page in the business request; if the value of the route permission identifier of the target page in the user's permission data in the database is the first preset value, the backend responds to the business request normally.

[0043] Upon receiving the aforementioned preset error code, a pop-up notification window appears. If the confirmation button in the pop-up window is triggered, the page is forcibly refreshed, and a permission request containing the aforementioned user's identity is sent to the backend again to obtain the aforementioned user's permission data from the backend. The routing path in the aforementioned user's permission data is then registered to the aforementioned routing list again.

[0044] For example, in a scenario where Zhang San's permissions change in real time while he is operating on the page, the timeline is as follows: 10:00 - Zhang San is reviewing a video on the platform's video review page, which has loaded normally. 10:15 - The administrator deletes Zhang San's access permissions for the platform's video review page in the backend. The value of the permission identifier in Zhang San's permission data in the database is immediately updated (from the first preset value to the second preset value), but the platform's video review page does not refresh. 10:16 - Zhang San clicks the "Approved" button on the platform's video review page. Zhang San's identity identifier and the route name of the platform's video review page are injected into the corresponding business request of the module. The business request is sent to the backend. The backend retrieves Zhang San's permission data from the database based on Zhang San's identity identifier and retrieves the platform's video review page from Zhang San's permission data in the database based on the route name of the platform's video review page. The page's route permission identifier is set to the second preset value of 0, indicating that Zhang San does not have permission to access the platform's video review page. A preset error code is returned to the front end. Upon receiving the preset error code, the front end displays a pop-up message: "Insufficient permissions, please refresh the page!" Zhang San clicks the "OK" button in the pop-up message to force a page refresh. After the page refreshes at 10:17, a permission request containing Zhang San's identity identifier is sent to the back end again to retrieve Zhang San's permission data. The route path in Zhang San's permission data is then registered in the route list again. Zhang San finds that he cannot see the menu of the platform's video review page. This ensures that even if Zhang San has entered the page, his access permissions are still controlled when he performs subsequent operations on the page. For example, if the preset error code is 4001, a forced page refresh will redirect to a page containing a menu, but this page does not contain the platform's video review menu.

[0045] For example, to ensure that permission changes take effect immediately after a user enters a page, when a user triggers a module on the target page, the user's identity and the route name of the target page are injected into the corresponding business request of the module. The business request is then sent to the backend, which returns a preset error code to the frontend if the user lacks access rights. Upon receiving the preset error code, a pop-up window appears. If the confirmation button in the pop-up window is triggered, the page is forcibly refreshed, and another permission request containing the user's identity is sent to the backend to retrieve the user's permission data. The route path in the user's permission data is then registered in the route list again, thus ensuring that permission changes take effect immediately after the user enters the page and further avoiding the risk of data leakage.

[0046] Existing technologies cannot control the operation permissions of modules within a page. To achieve operation permission control for modules within a page, in an optional embodiment, the page permission list includes: a module permission list for the page. The module permission list includes at least: the name of the module and a permission identifier of the module. The value of the permission identifier includes a third preset value indicating that the module has operation permissions and a fourth preset value indicating that the module does not have operation permissions. The step S104 of allowing the route to the target page to jump to the target page can be implemented as follows: When the permission identifier of a module in the above module permission list is set to the third preset value, the module is controlled to be displayed on the target page, and the function of the module is started on the target page. For example, the module can be a page element such as a button, input box, switch, selector, etc. If the permission identifier of the review button in the module permission list of the platform video review page is set to a third preset value, the button is controlled to be displayed on the platform video review page, and the function of the review button is activated on the platform video review page. For example, the third preset value is 1.

[0047] When the permission identifier of a module in the above module permission list is set to the fourth preset value and the modifier of the above module is the first preset modifier, the above module is controlled to be hidden on the above target page. For example, if the permission identifier of the review button in the module permission list of the platform video review page is a fourth preset value, and if the modifier of the review button is a first preset modifier, the review button is controlled to be hidden on the platform video review page, and the review button is not visible on the platform video review page. For example, the fourth preset value is 0, the first preset modifier is the show modifier, and the modifier of the above module can be located in the module permission list of the above target page.

[0048] If the permission identifier of a module in the above module permission list is set to the fourth preset value and the modifier of the above module is the second preset modifier, the display of the above module is controlled and the function of the above module is disabled on the above target page.

[0049] For example, if the permission identifier of the review button in the module permission list of the platform video review page is a fourth preset value, and the modifier of the review button is a second preset modifier, the review button is controlled to be displayed on the platform video review page, and the function of the review button is disabled on the platform video review page, that is, the review button is only visible and cannot be operated. For example, the fourth preset value is 0, and the second preset modifier is the disabled modifier.

[0050] For example, as shown in Table 2, compared to the page permission list in the prior art, this application adds a module permission list to the page permission list. The module permission list includes: the name of the module, the identifier of the module, and the permission identifier of the module. For example, the platform video review page includes: a review button, a view button, an export button, and an edit button. The identifier of the review button is AuditBtn, and the permission identifier of the review button is enable:1, where 1 indicates the value of the permission identifier of the review button, indicating that the review button is operable. According to the module permission list, the operation permission control of the modules within the page can be realized. Specifically, when the value of the permission identifier of the module in the module permission list is the third preset value, the module is controlled to be displayed on the target page, and the module's function is started on the target page. When the value of the permission identifier of the module in the module permission list is the fourth preset value and the modifier of the module is the first preset modifier, the module is controlled to be hidden on the target page. When the value of the permission identifier of the module in the module permission list is the fourth preset value and the modifier of the module is the second preset modifier, the module is controlled to be displayed, and the module's function is disabled on the target page, thereby realizing the operation permission control of the modules within the page.

[0051] Table 2

[0052] Figure 2 This application provides a page access permission control method, which is applied to a backend, such as... Figure 2 As shown, the above method includes: Step S201: Upon receiving the permission acquisition request sent by the aforementioned front-end, the user's permission data is retrieved from the database and returned to the aforementioned front-end based on the user's identity identifier in the permission acquisition request. The aforementioned permission data includes: a page permission list, which includes at least: the page's routing path and the page's routing permission identifier. The value of the permission identifier includes a first preset value indicating that the user has permission and a second preset value indicating that the user does not have permission. For example, upon receiving a successful login receipt from the backend, the frontend sends a permission acquisition request containing the user's identity identifier to the backend; if the user triggers the menu of the target page, the frontend determines whether the route path of the target page is in the user's permission data; if the route path of the target page is in the user's permission data, the frontend sends a permission verification request containing the user's identity identifier and the route name of the target page to the backend.

[0053] Step S202: Upon receiving the permission verification request sent by the front end, based on the user's identity identifier and the route name of the target page in the permission verification request, determine whether the value of the route permission identifier of the target page in the user's permission data in the database is the first preset value, and determine whether the value of the route permission identifier of the target page in the user's permission data in the database is the second preset value. In step S203, if the routing permission identifier of the target page is the first preset value, the verification result indicating that the user has access rights is returned to the front end; if the routing permission identifier of the target page is the second preset value, the verification result indicating that the user does not have access rights is returned to the front end.

[0054] For example, if the verification result indicates that the user has access rights, the front-end allows the route to the target page to redirect to the target page; if the verification result indicates that the user does not have access rights, the front-end blocks the route to the target page to remain on the current page.

[0055] In the above embodiments, for logged-in users, when a user triggers the menu of the target page, the front-end determines whether the route path of the target page is located in the user's permission data cached on the front-end. If the route path of the target page is located in the user's permission data, the front-end sends a permission verification request containing the user's identity and the route name of the target page to the back-end to obtain the verification result. If the verification result indicates that the user has permission, the front-end allows the route to the target page to redirect to the target page. If the verification result indicates that the user does not have permission, the front-end blocks the route to the target page to remain on the current page. Thus, even if the administrator modifies the user's permission data stored in the back-end database, the page access permission change can take effect in real time, even if the user does not log in again. This solves the problem in the prior art that it is impossible to achieve real-time effect of page access permission changes without requiring the user to log in, and avoids the risk of data leakage.

[0056] In an optional embodiment, after step S203, the method further includes: Upon receiving the aforementioned business request sent by the front end, based on the user's identity identifier and the route name of the target page in the aforementioned business request, determine whether the value of the route permission identifier of the target page in the user's permission data in the aforementioned database is the aforementioned second preset value. If the routing permission identifier of the target page is set to the second preset value, the preset error code will be returned to the front end.

[0057] For example, when the backend receives a business request from the frontend, it determines whether the value of the route permission identifier of the target page in the user's permission data in the database is a first preset value based on the user's identity identifier and the route name of the target page in the business request; if the value of the route permission identifier of the target page in the user's permission data in the database is the first preset value, the backend responds to the business request normally.

[0058] For example, when the aforementioned user triggers the module of the aforementioned target page, the front end injects the user's identity and the route name of the aforementioned target page into the business request corresponding to the aforementioned module, and the front end sends the aforementioned business request to the aforementioned back end.

[0059] For example, when the front end receives the aforementioned preset error code, the front end pops up a prompt window. When the confirmation button in the prompt window is triggered, the front end forces a page refresh and sends a permission acquisition request containing the identity identifier of the aforementioned user to the back end again in order to obtain the permission data of the aforementioned user from the back end. The front end then registers the route path in the permission data of the aforementioned user into the aforementioned route list.

[0060] The aforementioned page permission list includes: a page identifier. In an optional embodiment, after determining whether the value of the route permission identifier of the target page in the user's permission data in the database is the second preset value based on the user's identity identifier and the route name of the target page in the service request, the method further includes: Generate audit logs, which include: the user's identity identifier, the page identifier in the user's permission data, the parameters of the business in the business request, the address of the interface that receives the business request, the IP address that initiates the business request, and the timestamp of receiving the business request. The parameters include: the identifier of the operation object and the operation type.

[0061] For example, the business request includes the user's identity identifier, which is obtained from the business request. The business request also includes business parameters, including the identifier of the operation object and the operation type. For example, the operation object is a video, the identifier of the operation object can be id:123, and the operation type is delete. When the backend receives the business request, it records the address of the interface that received the business request, and obtains the IP address that initiated the business request from the business request. When the backend receives the business request, it records the time, which is the timestamp of receiving the business request. The audit log may also include the user's name and the name of the page in the user's permission data, which is obtained from the business request.

[0062] For example, existing audit logs only contain: the user's identity identifier, the address of the interface receiving the business request, and the business parameters contained in the business request. Therefore, it is only possible to determine which user made the business request based on the user's identity identifier, which interface the user initiated the business request to based on the address of the interface receiving the business request, and what kind of business operation was performed based on the business parameters contained in the business request. However, it is impossible to determine which page the business request originated from, the user's operation path, or whether it was a normal operation or an unauthorized operation. In addition to recording the user's identity identifier, the business parameters in the business request, and the address of the interface receiving the business request in the audit log, this application also records the timestamp of the business request (to determine the time when the business request was received), the page identifier in the user's permission data (to determine the page that initiated the business request), and the IP address that initiated the business request (to determine the device that initiated the business request, so as to reconstruct the user's operation path). Based on the user's identity identifier and the page identifier, the user's permission data can also be queried from the database to determine whether the user's operation was normal or illegal.

[0063] For example, in the prior art, if a video with ID 123 is illegally deleted, the audit logs in the prior art only show that a business request was received from the interface responsible for video deletion, but do not know which business process deleted it from, the user's operation path, or whether the user has permission to access this page. According to the audit logs of this application, based on the page identifier in the audit logs, it can be known that the video was deleted from the platform's video review page. Based on the user's identity identifier and the page identifier in the audit logs, it is possible to query from the database whether the user has permission to access the platform's video review. Based on the page identifier, the IP address that initiated the business request, and the address of the interface that received the business request in the audit logs, the user's operation path can be accurately reconstructed.

[0064] Figure 3 This application provides a page access permission control device, which is applied to a front-end, such as... Figure 3 As shown, the above-mentioned device includes: The first acquisition unit 300 is used to send an access request containing the user's identity identifier to the backend when it receives a successful login receipt from the backend, so as to obtain the user's access data from the backend. The aforementioned permission data includes: a page permission list, which includes at least: the page's route path and the page's route name; The determining unit 400 is used to determine whether the routing path of the target page is located in the user's permission data when the user triggers the menu of the target page. The first verification unit 500 is used to send a permission verification request containing the user's identity identifier and the route name of the target page to the backend when the route path of the target page is located in the user's permission data, so as to obtain the verification result from the backend. The control unit 600 is configured to allow the route to the target page to redirect to the target page if the verification result indicates that the user has access rights, and to block the route to the target page to remain on the current page if the verification result indicates that the user does not have access rights.

[0065] In the above embodiments, for logged-in users, when a user triggers the menu of the target page, the front-end determines whether the route path of the target page is located in the user's permission data cached on the front-end. If the route path of the target page is located in the user's permission data, the front-end sends a permission verification request containing the user's identity and the route name of the target page to the back-end to obtain the verification result. If the verification result indicates that the user has permission, the front-end allows the route to the target page to redirect to the target page. If the verification result indicates that the user does not have permission, the front-end blocks the route to the target page to remain on the current page. Thus, even if the administrator modifies the user's permission data stored in the back-end database, the page access permission change can take effect in real time, even if the user does not log in again. This solves the problem in the prior art that it is impossible to achieve real-time effect of page access permission changes without requiring the user to log in, and avoids the risk of data leakage.

[0066] In an optional embodiment, the above-described apparatus is further used for: Register the route path in the user's permission data to the route manager's route list to display the menu of the page to which the route path in the user's permission data belongs.

[0067] In an optional embodiment, the above-described apparatus is further used for: When the aforementioned user triggers the module of the aforementioned target page, the user's identity and the route name of the aforementioned target page are injected into the business request corresponding to the aforementioned module, and the aforementioned business request is sent to the aforementioned backend. The aforementioned backend is used to return a preset error code to the aforementioned frontend in the absence of access rights. Upon receiving the aforementioned preset error code, a pop-up notification window appears. If the confirmation button in the pop-up window is triggered, the page is forcibly refreshed, and a permission request containing the aforementioned user's identity is sent to the backend again to obtain the aforementioned user's permission data from the backend. The routing path in the aforementioned user's permission data is then registered to the aforementioned routing list again.

[0068] In an optional embodiment, the page permission list includes: a module permission list for the page, wherein the module permission list includes at least: the name of the module and a permission identifier of the module, wherein the value of the permission identifier includes a third preset value indicating that the user has operation permission and a fourth preset value indicating that the user does not have operation permission, and the control unit is used for: When the permission identifier of a module in the above module permission list is set to the third preset value, the module is controlled to be displayed on the target page, and the function of the module is started on the target page. When the permission identifier of a module in the above module permission list is set to the fourth preset value and the modifier of the above module is the first preset modifier, the above module is controlled to be hidden on the above target page. If the permission identifier of a module in the above module permission list is set to the fourth preset value and the modifier of the above module is the second preset modifier, the display of the above module is controlled and the function of the above module is disabled on the above target page.

[0069] Figure 4 This application provides a page access permission control method, in which the above-mentioned device applies a backend, such as... Figure 4 As shown, the above method includes: The second acquisition unit 700 is used to, upon receiving the permission acquisition request sent by the front end, retrieve and return the user's permission data from the database to the front end based on the user's identity identifier in the permission acquisition request. The permission data includes: a page permission list, which includes at least: the page's routing path and the page's routing permission identifier. The value of the permission identifier includes a first preset value indicating that the user has permission and a second preset value indicating that the user does not have permission. For example, upon receiving a successful login receipt from the backend, the frontend sends a permission acquisition request containing the user's identity identifier to the backend; if the user triggers the menu of the target page, the frontend determines whether the route path of the target page is in the user's permission data; if the route path of the target page is in the user's permission data, the frontend sends a permission verification request containing the user's identity identifier and the route name of the target page to the backend.

[0070] The second verification unit 800 is used to, upon receiving the permission verification request sent by the front end, determine whether the value of the route permission identifier of the target page in the permission data of the user in the permission data in the database is the first preset value, and determine whether the value of the route permission identifier of the target page in the permission data of the user in the database is the second preset value, based on the user's identity identifier and the route name of the target page in the permission verification request. The return unit 900 is used to return the verification result indicating that the user has access rights to the front end when the routing permission identifier of the target page is the first preset value, and to return the verification result indicating that the user does not have access rights to the front end when the routing permission identifier of the target page is the second preset value.

[0071] In the above embodiments, for logged-in users, when a user triggers the menu of the target page, the front-end determines whether the route path of the target page is located in the user's permission data cached on the front-end. If the route path of the target page is located in the user's permission data, the front-end sends a permission verification request containing the user's identity and the route name of the target page to the back-end to obtain the verification result. If the verification result indicates that the user has permission, the front-end allows the route to the target page to redirect to the target page. If the verification result indicates that the user does not have permission, the front-end blocks the route to the target page to remain on the current page. Thus, even if the administrator modifies the user's permission data stored in the back-end database, the page access permission change can take effect in real time, even if the user does not log in again. This solves the problem in the prior art that it is impossible to achieve real-time effect of page access permission changes without requiring the user to log in, and avoids the risk of data leakage.

[0072] In an optional embodiment, the above-described apparatus is further used for: Upon receiving the aforementioned business request sent by the front end, based on the user's identity identifier and the route name of the target page in the aforementioned business request, determine whether the value of the route permission identifier of the target page in the user's permission data in the aforementioned database is the aforementioned second preset value. If the routing permission identifier of the target page is set to the second preset value, the preset error code will be returned to the front end.

[0073] The aforementioned page permission list includes: the page identifier; in an optional embodiment, the aforementioned device is further used for: Generate audit logs, which include: the user's identity identifier, the page identifier in the user's permission data, the parameters of the business in the business request, the address of the interface that receives the business request, the IP address that initiates the business request, and the timestamp of receiving the business request. The parameters include: the identifier of the operation object and the operation type.

[0074] An embodiment of this application provides a page access permission control system, the system comprising: The front-end, as described above, is used to implement any of the aforementioned page access control methods; The backend is used to implement any of the above-mentioned page access control methods.

[0075] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the page access permission control method provided in any of the foregoing method embodiments.

[0076] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0077] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, or of course, using hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0078] It should be understood that the terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “described” as used herein may also include the plural forms. The terms “comprising,” “including,” “containing,” and “having” are inclusive and therefore indicate the presence of the stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or combinations thereof. The method steps, processes, and operations described herein are not construed as requiring them to be performed in a particular order described or illustrated unless the order of performance is explicitly indicated. It should also be understood that additional or alternative steps may be used.

[0079] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for controlling page access permissions, characterized in that, The method is applied to the front end, and the method includes: Upon receiving a successful login receipt from the backend, a permission acquisition request containing the user's identity identifier is sent to the backend to obtain the user's permission data from the backend. The permission data includes a page permission list, which at least includes the page's routing path and the page's routing name. When the user triggers the menu of the target page, determine whether the routing path of the target page is located in the user's permission data; If the routing path of the target page is located in the user's permission data, a permission verification request containing the user's identity identifier and the routing name of the target page is sent to the backend to obtain the verification result from the backend. If the verification result indicates that access is granted, the route to the target page is allowed to redirect to the target page; if the verification result indicates that access is denied, the route to the target page is blocked to remain on the current page.

2. The method according to claim 1, characterized in that, After sending a permission request containing the user's identity identifier to the backend, and before determining whether the routing path of the target page is located in the user's permission data, the method further includes: Register the routing path in the user's permission data to the routing list of the routing manager to display the menu of the page to which the routing path in the user's permission data belongs.

3. The method according to claim 2, characterized in that, After allowing the route to the target page to redirect to the target page, the method further includes: When the user triggers the module of the target page, the user's identity and the route name of the target page are injected into the business request corresponding to the module, and the business request is sent to the backend. The backend is used to return a preset error code to the frontend if the user does not have access rights. Upon receiving the preset error code, a pop-up notification window appears. If the confirmation button in the pop-up window is triggered, the page is forcibly refreshed, and a permission acquisition request containing the user's identity identifier is sent to the backend again to obtain the user's permission data from the backend. The routing path in the user's permission data is then registered in the routing list again.

4. The method according to claim 1, characterized in that, The page permission list includes: a module permission list for the page, wherein the module permission list includes at least: the name of the module and a permission identifier of the module. The value of the permission identifier includes a third preset value indicating that the user has operation permission and a fourth preset value indicating that the user does not have operation permission. Allowing the routing of the target page to jump to the target page includes: When the permission identifier of a module in the module permission list is set to the third preset value, the module is controlled to be displayed on the target page, and the function of the module is activated on the target page. When the permission identifier of a module in the module permission list is set to the fourth preset value and the modifier of the module is the first preset modifier, the module is controlled to be hidden on the target page. If the permission identifier of a module in the module permission list is set to the fourth preset value and the modifier of the module is the second preset modifier, the module is controlled to be displayed and the function of the module is disabled on the target page.

5. A method for controlling page access permissions, characterized in that, The method is applied to the backend, and the method includes: Upon receiving a permission request from the front end, the system retrieves and returns the user's permission data from the database to the front end based on the user's identity identifier in the permission request. The permission data includes a page permission list, which at least includes the page's routing path and the page's routing permission identifier. The permission identifier has a first preset value indicating that the user has permission and a second preset value indicating that the user does not have permission. Upon receiving the permission verification request sent by the front end, based on the user's identity identifier and the route name of the target page in the permission verification request, it is determined whether the value of the route permission identifier of the target page in the user's permission data in the database is the first preset value, and whether the value of the route permission identifier of the target page in the user's permission data in the database is the second preset value. If the routing permission identifier of the target page is set to the first preset value, a verification result indicating that the user has access rights will be returned to the front end. If the routing permission identifier of the target page is set to the second preset value, a verification result indicating that the user does not have access rights will be returned to the front end.

6. The method according to claim 5, characterized in that, When the route permission identifier on the target page is set to the first preset value, a verification result indicating access permission is returned to the front end; when the route permission identifier on the target page is set to the second preset value, a verification result indicating no access permission is returned to the front end. The method then includes: Upon receiving a business request sent by the front end, based on the user's identity identifier and the route name of the target page in the business request, determine whether the value of the route permission identifier of the target page in the user's permission data in the database is the second preset value; If the routing permission identifier of the target page is set to the second preset value, a preset error code will be returned to the front end.

7. The method according to claim 6, characterized in that, The page permission list includes: a page identifier. After determining whether the value of the route permission identifier of the target page in the user's permission data in the database is the second preset value based on the user's identity identifier and the route name of the target page in the business request, the method further includes: Generate an audit log, which includes: the user's identity identifier, the page identifier in the user's permission data, the parameters of the business in the business request, the address of the interface receiving the business request, the IP address that initiated the business request, and the timestamp of receiving the business request. The parameters include: the identifier of the operation object and the operation type.

8. A page access permission control device, characterized in that, The device is applied to a front end, and the device includes: The first acquisition unit is used to send a permission acquisition request containing the user's identity identifier to the backend when it receives a successful login receipt from the backend, so as to obtain the user's permission data from the backend. The permission data includes a page permission list, which includes at least the page's routing path and the page's routing name. The determining unit is configured to determine whether the routing path of the target page is located in the user's permission data when the user triggers the menu of the target page; The first verification unit is used to send a permission verification request containing the user's identity identifier and the route name of the target page to the backend when the route path of the target page is located in the user's permission data, so as to obtain the verification result from the backend. The control unit is configured to allow the route to the target page to redirect to the target page if the verification result indicates that the user has access rights, and to block the route to the target page to remain on the current page if the verification result indicates that the user does not have access rights.

9. A page access permission control system, characterized in that, The system includes: The front-end is used to implement the page access control method as described in any one of claims 1 to 4; The backend is used to implement the steps of the page access control method as described in any one of claims 5 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a permission computer program, which, when executed by a processor, implements the steps of the page access permission control method as described in any one of claims 1 to 4, or implements the steps of the page access permission control method as described in any one of claims 5 to 7.

Images