Authority verification method and device, equipment, medium and product
By obtaining the target annotations of the logic to be invoked in the business system and performing automated permission verification, the problem of improving security while ensuring work efficiency is solved, achieving the effects of rapid response and simplified permission management.
Patent Information
- Application Number
- CN202511720589.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-21
- Publication Date
- 2026-02-17
AI Technical Summary
In business systems, how can we improve security while ensuring work efficiency, especially in the face of network threats, by effectively managing permissions to prevent unauthorized logical calls?
By obtaining the target annotation of the logic to be invoked during program execution, verifying whether the current user has the right to invoke it, and processing the result accordingly, automated permission verification is achieved using custom annotations and cross-cutting concern framework.
It enables rapid response to massive permissions and security events, simplifies the complexity of permission management, reduces the maintenance cost of business systems, and improves overall security and business efficiency.
Smart Images
Figure CN121543072A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of financial technology, and in particular to an authorization verification method, apparatus, device, medium, and product. Background Technology
[0002] With social development and technological advancements, more and more industries are adopting newer technologies to improve the efficiency and quality of production and daily life. In today's digital age, with the rapid development of network technology and the explosive growth of data, enterprises, organizations, and individuals face unprecedented cybersecurity threats. These threats include malware, phishing attacks, data breaches, and cyberattacks, which seriously threaten the security of information assets and may lead to business interruption, financial losses, reputational damage, and other risks. Security issues have become a focal point in related fields, and protecting network and data security has become crucial for industry operations and business success.
[0003] Among these, the security of business systems is of paramount importance to all industries. Therefore, how to maximize the security of business systems and processes while ensuring their efficiency has become a key research focus for professionals in related fields. Summary of the Invention
[0004] This application provides an authorization verification method, apparatus, device, medium, and product to improve the security of business systems.
[0005] According to one aspect of this application, an authorization verification method is provided, comprising:
[0006] During the execution of the target program requested by the current user, obtain the target annotation corresponding to the logic to be invoked when the target program runs to the logic to be invoked.
[0007] Based on the target annotation, verify whether the current user has the target permission to invoke the logic to be invoked;
[0008] Based on the verification results, the logic to be invoked is processed.
[0009] According to another aspect of this application, an authorization verification device is provided, comprising:
[0010] The annotation acquisition module is used to acquire the target annotation corresponding to the logic to be invoked when the target program runs to the point of invocation during the current user's application for target program execution.
[0011] The permission verification module is used to verify whether the current user has the target permission to call the logic to be called, based on the target annotation.
[0012] The logic processing module is used to process the logic to be invoked based on the verification results.
[0013] According to another aspect of this application, an electronic device is provided, the electronic device comprising:
[0014] At least one processor; and
[0015] A memory communicatively connected to the at least one processor; wherein,
[0016] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the permission verification method described in any embodiment of this application.
[0017] According to another aspect of this application, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the permission verification method described in any embodiment of this application.
[0018] According to another aspect of this application, a computer program product is provided, the computer program product including a computer program that, when executed by a processor, implements the permission verification method according to any embodiment of this application.
[0019] In the technical solution of this application embodiment, during the execution of the target program requested by the current user, the target annotation corresponding to the logic to be invoked when the target program runs to the point of invocation is obtained; based on the target annotation, it is verified whether the current user has the target permission to invoke the logic to be invoked; based on the verification result, the logic to be invoked is processed. The process of performing permission verification during logic invocation, through automated triggering of permission verification during program execution, achieves rapid response to massive permissions and security events, simplifies the complexity of permission management, reduces the maintenance cost of the business system, and improves overall security.
[0020] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent from the following description. Attached Figure Description
[0021] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0022] Figure 1 This is a flowchart of an authorization verification method provided according to Embodiment 1 of this application;
[0023] Figure 2 This is a schematic diagram of the structure of an authorization verification device according to Embodiment 3 of this application;
[0024] Figure 3 This is a schematic diagram of the structure of an electronic device that implements the permission verification method of the embodiments of this application. Detailed Implementation
[0025] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.
[0026] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0027] Example 1
[0028] Figure 1 This application provides a flowchart of a permission verification method according to Embodiment 1. This embodiment is applicable to situations where permission verification management is performed on users applying for a program during program execution. This method can be executed by a permission verification device, which can be implemented in hardware and / or software and can be configured in an electronic device. Figure 1 As shown, the method includes:
[0029] S110. During the execution of the target program requested by the current user, obtain the target annotation corresponding to the logic to be called when the target program runs to the logic to be called.
[0030] The current user can be any unit, organization, or individual that applies to run the target program locally or via the network. The target program can be any program that can be used by the business system during normal operation and user use; this embodiment does not limit the form or functionality of the target program. The logic to be called can be other programs that may have a calling relationship with the target program, such as a function call or an application plugin call; this embodiment also does not limit this.
[0031] It should be noted that annotations are a programming language feature that allows developers to add metadata—descriptive information about the code itself—without changing its execution logic. Annotations are typically used to provide additional information about the code to the compiler or runtime environment, such as type hints, compile-time checks, code generation, configuration frameworks, or tools. In this embodiment, the target annotation can be a pre-added annotation to the logic to be called. This annotation can include metadata related to the logic to be called, including metadata related to security measures. For example, the target annotation can limit the permission level, defining the minimum permission requirements for executing the logic to be called or accessing the class; it can also limit roles, specifying which users with which roles can execute the logic to be called or access the class; it can also limit permission operations, such as specific operation permissions like read, write, and delete. This embodiment does not limit the permission level, permission role, or permission operation. Of course, the target annotation can be set by those skilled in the art during development based on the actual situation of the logic to be called or human experience, and this embodiment does not limit this.
[0032] Specifically, after a user applies to use the target program, during the execution of the target program, when the code of the target program runs to the calling code section corresponding to the logic to be called, it directly obtains the target annotation corresponding to the logic to be called. This target annotation can exist directly in the code of the target program as a comment, or the target annotation can be pre-stored in other database tables. When the corresponding calling code is executed, the database table is queried according to the name or number of the logic to be called to obtain the content of the corresponding target annotation.
[0033] S120. Based on the target annotation, verify whether the current user has the target permission to call the logic to be called.
[0034] The target permission can be the permission that a user is allowed to invoke the logic to be invoked. It is understandable that the target annotation can store metadata related to security measures. After obtaining the target annotation corresponding to the logic to be invoked, the current user can be verified based on the content recorded in the metadata of the target annotation or other programs called in the metadata. This could be identity verification or operation verification, i.e., whether the user meets the limitations of their role or the limits of their permitted operations.
[0035] S130. Based on the verification results, process the logic to be invoked.
[0036] The verification result can be either pass or fail. If the verification is successful, the current user is allowed to call the logic to be called; conversely, if the verification fails, the current user is not allowed to call the logic to be called, and the business system can report a prompt message to the user.
[0037] In the technical solution of this application embodiment, during the execution of the target program requested by the current user, the target annotation corresponding to the logic to be invoked when the target program runs to the point of invocation is obtained; based on the target annotation, it is verified whether the current user has the target permission to invoke the logic to be invoked; based on the verification result, the logic to be invoked is processed. The process of performing permission verification during logic invocation, through automated triggering of permission verification during program execution, achieves rapid response to massive permissions and security events, simplifies the complexity of permission management, reduces the maintenance cost of the business system, and improves overall security.
[0038] In an optional implementation, the step S110, which involves obtaining the target annotation corresponding to the logic to be invoked when the target program runs to the point of invocation, during the execution of the target program requested by the current user, may include:
[0039] During the execution of the target program requested by the current user, in response to the target program running to the point where there is a marked annotation to be called, if there is a target annotation in the marked annotation of the logic to be called, then the target annotation is obtained.
[0040] In this context, any logic to be called can be marked with an annotation. Therefore, when the target program is running and the code executes to a point where other logic methods are called, it first checks whether the logic to be called is marked with an annotation. If the marked annotation contains the target annotation involved in the aforementioned embodiments or implementations, then the relevant content of the target annotation is obtained first.
[0041] Understandably, before calling and running the logic to be invoked, the target user is checked by verifying the relevant permissions annotated in the target annotation, thereby ensuring that the logic method is not abused and guaranteeing the security of users when using the business system.
[0042] In one alternative implementation, after obtaining the target annotation in S110, the method may further include:
[0043] In response to the existence of the target annotation, the target notification corresponding to the target annotation is queried in the preset aspect; the target notification includes at least one permission verification logic.
[0044] An aspect can be a logical module used to handle cross-cutting concerns in an application. Cross-cutting concerns can be common functions that appear in multiple modules and layers of the application and are unrelated to the core business logic, such as, but not limited to, logging, transaction management, and permission checks. An advice in an aspect can be a specific action executed at a specific join point; that is, what specific cross-cutting logic needs to be executed at which stage of the current program execution. In this embodiment, the target advice includes at least one permission verification logic, and it is precisely this permission verification logic that needs to be executed, such as, but not limited to, permission level verification, permission role verification, and permission operation verification. An aspect can include one or more advices, and each advice can include multiple permission verification logics used to verify the permissions of the target user before invoking the logic to be invoked.
[0045] Specifically, if a target annotation exists in the comments of the logic to be invoked, the target notification corresponding to the target annotation is queried in a pre-set aspect to determine which verification steps are required for the target annotation. In this embodiment, the target notification corresponding to the target annotation is queried in a preset aspect. By querying the target notification through a preset aspect, the required permission verification for the logic to be invoked is determined, helping the program to automate the permission verification process and improve the efficiency of permission verification.
[0046] In one optional implementation, the step of verifying whether the current user has the target permission to invoke the logic to be invoked based on the target annotation in S120 may include:
[0047] Based on the target annotation and the target notification, verify whether the current user has the target permission to invoke the logic to be invoked.
[0048] Understandably, the target notification is retrieved from the preset aspect based on the target annotation. The information marked in the target annotation includes not only the query information for the target notification, but also the limiting conditions for the specified permission level, permission role, and permission operation. The target notification sets the information on what permission verification is required. By verifying the target user through both the target annotation and the target notification, it is determined whether the target user has the target permission to invoke the logic.
[0049] In the above implementation, verifying whether the current user has the target permissions through target annotations and target notifications can improve the verification efficiency of the business system for target users and help improve the security of the business system.
[0050] In a further optional implementation, verifying whether the current user has the target permission to invoke the logic to be invoked based on the target annotation and the target notification may include:
[0051] A1. Based on the target notification, obtain the user information of the current user from the pre-deployed authentication framework.
[0052] The authentication framework can be any collection of components or protocols used to store user login information. This framework stores user information when a user logs into the business system. Upon receiving a target notification, the target notification requests the user information from the authentication framework. User information can include identity-related information provided by the user when logging into the business system, such as user permissions and role positioning (user, developer, administrator, etc.). It can also include the user's personal information. It should be noted that the collected information is authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with relevant national and regional 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. Furthermore, the authentication framework can be pre-deployed by those skilled in the art according to actual conditions; this application embodiment does not limit this.
[0053] A2. Based on the user information, verify the permission level, permission role, and permission operation specified in the target annotation to determine whether the current user has the target permission to call the logic to be called.
[0054] After obtaining the current user's information from the preset authentication framework in the aforementioned steps, the permission level, permission role, and permission operation recorded in the target annotation are verified against the user information to verify whether the current user meets the permission level, permission role, and permission operation specified in the target annotation, thereby determining whether the current user has the target permission to call the logic.
[0055] In the above implementation, the user information of the current user is obtained from the pre-deployed authentication framework through target notification, and the current user is verified according to the permission content specified in the target annotation, which can improve the security of the business system; through a more flexible annotation and aspect mechanism, developers can deeply customize security requirements, thereby improving the security and usability of the system.
[0056] In a further optional implementation, verifying the permission level, permission role, and permission operation specified in the target annotation to determine whether the current user has the target permission to invoke the logic to be invoked may include:
[0057] If at least one of the permission level, permission role, and permission operation fails verification, the current user does not have the target permission.
[0058] The permission level can be a preset level corresponding to the permissions that different users can unlock. The permission role can be the role that a user is assigned when logging into the business system to use the target program. The permission operation can be the usage, modification or other operations that a user is allowed to perform on the target program. Different users, different permission levels and different permission roles all have an impact on the permission operation.
[0059] Understandably, if a user wants to invoke the logic to be invoked, they need to pass all the permission verification steps. Permission level, permission role, and permission operation all need to be verified. If any one of these verifications fails, it means the current user cannot pass the verification and therefore does not have the permission to invoke the logic. This implementation method also improves the security of the business system to a certain extent, enabling users to allocate permissions and adjust security policies more efficiently, thereby helping to improve the business efficiency of the system.
[0060] Example 2
[0061] This application embodiment is a specific example based on the foregoing embodiments and implementation methods, and its content is as follows:
[0062] First, to achieve automated access control, this application predefines a custom annotation in the code, such as "@Secured". This annotation is used to mark methods or classes that require permission checks. The annotation contains key information such as the permission level, which defines the minimum permission requirements to execute the method or access the class; roles, which specify which users with those roles can execute the method or access the class; and operations, which may include specific operation permissions such as "read", "write", and "delete". In this way, developers can easily specify security requirements in the code without manually checking permissions in each method.
[0063] Secondly, this application utilizes the aspect definition within the cross-cutting concern framework. An aspect, a logical module, is defined within this framework to handle cross-cutting concerns in the application, such as logging, transaction management, and permission checks. This aspect contains one or more advices, which are automatically executed before (before advice) or after (after advice) method execution. The advice's task is to check annotations on the method, such as "@Secured," and then perform permission verification based on the information in the annotation. If verification fails, the advice can throw an exception, preventing the method from executing.
[0064] This application then utilizes pointcut expressions to associate annotations: to ensure that only methods annotated with a specific annotation will trigger advice in the aspect, pointcut expressions are used. For example, the pointcut expression `@annotation(com.example.SecurityAnnotations.Secured)` means that the aspect advice associated with that pointcut will only be executed when a method or class is annotated with `@Secured`. This allows for automated control of code requiring security checks without interfering with unannotated methods or classes.
[0065] Finally, this application employs dynamic execution of advice: during program execution, when the execution flow reaches a method annotated with `@Secured`, the runtime proxy mechanism of the cross-cutting concern framework intervenes. The proxy detects whether the method to be executed has the `@Secured` annotation; if so, it looks for the advice associated with that annotation in the previously defined aspects. The advice contains one or more permission verification logics; for example, it retrieves detailed information about the currently logged-in user from a pre-deployed authentication framework, including roles and permissions. Then, the advice checks whether the user has the permission to execute the method based on the permission level, role, and action specified in the annotation. If the user meets all requirements, the advice allows the method to continue execution, and the program's execution flow continues to flow into the method. However, if the user lacks sufficient permissions, the advice triggers an exception or refuses to execute the method through other means (such as returning an error message). This prevents unauthorized users from accessing sensitive data or performing critical operations, thereby achieving security control. In this way, this application provides a dynamic, flexible and efficient permission management system that can be seamlessly integrated into existing applications without requiring developers to manually implement permission checks in each method, thus reducing code complexity and improving system security.
[0066] This application automates application permission management and security control through an efficient combination of custom annotations and a cross-cutting concern framework, enabling rapid response to massive amounts of permissions and security events. By using predefined security policies and dynamically executed aspects, this application not only provides a convenient method for permission control and security checks, but also allows developers to deeply customize security requirements through flexible annotation and aspect mechanisms, thereby improving system security and usability.
[0067] In this way, this application not only simplifies the complexity of access control and reduces maintenance costs, but also enables the system to adapt to constantly changing security threats and organizational needs through the flexibility of custom annotations. This not only improves system security, but also allows users to allocate permissions and adjust security policies more efficiently, thereby improving overall business efficiency and decision-making quality.
[0068] Example 3
[0069] Figure 2 This is a schematic diagram of the structure of an authorization verification device provided in Embodiment 3 of this application. Figure 2 As shown, the device 200 includes:
[0070] The annotation acquisition module 210 is used to acquire the target annotation corresponding to the logic to be invoked when the target program runs to the point of invocation during the current user-application target program execution process;
[0071] The permission verification module 220 is used to verify whether the current user has the target permission to call the logic to be called, based on the target annotation.
[0072] The logic processing module 230 is used to process the logic to be invoked based on the verification result.
[0073] In the technical solution of this application embodiment, during the execution of the target program requested by the current user, the target annotation corresponding to the logic to be invoked when the target program runs to the point of invocation is obtained; based on the target annotation, it is verified whether the current user has the target permission to invoke the logic to be invoked; based on the verification result, the logic to be invoked is processed. The process of performing permission verification during logic invocation, through automated triggering of permission verification during program execution, achieves rapid response to massive permissions and security events, simplifies the complexity of permission management, reduces the maintenance cost of the business system, and improves overall security.
[0074] In one optional implementation, the annotation acquisition module 210 may include:
[0075] The annotation acquisition unit is used to, during the execution of the target program applied for by the current user, respond to the target program running to the point where there is a marked annotation for the logic to be called, and if there is a target annotation in the marked annotation of the logic to be called, then acquire the target annotation.
[0076] In one alternative embodiment, the device 200 may further include:
[0077] The notification query module is used to query the target notification corresponding to the target annotation in a preset aspect in response to the existence of the target annotation; the target notification includes at least one permission verification logic.
[0078] In another alternative embodiment, the permission verification module 220 may include:
[0079] The permission verification unit is used to verify whether the current user has the target permission to call the logic to be called, based on the target annotation and the target notification.
[0080] In a further optional embodiment, the permission verification unit may include:
[0081] The user information acquisition subunit is used to acquire the user information of the current user from a pre-deployed authentication framework according to the target notification.
[0082] The target permission verification subunit is used to verify the permission level, permission role and permission operation specified in the target annotation based on the user information, and determine whether the current user has the target permission to call the logic to be called.
[0083] In a further optional embodiment, the target permission verification subunit may be specifically used for:
[0084] If at least one of the permission level, permission role, and permission operation fails verification, the current user does not have the target permission.
[0085] The permission verification device provided in this application embodiment can execute the permission verification method provided in any embodiment of this application, and has the corresponding functional modules and beneficial effects for executing each permission verification method.
[0086] Example 4
[0087] Figure 3 A schematic diagram of an electronic device 10, which can be used to implement embodiments of this application, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (such as helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the application described and / or claimed herein.
[0088] like Figure 3 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory 12 or a random access memory 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the read-only memory 12 or loaded from storage unit 18 into the random access memory 13. The random access memory 13 may also store various programs and data required for the operation of the electronic device 10. The processor 11, read-only memory 12, and random access memory 13 are interconnected via a bus 14. An input / output interface 15 is also connected to the bus 14.
[0089] Multiple components in electronic device 10 are connected to input / output interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of monitors, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.
[0090] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, central processing units, graphics processing units, various special-purpose artificial intelligence computing chips, various processors running machine learning model algorithms, digital signal processors, and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as authorization verification methods.
[0091] In some embodiments, the access control method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via read-only memory 12 and / or communication unit 19. When the computer program is loaded into random access memory 13 and executed by processor 11, one or more steps of the access control method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform the access control method by any other suitable means (e.g., by means of firmware).
[0092] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays, application-specific integrated circuits (ASICs), application-specific standard products (ASICs), system-on-a-chip (SoCs), payload programmable logic devices (PLCs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.
[0093] Computer programs used to implement the methods of this application may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.
[0094] In the context of this application, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium can be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, optical fibers, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.
[0095] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a monitor with a cathode ray tube or liquid crystal display) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).
[0096] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.
[0097] A computing system can include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a host product within the cloud computing service system to address the shortcomings of traditional physical hosts and virtual private servers, such as high management difficulty and weak business scalability.
[0098] This application also discloses a computer program product, which includes a computer program that, when executed by a processor, implements the permission verification method provided in any embodiment of this application. This program product and the permission verification methods disclosed in the embodiments of this application belong to the same inventive concept, and therefore will not be described in detail here.
[0099] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this application can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this application can be achieved, and this is not limited herein.
[0100] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.
Claims
1. A method of verifying rights, characterized by The method comprises the following steps: In the process of running the target program applied by the current user, the target annotation corresponding to the to-be-called logic is acquired when the target program runs to the to-be-called logic; According to the target annotation, it is verified whether the current user has the target permission to call the to-be-called logic; According to the verification result, the to-be-called logic is processed.
2. The method of claim 1, wherein, The method comprises the following steps: In the process of running the target program applied by the current user, the target annotation corresponding to the to-be-called logic is acquired when the target program runs to the to-be-called logic.
3. The method of claim 2, wherein, After acquiring the target annotation, the method further comprises the following steps: In response to the existence of the target annotation, the target notification corresponding to the target annotation is queried in a preset aspect; the target notification comprises at least one permission verification logic.
4. The method of claim 3, wherein, According to the target annotation and the target notification, it is verified whether the current user has the target permission to call the to-be-called logic. According to the target annotation and the target notification, it is verified whether the current user has the target permission to call the to-be-called logic.
5. The method of claim 4, wherein, According to the target notification, the user information of the current user is acquired in a pre-deployed identity verification framework; According to the user information, the permission level, the permission role and the permission operation specified in the target annotation are verified to determine whether the current user has the target permission to call the to-be-called logic. According to the target annotation and the target notification, it is verified whether the current user has the target permission to call the to-be-called logic.
6. The method of claim 5, wherein, In response to the fact that at least one of the permission level, the permission role and the permission operation fails to pass the verification, the current user does not have the target permission. The method comprises the following steps:
7. An authority verification apparatus characterized by comprising: The annotation acquisition module is configured to acquire the target annotation corresponding to the to-be-called logic when the target program runs to the to-be-called logic in the process of running the target program applied by the current user; The permission verification module is configured to verify whether the current user has the target permission to call the to-be-called logic according to the target annotation; The logic processing module is configured to process the to-be-called logic according to the verification result. The electronic device comprises:
8. An electronic device, comprising: At least one processor; and The memory is in communication connection with the at least one processor; wherein The memory stores a computer program that can be executed by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to execute the permission verification method in any one of claims 1-6. The computer readable storage medium stores computer instructions, and the computer instructions are used to enable the processor to execute the permission verification method in any one of claims 1-6.
9. A computer-readable storage medium, characterized in that, 10. A computer program product, characterised in that, The computer program product comprises a computer program which, when executed by a processor, implements the permission verification method according to any one of claims 1-6.