Application permission approval method and device, equipment, medium and program product

Abstract

The invention provides an application permission approval method, device and equipment, a medium and a program product, which can be applied to the field of privacy computing and the field of financial science and technology. The application permission approval method comprises the following steps: in response to a permission application of a target application submitted by a user through a first interactive interface, performing role verification on the permission application; under the condition that the role verification is passed, reading application associated data; wherein the application associated data is automatically and synchronously updated by periodically calling a cross-system interface; and based on the application association data, approving the permission application through an approval process strategy, and based on an approval result, performing application permission allocation on the user.

Description

Technical Field

[0001] This application relates to the fields of privacy computing and fintech, and more specifically to an application permission approval method, apparatus, device, medium, and program product. Background Technology

[0002] In the fintech sector, the efficiency and security of access control approvals directly impact business continuity and data security. Financial institutions' core systems (such as transaction settlement, customer credit reporting, and risk control decisions) involve sensitive data and fund operations. Therefore, ordinary users need to apply for specific application management permissions, and access control for ordinary users must be approved to ensure the security of the financial system.

[0003] Currently, when ordinary users apply for management permissions for specific applications, the authorization must be manually granted by operations and maintenance personnel on the management platform. The process relies on manual submission of work orders, review by operations and maintenance personnel, and backend configuration, involving switching between multiple systems. This has drawbacks such as low approval efficiency, rigid permission management, heavy operation and maintenance burden, and high risk of misoperation. Summary of the Invention

[0004] In view of the above problems, this application provides application permission approval methods, apparatus, devices, media and program products.

[0005] According to a first aspect of this application, an application permission approval method is provided, comprising: responding to a user submitting a permission request for a target application through a first interactive interface, performing role verification on the permission request; if the role verification is successful, reading application-related data; wherein the application-related data is automatically synchronized and updated by periodically calling a cross-system interface; and approving the permission request based on the application-related data through an approval process strategy, and allocating application permissions to the user based on the approval result.

[0006] According to an embodiment of this application, the step of performing role verification on the permission request includes: checking the user's role in the target application to determine the application status; and, if the application status is pending approval, verifying the user's role based on the permission request.

[0007] According to an embodiment of this application, checking the user's role in the target application to determine the application status includes: matching the user's role based on the authorized user information of the target application; if the role matching is successful, configuring the application status as authorized and prompting the user through the first interactive interface that no application information is required; and if the role matching fails, configuring the application status based on the permission approval record table.

[0008] According to an embodiment of this application, configuring the application status based on the permission approval record table includes: when the user's approval information exists in the permission approval record table, prompting the user with approval information through the first interactive interface; and when the user's approval information does not exist in the permission approval record table, generating an application record based on the permission application, writing the application record into the permission approval record table, and configuring the application status as pending approval.

[0009] According to an embodiment of this application, the step of verifying the user's role based on the permission request includes: querying the application role corresponding to the user based on a user role relationship table; and performing hierarchical verification of the application role.

[0010] According to an embodiment of this application, the approval process strategy includes: obtaining the approval operation submitted by the application administrator through a second interactive interface; and if the approval operation is an automatic operation, automatically approving the permission application based on the application-related data.

[0011] According to an embodiment of this application, the process of automatically synchronizing and updating the application-related data includes: calling the cross-system interface based on a scheduled task to obtain the full amount of application data through a pagination query mechanism; and incrementally updating the application-related data based on the full amount of application data.

[0012] According to an embodiment of this application, the step of allocating application permissions to the user based on the approval result includes: if the approval result is approval passed, inserting the identifier corresponding to the user into the permission association table, adding the application role corresponding to the user in the user role relationship table, and modifying the application status corresponding to the user in the permission approval record table.

[0013] A second aspect of this application provides an application permission approval device, comprising: a role verification module, configured to verify the role of the permission request submitted by a user through a first interactive interface; a data reading module, configured to read application-related data if the role verification is successful; wherein the application-related data is automatically synchronized and updated by periodically calling a cross-system interface; and an approval module, configured to approve the permission request based on the application-related data and an approval process strategy, and to allocate application permissions to the user based on the approval result.

[0014] A third aspect of this application provides an electronic device comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0015] A fourth aspect of this application also provides a computer-readable storage medium having a computer program or instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.

[0016] The fifth aspect of this application also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method.

