Authority verification method based on interface button state and processing terminal
By using a permission verification method based on the state of interface buttons and leveraging automated scripts to generate and compare permission status tables, the problems of inaccurate permission verification and anomaly analysis are solved, thereby improving accuracy and user experience.
Patent Information
- Application Number
- CN202511488118.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-10-17
- Publication Date
- 2026-02-27
AI Technical Summary
Existing permission verification methods suffer from inconsistencies between preset rule tables and actual permissions, inability to dynamically update rules, and inability to perform anomaly analysis and location, resulting in inaccurate verification and a poor user experience.
By using the permission verification method based on the state of the interface buttons, an automated script is used to log in to the interface, locate permission controls, generate a permission status table, and update it in real time. The status table is compared to identify differences, and anomaly analysis and repair are performed.
It achieves accurate permission verification in a dynamically updated environment, can identify and locate anomalies of inconsistent verification, and improves the accuracy of permission verification and user experience.
Smart Images
Figure CN121580388A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer technology, specifically to a permission verification method and processing terminal based on the state of interface buttons. Background Technology
[0002] In the development of software and other computer systems, permission verification is a crucial step in ensuring system security. Traditional permission verification methods often rely on comparisons based on pre-defined permission rule tables. These methods have the following shortcomings: 1. There may be differences between the preset rule table and the actual permissions configured in the system. For example, if the permissions configured in the system are changed, the rule table may not be updated in time, resulting in the preset rule table being inconsistent with the permissions currently configured in the system, which will lead to inaccurate permission verification.
[0003] 2. The preset permission rule table is static and cannot adapt to scenarios with dynamic permission granting. This makes it impossible to adjust user permissions in real time according to business needs, and thus impossible to accurately verify permissions.
[0004] 3. The comparison based on the rule table can only verify whether permissions are granted. The verification result only includes logical results of "yes" and logical results of "no," meaning it can only verify whether permissions are granted. Verifications that result in "no permission" cannot be used for permission anomaly analysis and localization. If analysis and localization are required, manual intervention is necessary.
[0005] In summary, the existing permission verification still has some limitations, including the inability to dynamically update permissions leading to inaccurate verification and the inability to perform anomaly analysis and localization, resulting in a need to improve the user experience. Summary of the Invention
[0006] To address the shortcomings of existing technologies, the purpose of this invention is to provide a permission verification method and processing terminal based on the state of interface buttons, which can solve the problems described in the background art.
[0007] The technical solution to achieve the objective of this invention is: a permission verification method based on the state of interface buttons, comprising the following steps: Step 1: Obtain the permission IDs of each permission item control under the target interface logged in with the administrator role, and establish a mapping between the permission IDs and the predefined interface button controls of the target interface according to the preset mapping relationship, and form the mapping results into the first permission status table; Step 2: Obtain the interface buttons that require authentication login for each permission item control under the target interface with user role function, obtain the element attribute data of the interface buttons, and parse the visibility and availability of the interface buttons through the element attribute data, thereby collecting the visibility and availability status of the interface buttons, and generating a second permission status table by associating the collection results with the permission ID. Step 3: Compare the aligned first permission status table and the second permission status table, and determine the permission verification result based on the comparison result.
[0008] Furthermore, in step 1, the permission IDs of each permission item control under the target interface logged in with the administrator role are obtained. This is specifically implemented through the following steps: Configure a first automated script with administrator role functionality, and log in to the target interface based on the first automated script. After successful login, locate all controls with permission items on the target interface, and parse out the permission ID representing the permission of each control with permission items.
[0009] Furthermore, the locator of the automated testing framework is used to locate the container containing all permission items and the container elements within that container, thereby locating all controls with permission items.
[0010] Furthermore, the permission ID representing the permission of the permission item control is parsed out through the following steps: Within the located containers, find all container elements representing a single permission item. For each container element, obtain the permission name and permission identifier of the permission item represented by that container element, and use the permission identifier as the permission ID representing the permission.
[0011] Furthermore, after establishing a mapping between the permission ID and the predefined interface button controls on the target interface according to a preset mapping relationship, the mapping result is converted into a structured mapping result, thereby obtaining a structured first permission status table.
[0012] Furthermore, step 1 also includes: Listen for save operations on the target interface. When a save operation is detected, locate all controls on the target interface that have the required permissions. If the target interface has a permission change event notification interface, then subscribe to that interface to receive permission change information in real time through subscription. A polling strategy is adopted to periodically obtain permission configuration information from the administrator interface or permission configuration interface of the target interface.
[0013] Furthermore, in step 2, the interface buttons for logging in with authentication permissions for each permission item control under the target interface with user role functions are obtained. The specific implementation process includes the following steps: Configure a second automated script with user role functionality, and log in to the target interface based on the second automated script. After successful login, locate the interface button on the target interface that requires permission verification.
[0014] Furthermore, aligning the first permission status table and the second permission status table includes: establishing a one-to-one mapping relationship between the two permission status tables based on permission ID, consistency verification, and interface buttons, so that the first permission status table and the second permission status table for the same interface button under the same role can be placed together for comparison.
[0015] Furthermore, in step 3, when comparing the aligned first permission status table and the second permission status table and verifying that the permission items in the two permission status tables are inconsistent, the following steps are also included: Identify the types of discrepancies, including inconsistent visibility, inconsistent availability, and complete inconsistency. If visibility is inconsistent but availability is consistent, it is determined to be a front-end rendering logic error; if availability is inconsistent but visibility is consistent, it is determined to be a back-end permission synchronization issue. For issues identified as front-end problems, fix them by checking the visibility control logic of interface buttons; for issues identified as back-end problems, fix them by checking the synchronization update mechanism of permission configurations.
[0016] A processing terminal, comprising: Memory, used to store program instructions; A processor is configured to run the program instructions to perform the steps of the permission verification method based on the state of the interface buttons.
[0017] The beneficial effects of this invention are: This invention can still perform accurate permission verification under dynamic updates, and can also perform anomaly analysis and location on permission verification inconsistencies (i.e. verification failures), and provide repair suggestions based on the analysis results, thereby ensuring the accuracy of permission verification and improving the user experience. Attached Figure Description
[0018] Figure 1 This is a flowchart illustrating a preferred embodiment of the method of the present invention; Figure 2 This is a schematic diagram of the processing terminal. Detailed Implementation
[0019] The present invention will be further described below with reference to the accompanying drawings and specific embodiments: like Figure 1 As shown, a permission verification method based on the state of interface buttons includes the following steps: Step 1: Configure the first automated script with administrator role functionality, and log in to the target interface based on the first automated script. After successful login, locate all controls with permission items on the target interface, and parse out the permission ID representing the permission of each control with permission items. Establish a mapping between the permission ID and the predefined interface button controls on the target interface according to the preset mapping relationship, and form the first permission status table with the mapping result.
[0020] Understandably, configuring the administrator account and password on the first automation script will create a first automation script with administrator role functionality. The administrator role refers to a role that has all permissions for the target interface.
[0021] A first automated script can be written to simulate an administrator logging into the target interface. For example, it can simulate logging into a digital broadcasting system and complete authentication using the administrator's account and password. Upon successful login, the first automated script can automatically navigate to the target module containing permission-related items, such as role management or user management, and locate the controls with permission items within that module. After locating the control with permission items, the script parses the permission configuration control.
[0022] For example, when the permission control is an interface button with form checkboxes representing permissions, the locator of the automated testing framework can be used to find the container containing all permission items and the container elements within that container, thereby locating all controls with permission items.
[0023] The permission ID representing the permission of a permission item control can be obtained by parsing the following steps: Within the located containers, find all container elements representing a single permission item. For each container element, obtain the permission name and permission identifier of the permission item it represents, and use the permission identifier as the permission ID representing the permission. The permission identifier identifies the permission item, that is, it identifies the permission to which it belongs.
[0024] Among them, checkboxes (indicating that they are form check options) or switch controls are found through container elements.
[0025] For example, after mapping the permission IDs to predefined interface button controls on the target interface according to a preset mapping relationship, the mapping results are converted into structured mapping results, thereby obtaining a structured first permission status table. For example, it can be converted into a structured JSON first permission status table for individual income tax.
[0026] For example, in order to obtain permission configuration data in real time, that is, to obtain the latest permission configuration information after dynamic permission updates, the following steps are also included: Listen for the "save" operation on the target interface. When the "save" operation is detected, locate all controls with permissions on the target interface again.
[0027] If the target interface has a permission change event notification interface, then subscribe to that interface to obtain permission change information in real time through the subscription method.
[0028] A polling strategy is adopted to periodically obtain permission configuration information from the administrator interface or permission configuration interface of the target interface.
[0029] Step 2: Configure a second automated script with user role functionality. Log in to the target interface using this script. After successful login, locate the interface button on the target interface that requires permission verification and obtain its element attribute data. Parse the element attribute data to determine the visibility and availability of the interface button (i.e., permission control), thus collecting its visibility and availability status. Associate the collected results (visibility and availability status) with the permission ID, generating a second permission status table, which is then aligned with the first permission status table. The second permission status table represents the current actual permission status.
[0030] Understandably, by simply configuring the user account and password on the second automation script, a second automation script with user role functionality can be configured. A user role refers to a role that does not have administrator privileges but possesses permissions within a preset scope.
[0031] It is understandable that aligning the first permission status table and the second permission status table means that the two permission status tables establish a one-to-one mapping relationship based on permission ID, consistency verification, and interface buttons, so that the first permission status table and the second permission status table of the same interface button under the same role can be placed together for comparison.
[0032] To collect the visibility status of buttons on the interface, you can use the `is_displayed()` method to determine whether the button is visible; to collect the availability status of buttons on the interface, you can use the `is_enabled()` method to determine whether the button is enabled.
[0033] The `find_element()` method can be used to attempt to locate UI buttons and collect their element attribute data. If an exception is thrown, it indicates that the button does not exist. For exceptions, an explicit wait strategy can be used to ensure that the element is fully loaded before collecting its state attribute data.
[0034] Step 3: Compare the aligned first permission status table and the second permission status table to verify whether the permission items in the two permission status tables are consistent. If they are consistent, the permission verification passes; otherwise, the weight verification fails.
[0035] Furthermore, in step 3, when comparing the aligned first permission status table and the second permission status table, and verifying that the permission items in the two permission status tables are inconsistent, that is, when the permission verification fails, the following steps are also included: Identify the types of discrepancies, including visibility inconsistencies, usability inconsistencies, and complete inconsistencies. The Drools rule engine can be used for discrepancy type identification and analysis. For visibility, if the permission level of the interface button's function is higher than the user role's permission level, then the expectedVisible element of the interface button will be changed to false. For usability, if the user role does not have the necessary permissions, then the expectedVisible element of the interface button will also be changed to false.
[0036] If the permission configuration is not updated, the problem is identified as a backend issue on the target interface. If the frontend of the target interface does not correctly hide the interface buttons, the problem is identified as a frontend issue. Specifically, if visibility is inconsistent but availability is consistent, the problem is identified as a frontend rendering logic error; if availability is inconsistent but visibility is consistent, the problem is identified as a backend permission synchronization issue. Other situations are identified as other issues requiring further analysis.
[0037] For issues identified as front-end problems, they can be fixed by checking the visibility control logic of UI buttons, such as CSS hiding or DOM removal. For issues identified as back-end problems, they can be fixed by checking the synchronization update mechanism of permission configurations, such as cache invalidation policies.
[0038] To determine the reliability of the authorization verification result, a confidence score can be calculated to represent the level of confidence. Specifically, the Analytic Hierarchy Process (AHP) can be used to assign weights to the difference types and calculate the total risk and confidence score. For example, the confidence score can be calculated using the following formula:
[0039] For example, after performing step 3, the process also includes: Step 4: Connect to large internal or external language models (i.e., AI models) via API to further analyze permission differences through large language models.
[0040] For permission differential analysis using large language models, the permission status data and differential analysis results need to be formatted to form a text description suitable for input into the large language model. Then, the decision results, confidence levels, and analysis descriptions are extracted from the large language model's response and converted into structured JSON format.
[0041] This invention can still perform accurate permission verification under dynamic updates, and can also perform anomaly analysis and location for inconsistencies in permission verification (i.e., verification failure), and provide repair suggestions based on the analysis results, thereby ensuring the accuracy of permission verification and improving the user experience.
[0042] like Figure 2 As shown, the present invention also provides a processing terminal 100, which includes: Memory 101 is used to store program instructions; Processor 102 is configured to run the program instructions to perform the steps of the permission verification method based on the state of the interface buttons.
[0043] The embodiments disclosed in this specification are merely illustrative of one aspect of the invention, and the scope of protection of the invention is not limited to these embodiments. Any other functionally equivalent embodiments fall within the scope of protection of the invention. Those skilled in the art can make various other corresponding changes and modifications based on the technical solutions and concepts described above, and all such changes and modifications should fall within the scope of protection of the claims of this invention.
Claims
1. A permission verification method based on the state of interface buttons, characterized in that, Includes the following steps: Step 1: Obtain the permission IDs of each permission item control under the target interface logged in with the administrator role, and establish a mapping between the permission IDs and the predefined interface button controls of the target interface according to the preset mapping relationship, and form the mapping results into the first permission status table; Step 2: Obtain the interface buttons that require authentication login for each permission item control under the target interface with user role function, obtain the element attribute data of the interface buttons, and parse the visibility and availability of the interface buttons through the element attribute data, thereby collecting the visibility and availability status of the interface buttons, and generating a second permission status table by associating the collection results with the permission ID. Step 3: Compare the aligned first permission status table and the second permission status table, and determine the permission verification result based on the comparison result.
2. The permission verification method based on interface button state according to claim 1, characterized in that, In step 1, the permission IDs of each permission item control under the target interface logged in with the administrator role are obtained. This is specifically implemented through the following steps: Configure a first automated script with administrator role functionality, and log in to the target interface based on the first automated script. After successful login, locate all controls with permission items on the target interface, and parse out the permission ID representing the permission of each control with permission items.
3. The permission verification method based on interface button state according to claim 2, characterized in that, The locator of the automated testing framework locates the container containing all permission items and the container elements within that container, thereby locating all controls with permission items.
4. The permission verification method based on interface button state according to claim 3, characterized in that, The permission ID representing the permission of the permission item control is parsed out through the following steps: Within the located containers, find all container elements representing a single permission item. For each container element, obtain the permission name and permission identifier of the permission item represented by that container element, and use the permission identifier as the permission ID representing the permission.
5. The permission verification method based on interface button state according to claim 1, characterized in that, After establishing a mapping between the permission ID and the predefined interface button controls on the target interface according to the preset mapping relationship, the mapping result is converted into a structured mapping result, thereby obtaining a structured first permission status table.
6. The permission verification method based on interface button state according to claim 1, characterized in that, Step 1 also includes: Listen for save operations on the target interface. When a save operation is detected, locate all controls on the target interface that have the required permissions. If the target interface has a permission change event notification interface, then subscribe to that interface to receive permission change information in real time through subscription. A polling strategy is adopted to periodically obtain permission configuration information from the administrator interface or permission configuration interface of the target interface.
7. The permission verification method based on interface button state according to claim 1, characterized in that, In step 2, the interface buttons for logging in with authentication permissions are obtained from the permission items controls under the target interface with user role functions. The specific implementation process includes the following steps: Configure a second automated script with user role functionality, and log in to the target interface based on the second automated script. After successful login, locate the interface button on the target interface that requires permission verification.
8. The permission verification method based on interface button state according to claim 1, characterized in that, Aligning the first and second permission status tables involves establishing a one-to-one mapping relationship between the two permission status tables based on permission ID, consistency verification, and interface buttons, so that the first and second permission status tables for the same interface button under the same role can be placed together for comparison.
9. The permission verification method based on interface button state according to claim 1, characterized in that, In step 3, when comparing the aligned first permission status table and the second permission status table and verifying that the permission items in the two permission status tables are inconsistent, the following steps are also included: Identify the types of discrepancies, including inconsistent visibility, inconsistent availability, and complete inconsistency. If visibility is inconsistent but availability is consistent, it is determined to be a front-end rendering logic error; if availability is inconsistent but visibility is consistent, it is determined to be a back-end permission synchronization issue. For issues identified as front-end problems, fix them by checking the visibility control logic of interface buttons; for issues identified as back-end problems, fix them by checking the synchronization update mechanism of permission configurations.
10. A processing terminal, characterized in that, It includes: Memory, used to store program instructions; A processor for running the program instructions to perform the steps of the permission verification method based on the state of an interface button as described in any one of claims 1-9.