[0017] In the embodiments of this application, user self-submission combined with role verification as a pre-screening measure, and application-related data updated synchronously across systems on a regular basis, are used to achieve automated approval and permission allocation through approval process strategies. This not only eliminates the cumbersome steps of manual work order processing and switching between multiple systems, but also shortens the user permission approval and allocation cycle, significantly reduces the investment of operation and maintenance manpower, and prevents unauthorized operations through accurate role verification and real-time consistent data, thus balancing approval efficiency and system security. Attached Figure Description

[0018] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0019] Figure 1 The illustrations depict application scenarios of the application permission approval method, apparatus, device, medium, and program product according to embodiments of this application.

[0020] Figure 2 A flowchart illustrating an application permission approval method according to an embodiment of this application is shown schematically.

[0021] Figure 3 This illustration schematically shows a role verification flowchart of an application permission approval method according to an embodiment of this application;

[0022] Figure 4 This illustration schematically shows a role verification flowchart of an application permission approval method according to an embodiment of this application;

[0023] Figure 5 This illustration schematically shows a flowchart of the permission approval method for application permissions according to an embodiment of this application;

[0024] Figure 6 This illustration schematically shows an approval system diagram of an application permission approval method according to an embodiment of this application;

[0025] Figure 7 This schematically illustrates a structural block diagram of an application permission approval device according to an embodiment of this application; and

[0026] Figure 8A block diagram schematically illustrates an electronic device suitable for implementing an application permission approval method according to an embodiment of this application. Detailed Implementation

[0027] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0028] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0029] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0030] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0031] Access control and fintech are deeply intertwined, with their efficiency and security directly impacting the quality of fintech implementation and risk control. Fintech is data-driven and intelligently collaborative, while access control is the fundamental defense for data security and business compliance. The current human-dominated access approval model contradicts the efficiency, intelligence, and proactive risk control requirements pursued by fintech.

[0032] The existing manual approval and authorization methods have the following drawbacks: (1) low efficiency: manual approval and authorization operations are time-consuming and cannot meet the real-time requirements; (2) rigid permission management: users cannot apply or check the progress on their own and need to communicate and confirm repeatedly; (3) heavy maintenance burden: permission changes require the full intervention of maintenance personnel, which can easily become a system bottleneck; (4) high risk of misoperation: manual operation may cause security risks of incorrect permission allocation.

[0033] In fintech scenarios, core businesses such as payment settlement, robo-advisory, and risk control modeling all rely on precise access control. The inefficiency of manual approval can easily lead to delayed business responses and missed market opportunities; rigid access management struggles to adapt to the rapidly evolving business needs of fintech, hindering product innovation; heavy operational burdens and high risks of misoperation can also trigger significant financial risks such as data loss and fund security breaches, contradicting the core logic of fintech empowering risk control. Therefore, leveraging fintech to automate and intelligently upgrade access approval is a crucial support for strengthening financial security and unlocking the value of technology.

[0034] It should be noted that the application permission approval method and device of this application can be used in the fields of privacy computing and fintech, as well as in any field other than privacy computing and fintech. The application fields of the application permission approval method and device of this application are not limited.

[0035] In the technical solution of this application, the user information (including but not limited to user personal information, user image information, user device information, such as location information) and data (including but not limited to data used for analysis, stored data, and displayed data) involved are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with relevant laws, regulations, and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0036] In scenarios where personal information is used for automated decision-making, the methods, devices, and systems provided in this application all provide users with corresponding operation entry points for users to choose to agree to or reject the automated decision results; if the user chooses to reject, the process enters the expert decision-making process.

[0037] This application provides an application permission approval method, comprising: responding to a user submitting a permission request for a target application through a first interactive interface, performing role verification on the permission request; if the role verification is successful, reading application-related data; wherein the application-related data is automatically updated through periodic calls to cross-system interfaces; and approving the permission request based on the application-related data using an approval process strategy, and allocating application permissions to the user based on the approval result. In this application's embodiments, by combining user self-submission with pre-screening through role verification, and combining periodically updated application-related data across systems, an approval process strategy is used to achieve automated approval and permission allocation. This eliminates the cumbersome steps of manual work order processing and multi-system switching, compresses the user permission approval and allocation cycle, significantly reduces maintenance manpower investment, and prevents unauthorized operations through accurate role verification and real-time consistent data, balancing approval efficiency and system security.

[0038] Figure 1 The illustration shows an application scenario diagram of the application permission approval method, apparatus, device, medium, and program product according to embodiments of this application.

[0039] like Figure 1 As shown, application scenario 100 according to this embodiment may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0040] Users can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 via the network 104 to receive or send messages, etc. Various communication client applications can be installed on the first terminal device 101, the second terminal device 102, and the third terminal device 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0041] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be various electronic devices with displays and support web browsing, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0042] Server 105 can be a server that provides various services, such as a backend management server that supports websites browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103 (this is just an example). The backend management server can analyze and process data such as received user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices.

[0043] It should be noted that the application permission approval method provided in this application embodiment can generally be executed by server 105. Correspondingly, the application permission approval device provided in this application embodiment can generally be located in server 105. The application permission approval method provided in this application embodiment can also be executed by a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105. Correspondingly, the application permission approval device provided in this application embodiment can also be located in a server or server cluster that is different from server 105 and capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105.

[0044] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0045] The following will be based on Figure 1 The described scene, through Figures 2-6 The application permission approval method according to the embodiments of this application will be described in detail.

[0046] Figure 2 A flowchart illustrating an application permission approval method according to an embodiment of this application is shown.

[0047] like Figure 2 As shown, the application permission approval method in this embodiment includes operations S210 to S230. This application permission approval method does not limit the specific executing entity. The executing entity can be any electronic device, such as a terminal device or a server device, etc. The executing entity can also be any software application or client.

[0048] In operation S210, in response to the user submitting a permission request for the target application through the first interactive interface, the permission request is verified by role.

[0049] Users submit corresponding permission requests on the first interactive interface (permission request) on the front end. The permission request includes the application identifier (ID), approval role, reason for request, and scope of permission.

[0050] The front-end interface transmits user-submitted permission requests (including application ID, approval role, and reason for request) to the back-end interface. Upon receiving the request, the back-end interface first verifies data integrity (checking for missing required fields like application ID and user ID), parses and extracts core parameters, encapsulates them into a unified data object, and uses the user's unique ID as a condition to perform role verification. It determines which role the user belongs to within the target application. Roles such as super administrator, application architect, and application user already possess the necessary permissions for the target application and do not require further permission requests; therefore, role verification fails, and the user is informed of their current role. For ordinary users of the target application, role verification passes, and the permission request process continues.

[0051] When operating S220, if the role verification is successful, read the application-related data; the application-related data is automatically synchronized and updated by periodically calling the cross-system interface.

[0052] After role verification is passed, the target application ID in the permission request is extracted. The query conditions for application-related data are determined, and the required data range (application architect information, authorization configuration, etc.) is defined. Using the target application ID as the core condition, a query is used to retrieve the local application architect association table (whose data is synchronously updated daily via a cross-system interface call by a scheduled task). The corresponding application-related data is read, including key information such as the relationship between the application architect and the application, and authorization rules. The retrieved application-related data is then returned to the permission request processing flow to provide data support for subsequent approval record generation and workflow driving, while ensuring the timeliness and accuracy of the data.

[0053] According to an embodiment of this application, the process of automatically synchronizing and updating application-related data includes: calling a cross-system interface based on a scheduled task to obtain the full amount of application data through a pagination query mechanism; and incrementally updating the application-related data based on the full amount of application data.

[0054] A daily scheduled task uses a paginated query mechanism to call an external system interface to retrieve the architect's full application data. The paginated query mechanism is designed with fault tolerance in mind, including retries up to 3 times if a single page query fails, and termination of the task if 10 consecutive pages fail, with re-execution the following day. During data updates: the local application architect association table is overwritten and updated; this table represents application-related data. It's worth noting that the local data table is shown in Table 1 below.

[0055] Table 1

[0056]

[0057] The process of automatic synchronization and update of application-related data is as follows: (1) Triggering scheduled tasks and executing paginated queries: Configure daily fixed execution tasks through the scheduled scheduling framework. After the task starts, obtain the external system interface address and pagination parameters (page size, starting page number) and start the pagination query process. Call the cross-system interface page by page to obtain application architect data, and enable the fault tolerance mechanism: trigger retry immediately when a single page query fails, and retry up to 3 times; if 10 pages of query fail consecutively, terminate the current synchronization task immediately, record the failure log and wait for automatic re-execution the next day to ensure task stability. (2) Data incremental update processing: Compare the obtained full remote data with the local application architect related table data, and filter out the new and modified difference data (incremental data) by using user ID and application ID as unique identifiers. Perform overwrite update operation on incremental data, first delete the old records in the local table that match the incremental data, and then insert or update the new data; do not process the existing data with no difference, and finally complete the incremental update of local application-related data, which not only ensures data consistency but also improves synchronization efficiency.

[0058] In the embodiments of this application, cross-system interface calls are driven by scheduled tasks, and full application data is obtained by paginated queries. Then, application-related data is synchronized through an incremental update mechanism. This avoids the resource consumption and data redundancy of full updates, ensures the real-time performance and consistency of data, and eliminates the need for manual data synchronization, providing accurate and reliable data support for automated approval.

[0059] When operating S230, based on application-related data, permission requests are approved through an approval process strategy, and application permissions are assigned to users based on the approval results.

[0060] The system extracts application-related data (application architect, backup approver, etc.) and permission application information, matches it with a preset approval process strategy, and allows application architects to choose whether to enable automatic approval. If the approval result is "approved," the system triggers the allocation of application permissions to the user. If the application architect performs a "reject" operation on the approval page (single or batch applications), or if automatic approval fails, the current approval result is "approved but not approved," and only the application record status is updated to "rejected," without triggering application permission allocation.

[0061] After approval, the system extracts the user ID and application ID, first inserts a user-application binding record into the permission association table, then grants the corresponding application role to the user role relationship table, and at the same time updates the permission approval record table status to "approved".

[0062] In the embodiments of this application, user self-submission combined with role verification as a pre-screening measure, and application-related data updated synchronously across systems on a regular basis, are used to achieve automated approval and permission allocation through approval process strategies. This not only eliminates the cumbersome steps of manual work order processing and switching between multiple systems, but also shortens the user permission approval and allocation cycle, significantly reduces the investment of operation and maintenance manpower, and prevents unauthorized operations through accurate role verification and real-time consistent data, thus balancing approval efficiency and system security.

[0063] Figure 3 The illustration shows a flowchart of the role verification process for the application permission approval method according to an embodiment of this application.

[0064] like Figure 3 As shown, in operation S210, the permission request is verified by role, which includes operations S310 to S320.

[0065] In operation S310, check the user's role in the target application to determine the application status.

[0066] According to an embodiment of this application, in operation S310, checking the user's role in the target application to determine the application status includes: matching the user's role based on the authorized user information of the target application; if the role matching is successful, configuring the application status as authorized and prompting the user through the first interactive interface that no application information is required; and if the role matching fails, configuring the application status based on the permission approval record table.

[0067] First, basic data is obtained for matching preparation. The user's unique ID and the target application ID are extracted. The full authorized user information of the target application (including roles such as architect and authorized user and their corresponding user IDs) is retrieved from the system's local database as the benchmark data for role matching.

[0068] Secondly, a role matching verification is performed, accurately matching the current user ID with the target application's authorized user information, verifying whether each user belongs to the application's architect or authorized user category. If the match is successful, the application status is directly configured as "authorized," and a pop-up window or text message "No application required" is displayed to the user through the first interactive interface, terminating the subsequent application process.

[0069] Finally, regarding the configuration of the application status after a mismatch, if the role mismatch occurs, it indicates that the user is not an authorized role for the target application. In this case, the permission approval record table is queried. If the table contains approval information for the user corresponding to the target application, the user is notified through the first interactive interface that an approval record already exists. If no corresponding approval information exists, an application record is generated based on the user's submitted permission application, written to the permission approval record table, and the application status is uniformly configured as "pending approval," thus completing the final setting of the application status.

[0070] In the embodiments of this application, pre-verification is achieved through role matching of the target application's authorization information. If the match is successful, a prompt is directly displayed indicating that no repeated application is needed, avoiding invalid processes. If the match fails, the status is configured based on the permission approval record table, ensuring that the status determination is based on evidence, thereby reducing redundant approval operations, improving the user application experience, and lowering the probability of misjudgment.

[0071] According to an embodiment of this application, configuring the application status based on the permission approval record table includes: if the user's approval information exists in the permission approval record table, prompting the user with the approval information through a first interactive interface; and if the user's approval information does not exist in the permission approval record table, generating an application record based on the permission application, writing the application record into the permission approval record table, and configuring the application status as pending approval.

[0072] To prevent duplicate applications, the system first obtains the user ID and target application ID. Using these two fields as the core query criteria, combined with status filtering (status = "Pending Approval"), it queries the permission approval record table via a selection statement. It first performs a duplicate application check. If a record with user ID + application ID + status = "Pending Approval" is found, the application is directly intercepted, and the user is notified "Approval in progress" through the first interactive interface. Application status is configured according to different scenarios. If no duplicate pending approval record is found, it continues to check if the user has other approval information for the corresponding application (regardless of status). If approval information exists, the approval status and other details of the record are extracted and displayed to the user through the first interactive interface. If no corresponding approval information exists, an application record is constructed based on the user's submitted permission application data (including user ID, application ID, application content, etc.), written to the permission approval record table, and the application status field of the record is uniformly configured as "Pending Approval". After the operation is completed, the configuration result (notification of existing approval / generation of pending approval record) is synchronously fed back to the front end to ensure that the user is aware of the process status in real time.

[0073] Figure 4 The illustration shows a role verification flowchart of an application permission approval method according to an embodiment of this application.

[0074] like Figure 4 As shown, if the user is already authorized, no application is required. If the user exists in the target application's permission approval record table (meaning the user is present in the target application's permission approval record table), and the application status is "Pending Approval," then "Approving" will be displayed. If the user does not exist in the target application's permission approval record table (meaning the user is not present in the target application's permission approval record table), for ordinary users, an application record will be directly generated based on the permission request, and the application record will be written to the permission approval record table, with the application status set to "Pending Approval."

[0075] In the embodiments of this application, the user application status is distinguished based on the permission approval record table. When a user exists in the table, the information that the application is under review is directly displayed to avoid repeated queries and operations. When there is no user information, the application record is automatically generated and written, and the pending approval status is configured. This not only achieves standardized and automated determination of the application status, reducing manual intervention, but also avoids duplicate applications.

[0076] When operating S320, if the application status is pending approval, the user's role is verified based on the permission request.

[0077] When the application status is "Pending Approval," the user's role is further verified. When the application status is not "Pending Approval," appropriate prompts are made. For example, if the application status is "Authorized," the user is informed that no application information is required; if the application status is "Under Review," the user is informed that the application is under review.

[0078] In the embodiments of this application, by first verifying the user's role in the target application to determine the application status, and then conducting role verification for the pending approval status, invalid applications are efficiently filtered out, redundant approval steps are reduced, and the access threshold for permission applications is accurately controlled.

[0079] According to an embodiment of this application, in operation S320, which verifies the user's role based on permission request, the steps include: querying the application role corresponding to the user based on the user role relationship table; and performing hierarchical verification of the application role.

[0080] Real-time query: Directly retrieve the user role relationship table by user ID to obtain a list of all role IDs. Layered verification is performed based on user roles and requested application permissions, with the following verification levels:

[0081] (1) Super Administrator: Has direct access to all applications.

[0082] (2) Application Architect: Check whether the user in the application architect association table is the person in charge of the target application. If a record exists, the application is blocked.

[0083] (3) Application users: Check if there is a record of binding user ID + application ID in the permission association table. If there is a valid record, the application will be blocked.

[0084] (4) Regular users: Applications are allowed (no prior verification required).

[0085] For example, firstly, obtain the current user's unique ID, query the user role relationship table in real time using a query statement, extract all role IDs corresponding to the user using the user ID as the query condition, form a user role set, and use it as the basic data for subsequent layered verification. The user roles are verified in layers according to the preset priority: (1) First, determine whether the role set contains the super administrator role. If it does, the verification is directly passed and the user does not need to apply for the application permission; (2) If the super administrator role does not exist, check whether it is the application architect role. Use a join statement to associate the user ID with the application architect association table and verify whether the user is the person in charge of the target application. If a record exists, the application is blocked; (3) If it is not the application architect, continue to verify whether it is the application user. Query whether there is a valid binding record between the user ID and the target application ID in the permission association table. If it exists, the application is blocked; (4) If none of the above roles match, it is determined to be an ordinary user, the verification is passed and the permission application is allowed to be submitted. The result of the layered verification (block / allow) is fed back to the front end, and the verification log is recorded synchronously.

[0086] In the embodiments of this application, the application role corresponding to the user is accurately queried based on the user role relationship table, and then permission verification is carried out through layered verification. Layered verification can verify the permission adaptability level by level according to the role level, avoiding the omissions of single verification. Combined with the accurate matching of the role relationship table, invalid applications can be screened out from the process and approval efficiency can be improved.

[0087] According to an embodiment of this application, the approval process strategy includes: obtaining the approval operation submitted by the application administrator through a second interactive interface; and if the approval operation is an automatic operation, automatically approving the permission application based on the application-related data.

[0088] Figure 5 The illustration shows a flowchart of the permission approval method for application permissions according to an embodiment of this application.

[0089] like Figure 5 As shown, application administrators (such as application architects) can view and process applications on the approval page (second interactive interface), supporting single or batch operations (approval / rejection). After approval, the user-application binding relationship is automatically written into the permission association table, and the user is granted the "application user" role.

[0090] Application architects can also select whether to automate approval on the approval page (second interaction interface). When auto-approval is enabled, the system automatically approves user applications based on application-related data. It also uses the human resources system to determine if the user is a subordinate of the corresponding application architect. If so, the application is automatically approved; otherwise, it can be manually approved. Alternatively, pre-defined rules can be used to automatically reject applications from non-subordinate users, with a notification on the first interaction interface stating, "Not a subordinate of the corresponding architect; application automatically rejected. Please contact the relevant person in charge." A timeout mechanism is also configured. If the current application architect fails to complete manual approval within the specified time limit, a resubmission or a secondary reminder is automatically triggered to prevent application backlog.

[0091] In the embodiments of this application, user applications and administrator configurations are distinguished through dual interactive interfaces, supporting both automatic and manual approval modes. When the approval operation is automatic, permission review is automatically completed based on synchronously updated application-related data, without the need for manual intervention, avoiding human error and balancing approval efficiency with the security of permission control.

[0092] According to an embodiment of this application, in operation S230, which allocates application permissions to a user based on the approval result, the following steps are included: if the approval result is "approved", the identifier corresponding to the user is inserted into the permission association table, the application role corresponding to the user is added to the user role relationship table, and the application status corresponding to the user is modified in the permission approval record table.

[0093] When an application architect clicks "Agree" on the approval page (for a single or batch application), or when the application is automatically approved, the current approval result is "Approved." This approval is then used as a trigger to assign application permissions to the approved user.

[0094] When assigning application permissions, firstly, user-application binding is performed: a record is inserted into the permission association table, such as (User ID, Application ID, "Application User"). Secondly, role granting is performed: roles are added to the user role relationship table, such as (User ID, "Application User"). Finally, the status is updated, changing the corresponding application status in the permission approval record table to "Approved".

[0095] For example, the system obtains the target user's unique identifier (User ID), associated application identifier (Application ID), confirms the preset role code ("Application User") and approval status value ("Agreed"), and simultaneously obtains the unique identifier of the approval record corresponding to the user. First, it inserts a record (User ID, Application ID, "Application User") into the permission association table using database operation execution statements to establish the binding relationship between the user and the application. Next, it adds a role record (User ID, "Application User") to the user role relationship table using database operation execution statements to complete the application role grant. Finally, it updates the status field of the corresponding record in the permission approval record table to "Agreed" using an update statement, based on the User ID and approval record ID. These three database operations are managed within the same transaction to ensure that either all operations succeed or all are rolled back, avoiding data inconsistency. After the operation is completed, the system queries the corresponding data table to verify whether the record has taken effect and returns the operation result status.

[0096] In the embodiments of this application, after approval, the three-table linkage operation is automatically completed: inserting the user identifier into the permission association table, supplementing the user application role into the role relationship table, and updating the status of the approval record table. The entire process does not require manual intervention in configuration, avoids the risk of human error, ensures data consistency and traceability across multiple tables, and improves the efficiency of permission allocation.

[0097] For example, Figure 6 The diagram illustrates an approval system diagram of an application permission approval method according to an embodiment of this application.

[0098] like Figure 6As shown, in this approval system, application data is submitted through a front-end interaction module, which provides "Permission Request (First Interaction Interface)" and "Permission Approval (Second Interaction Interface)" interfaces. Ordinary users submit application data through the "Permission Request Interface," while approvers process the workflow through the "Permission Approval Interface." After receiving the application data from the front end, the role verification engine dynamically verifies the legality of the permission request based on the user's role. It then transmits the verification result to the approval workflow module. Based on the verification result, the approval workflow is driven (e.g., automatically transferred to the corresponding approver). Upon completion of the workflow, a permission allocation action is triggered. Daily synchronization is achieved through a data synchronization service (serving as approval data support). Application architect relationship data is pulled from external system interfaces and synchronized to the local database daily. The data synchronization service also supports the workflow; the role verification engine and the approval workflow module read synchronized data from the local database (e.g., verifying whether the application corresponds to the applicant's responsible application) as the basis for permission verification and approval. The approval system enables automated and self-service application permission management, solving the problems of manual reliance, low efficiency, and error-proneness in the permission application process of existing technologies. It enables users to apply for permissions themselves, automatically verify roles, conduct targeted approvals, and automatically allocate permissions.

[0099] By approving application permissions through the approval system, user self-service application and automated approval are realized, improving efficiency and shortening the permission allocation cycle to minutes; eliminating manual operation, reducing the burden on operation and maintenance, and reducing the manpower input for operation and maintenance by 90%; through role verification engine and architect-oriented approval, accurate authorization is achieved and unauthorized allocation is prevented; data consistency is ensured and incremental synchronization mechanism guarantees the real-time accuracy of architect information.

[0100] Based on the above application permission approval method, this application also provides an application permission approval device. The following will combine... Figure 7 The device is described in detail.

[0101] Figure 7 The diagram illustrates the structure of an application permission approval device according to an embodiment of this application.

[0102] like Figure 7 As shown, the application permission approval device 700 of this embodiment includes a role verification module 710, a data reading module 720, and an approval module 730.

[0103] The role verification module 710 is used to verify the role of the permission request submitted by the user through the first interactive interface for the target application. In one embodiment, the role verification module 710 can be used to perform the operation S210 described above, which will not be repeated here.

[0104] The data reading module 720 is used to read application-related data after the role verification is passed; wherein, the application-related data is automatically synchronized and updated by periodically calling a cross-system interface. In one embodiment, the data reading module 720 can be used to perform the operation S220 described above, which will not be repeated here.

[0105] The approval module 730 is used to approve the permission application based on the application-related data and through an approval process strategy, and to allocate application permissions to the user based on the approval result. In one embodiment, the approval module 730 can be used to perform the operation S230 described above, which will not be repeated here.

[0106] According to an embodiment of this application, the role verification module 710 includes: a status check submodule, used to check the user's role in the target application to determine the application status; and a role verification submodule, used to verify the user's role based on the permission application when the application status is pending approval.

[0107] According to an embodiment of this application, the status check submodule includes: a role matching unit, used to match the user's role based on the authorized user information of the target application; an authorized unit, used to configure the application status as authorized if the role matching is successful, and to prompt the user through the first interactive interface that no application information is required; and an application status configuration unit, used to configure the application status based on the permission approval record table if the role matching is unsuccessful.

[0108] According to an embodiment of this application, the application status configuration unit includes: an approval information prompting subunit, used to prompt the user with approval information through the first interactive interface when the user's approval information exists in the permission approval record table; and a pending approval subunit, used to generate an application record based on the permission application, write the application record into the permission approval record table, and configure the application status as pending approval when the user's approval information does not exist in the permission approval record table.

[0109] According to an embodiment of this application, the role verification submodule includes: a query unit for querying the application role corresponding to the user based on a user role relationship table; and a hierarchical verification unit for performing hierarchical verification on the application role.

[0110] According to an embodiment of this application, the approval module 730 includes: an approval process strategy unit, used to obtain the approval operation submitted by the application administrator through a second interactive interface; and if the approval operation is an automatic operation, to automatically approve the permission application based on the application-related data.

[0111] According to an embodiment of this application, the data reading module 720 includes: a data update unit, configured to call the cross-system interface based on a scheduled task to obtain full application data through a pagination query mechanism; and to incrementally update the application-related data based on the full application data.

[0112] According to an embodiment of this application, the approval module 730 further includes: a permission allocation unit, configured to, if the approval result is approval passed, insert the identifier corresponding to the user into the permission association table, add the application role corresponding to the user in the user role relationship table, and modify the application status corresponding to the user in the permission approval record table.

[0113] According to embodiments of this application, any multiple modules among the role verification module 710, data reading module 720, and approval module 730 can be merged into one module, or any one of these modules can be split into multiple modules. Alternatively, at least some of the functions of one or more of these modules can be combined with at least some of the functions of other modules and implemented in one module. According to embodiments of this application, at least one of the role verification module 710, data reading module 720, and approval module 730 can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or any other reasonable means of integrating or packaging circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, at least one of the role verification module 710, data reading module 720, and approval module 730 can be at least partially implemented as a computer program module, which can perform corresponding functions when the computer program module is run.

[0114] Figure 8 A block diagram schematically illustrates an electronic device suitable for implementing an application permission approval method according to an embodiment of this application.

[0115] like Figure 8As shown, an electronic device 900 according to an embodiment of this application includes a processor 901, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 902 or a program loaded from a storage portion 908 into a random access memory (RAM) 903. The processor 901 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 901 may also include onboard memory for caching purposes. The processor 901 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of this application.

[0116] RAM 903 stores various programs and data required for the operation of electronic device 900. Processor 901, ROM 902, and RAM 903 are interconnected via bus 904. Processor 901 executes various operations of the method flow according to embodiments of this application by executing programs in ROM 902 and / or RAM 903. It should be noted that the programs may also be stored in one or more memories other than ROM 902 and RAM 903. Processor 901 may also execute various operations of the method flow according to embodiments of this application by executing programs stored in said one or more memories.

[0117] According to embodiments of this application, the electronic device 900 may further include an input / output (I / O) interface 905, which is also connected to a bus 904. The electronic device 900 may also include one or more of the following components connected to the input / output (I / O) interface 905: an input section 906 including a keyboard, mouse, etc.; an output section 907 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 908 including a hard disk, etc.; and a communication section 909 including a network interface card such as a LAN card, modem, etc. The communication section 909 performs communication processing via a network such as the Internet. A drive 910 is also connected to the input / output (I / O) interface 905 as needed. A removable medium 911, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 910 as needed so that computer programs read from it can be installed into the storage section 908 as needed.

[0118] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0119] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include ROM 902 and / or RAM 903 and / or one or more memories other than ROM 902 and RAM 903 described above.

[0120] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code enables the computer system to implement the application permission approval method provided in the embodiments of this application.

[0121] When the computer program is executed by the processor 901, it performs the functions defined in the system / apparatus of this application embodiment. According to the embodiments of this application, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0122] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via the communication section 909, and / or installed from a removable medium 911. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0123] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 909, and / or installed from the removable medium 911. When the computer program is executed by the processor 901, it performs the functions defined in the system of this application embodiment. According to the embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0124] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0125] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0126] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

Claims

1. An application permission approval method, characterized in that, The method includes: In response to a user submitting a permission request for a target application through the first interactive interface, the permission request is subject to role verification. If the role verification passes, read the application-related data; wherein, the application-related data is automatically synchronized and updated through periodic calls to cross-system interfaces; and Based on the application-related data, the permission application is approved through an approval process strategy, and application permissions are assigned to the user based on the approval result.

2. The method according to claim 1, characterized in that, The step of performing role verification on the permission request includes: Check the user's role in the target application to determine the application status; and If the application status is pending approval, the user's role is verified based on the permission application.

3. The method according to claim 2, characterized in that, The step of checking the user's role in the target application to determine the application status includes: Based on the authorized user information of the target application, the user is matched with a role; If the role matching is successful, the application status is configured to "authorized," and the user is notified via the first interactive interface that no application information is required; and If the role matching fails, the application status will be configured based on the permission approval record table.

4. The method according to claim 3, characterized in that, The configuration of the application status based on the permission approval record table includes: If the user's approval information exists in the permission approval record table, the user is prompted with the approval information through the first interactive interface; and If the user's approval information is not found in the permission approval record table, an application record is generated based on the permission application, the application record is written into the permission approval record table, and the application status is configured as pending approval.

5. The method according to any one of claims 2 to 4, characterized in that, The step of verifying the user's role based on the permission request includes: Based on the user role relationship table, query the application role corresponding to the user; and The application roles are verified in layers.

6. The method according to claim 1, characterized in that, The approval process strategy includes: Obtain approval actions submitted by the application administrator through the second interactive interface; and If the approval operation is automated, the permission request will be automatically approved based on the application-related data.

7. The method according to claim 1, characterized in that, The process of automatically synchronizing and updating application-related data includes: Based on a scheduled task, the cross-system interface is invoked to retrieve the full application data through a paginated query mechanism; and Based on the full application data, the application-related data is incrementally updated.

8. The method according to claim 5, characterized in that, The process of allocating application permissions to the user based on the approval result includes: If the approval result is "approved", then the identifier corresponding to the user is inserted into the permission association table, the application role corresponding to the user is added to the user role relationship table, and the application status corresponding to the user in the permission approval record table is modified.

9. An application permission approval device, characterized in that, The device includes: The role verification module is used to verify the role of the permission request submitted by the user through the first interactive interface for the target application. The data reading module is used to read application-related data after the role verification is passed; wherein, the application-related data is automatically synchronized and updated by periodically calling a cross-system interface; and The approval module is used to approve the permission application based on the application-related data and through the approval process strategy, and to allocate application permissions to the user based on the approval result.

10. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 8.

11. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 8.

12. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 8.

Images