Permission processing method, medium and program product
By dynamically obtaining account status and permission judgment rules, the problem of poor reliability of permission judgment in existing technologies is solved, and real-time and reliable permission control and interface display are realized.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-10-28
- Publication Date
- 2026-03-31
AI Technical Summary
In existing technologies, software system permission determination mainly relies on static methods such as usernames and passwords, resulting in poor reliability.
By obtaining the current account status of the target account and the access permission judgment rules of the target system, the permission judgment result is dynamically generated, and the system entry is displayed according to the interface information. The permission judgment logic is dynamically adjusted by considering the account status and multiple permission reference factors.
It improves the real-time performance and reliability of permission determination, ensuring the security of system use and the rationality of interface information.
Smart Images
Figure CN121765699A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of computer technology, and in particular to a permission handling method, medium, and program product. Background Technology
[0002] With the development of information technology, software systems are widely used in various industries to implement specific functions such as fund custody and data management. Typically, only accounts with access to the software system can use it. The inventors discovered that most related technologies rely on static methods such as usernames and passwords to determine whether an account has system access, which is unreliable. Summary of the Invention
[0003] To solve the above-mentioned technical problems, or at least partially solve them, this disclosure provides a permission processing method, medium, and program product.
[0004] This disclosure provides a permission processing method, the method comprising: responding to a permission judgment event triggered by a target account, obtaining the current account status of the target account; retrieving the current usage permission judgment rule corresponding to the target system; wherein the usage permission judgment rule is an adjustable rule set based on at least one permission reference factor, the at least one permission reference factor including an account status factor; generating a permission judgment result corresponding to the target account based on the account status of the target account and the usage permission judgment rule; wherein the permission judgment result is used to indicate whether the target account currently has usage permission to the target system; and displaying interface information corresponding to the permission judgment result to the target account.
[0005] Optionally, the number of permission reference factors can be multiple; the step of generating a permission judgment result corresponding to the target account based on the account status of the target account and the usage permission judgment rule includes: determining the target set to which the account status of the target account belongs from a pre-set set of multiple account status types; determining the permission judgment logic corresponding to the target set based on the usage permission judgment rule, and executing the permission judgment logic corresponding to the target set; wherein, the permission judgment logic corresponding to different account status sets is different; and obtaining the permission judgment result corresponding to the target account based on the execution result of the permission judgment logic corresponding to the target set.
[0006] Optionally, the set of multiple account statuses includes a first set of account statuses, a second set of account statuses, and a third set of account statuses. If the target set is the first set of account statuses, the permission determination logic corresponding to the target set is: determining that the target account has access to the target system. If the target set is the second set of account statuses, the permission determination logic corresponding to the target set is: determining that the target account does not have access to the target system. If the target set is the third set of account statuses, the permission determination logic corresponding to the target set includes: retrieving information about additional reference factors corresponding to the target account, and determining whether the target account has access to the target system based on the information about the additional reference factors. The additional reference factors are other permission reference factors besides the account status among the various permission reference factors.
[0007] Optionally, determining whether the target account has access to the target system based on the information of the additional reference factors includes: obtaining the reference priority corresponding to each additional reference factor, and the conditions that each additional reference factor must meet; verifying whether the information of the additional reference factors corresponding to the target account meets the conditions of the additional reference factor in descending order of the reference priority, until all additional reference factors have been verified, or until an additional reference factor that does not meet the corresponding conditions is found; if no additional reference factor that does not meet the corresponding conditions is found, then it is determined that the target account has access to the target system; if an additional reference factor that does not meet the corresponding conditions is found, then it is determined that the target account does not have access to the target system.
[0008] Optionally, obtaining the current account status of the target account includes: determining the latest status of the target account based on the target message queue, and using the latest status of the target account as the current account status of the target account; wherein, the target message queue is used to record account status change events.
[0009] Optionally, the method further includes: receiving the usage permission judgment rule corresponding to the target system through the visual interface of the rule configuration backend, and saving the received usage permission judgment rule to the memory of the permission judgment engine; the step of retrieving the usage permission judgment rule currently corresponding to the target system and generating the permission judgment result corresponding to the target account based on the account status of the target account and the usage permission judgment rule includes: retrieving the usage permission judgment rule currently corresponding to the target system from the memory of the permission judgment engine, and using the permission judgment engine to generate the permission judgment result corresponding to the target account based on the account status of the target account and the usage permission judgment rule.
[0010] Optionally, displaying interface information corresponding to the permission determination result for the target account includes: if the permission determination result indicates that the target account has access to the target system, then displaying first interface information on the user interface corresponding to the target account; wherein the first interface information includes the entry point to the target system; if the permission determination result indicates that the target account does not have access to the target system, then displaying second interface information on the user interface corresponding to the target account; wherein the second interface information does not include the entry point to the target system.
[0011] Optionally, the target system includes a fund custody system; the permission reference factors also include one or more of the following: contract type, project node type, payment type, whether the service provider corresponding to the target account supports the target system, the geographical information corresponding to the target account, and whether the project corresponding to the target account is in the list of projects unconditionally permitted to use the target system.
[0012] This disclosure also provides a computer-readable storage medium storing a computer program for executing the permission processing method provided in this disclosure.
[0013] This disclosure also provides a computer program product, including a computer program that, when executed by a processor, implements the permission handling method provided in this disclosure.
[0014] The technical solution provided in this disclosure can obtain the current account status of the target account and the current access permission judgment rules of the target system. Based on this, it generates the access permission judgment result corresponding to the target account, and then displays the interface information corresponding to the access permission judgment result to the target account. This method does not directly use static methods such as username and password to determine whether the target account has access permission to the target system. Instead, it fully considers the impact of account status on system access permission and dynamically obtains the current account status of the target account and the current access permission judgment rules of the target system, thereby dynamically determining whether the target account currently has access permission to the target system. This method has strong real-time performance, which can effectively ensure the reliability of the access permission judgment result and further ensure the rationality of the interface information displayed to the target account.
[0015] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description
[0016] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.
[0017] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0018] Figure 1 A flowchart illustrating a permission processing method provided in an embodiment of this disclosure; Figure 2 This is a schematic diagram of the structure of an authorization system provided in an embodiment of the present disclosure; Figure 3 This is a schematic diagram of a permission processing flow provided in an embodiment of the present disclosure; Figure 4 This is a schematic diagram of the structure of a permission processing device provided in an embodiment of the present disclosure; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure. Detailed Implementation
[0019] To better understand the above-mentioned objectives, features, and advantages of this disclosure, the solutions disclosed herein will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.
[0020] Numerous specific details are set forth in the following description in order to provide a full understanding of this disclosure, but this disclosure may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some, and not all, of the embodiments of this disclosure.
[0021] Figure 1 This is a flowchart illustrating a permission processing method provided in an embodiment of the present disclosure. This method can be executed by a permission processing device, which can be implemented in software and / or hardware, and is generally integrated into an electronic device. Figure 1 As shown, the method mainly includes the following steps S102 to S108: Step S102: In response to the target account triggering a permission judgment event, obtain the current account status of the target account.
[0022] The target account can be an individual user account or an enterprise user account; there is no restriction on this. A permission determination event is an event used to indicate whether a target account has the necessary permissions to use the target system. This disclosure does not limit the form in which the target account triggers the permission determination event. For example, if the target account is detected logging into the target application, then it is confirmed that the target account has triggered the permission determination event; wherein, the target application is an application related to the target system; or, for example, if the target account is detected triggering a function control or page related to the target system, then it is confirmed that the target account has triggered the permission determination event.
[0023] This disclosure does not limit the way account status is divided. Account status can be understood as a number of predefined enumerated values. Account status can include statuses that reflect different stages of the account's lifecycle. For example, account status includes, but is not limited to: pending account opening, pending contract signing, account closure available, account closure in progress, and account closure. In addition, account status can also include statuses related to the target system, such as: the target system's usage status and the status that the target system is not supported. Furthermore, account status can also include statuses related to funds, such as frozen status and insufficient balance status. The specific settings can be flexible.
[0024] Step S104: Retrieve the current access permission judgment rule of the target system; wherein, the access permission judgment rule is an adjustable rule set based on at least one permission reference factor, and the at least one permission reference factor includes account status factor.
[0025] The access permission determination rules provided in this disclosure are not statically set fixed rules, but rather adjustable rules configured through a rule configuration backend. Backend personnel can flexibly set and adjust these rules as needed. For example, the rules can be used to indicate the permission determination logic corresponding to different account states, and / or the conditions that an account with access to the target system must meet in terms of various permission reference factors, etc., without any limitations. This approach greatly improves the flexibility of rule setting and the convenience of rule adjustment. It eliminates the need for personnel to modify or release code; the rules can be flexibly set and adjusted through the visual interface of the rule configuration backend. This allows the access permission determination rules for the target system to become dynamic rules, further enhancing the security of the target system.
[0026] In some implementation examples, the current usage permission judgment rules of the target system can be retrieved directly through the rule configuration backend. In other implementation examples, the rule configuration backend can synchronously store the latest received current usage permission judgment rules of the target system in a specified location such as the rule database or the memory used to execute the permission judgment engine, thereby retrieving the current usage permission judgment rules of the target system from the specified location, achieving the purpose of retrieving usage permission judgment rules in real time and quickly.
[0027] This disclosure does not limit the target system and permission reference factors. For example, the target system includes a fund custody system. Based on this, permission reference factors also include one or more of the following: contract type, project node type, payment type, whether the service provider corresponding to the target account supports the target system, the geographical information of the target account, and whether the project corresponding to the target account is on the list of projects unconditionally permitted to use the target system (also referred to as the whitelist). Furthermore, factors such as account qualifications, transaction time periods, and transaction limits may also be included, and these can be flexibly set without limitation. Through the above methods, access conditions for the target system can be set based on a multi-dimensional combination, enabling fine-grained control over the use permissions of the target system.
[0028] Step S106: Based on the account status and usage permission discrimination rules of the target account, generate the permission discrimination result corresponding to the target account; wherein, the permission discrimination result is used to indicate whether the target account currently has usage permission of the target system.
[0029] For example, the permission determination result for the target account can be determined based on the permission determination logic corresponding to the account status indicated by the permission determination rules. It is understood that both the account status and the permission determination rules are up-to-date information; if the account status or the permission determination rules change, the permission determination result will be adjusted accordingly, thereby ensuring the timely and effective security of the target system.
[0030] Step S108: Display the interface information corresponding to the permission judgment result for the target account.
[0031] In some implementation examples, if the permission assessment result indicates that the target account has access to the target system, then a first interface information is displayed on the user interface corresponding to the target account; this first interface information includes the entry point to the target system. If the permission assessment result indicates that the target account does not have access to the target system, then a second interface information is displayed on the user interface corresponding to the target account; this second interface information does not include the entry point to the target system. The entry point to the target system can be represented through controls, interfaces, links, etc. In this way, the entry point to the target system is only displayed to the target account when it is determined that the target account has access to the target system, thus fully ensuring information security. In other implementation examples, the entry point to the target system is always displayed on the user interface of the target account. The first interface information includes system interface information indicating successful access to the target system, and the second interface information includes a prompt message indicating that access to the target system is denied. The specific interface information corresponding to the permission assessment result can be flexibly set, and no restrictions are imposed here.
[0032] The above method does not directly use static methods such as username and password to determine whether the target account has access to the target system. Instead, it fully considers the impact of account status on system access permissions and dynamically obtains the current account status of the target account and the current access permission judgment rules of the target system. This allows for dynamic determination of whether the target account currently has access to the target system. This method has strong real-time performance, which can effectively ensure the reliability of the permission judgment results and further ensure the rationality of the interface information displayed to the target account.
[0033] To ensure the reliability of the obtained target account status, the steps for obtaining the current account status of the target account include: determining the latest status of the target account based on the target message queue, and using the latest status of the target account as the current account status; wherein, the target message queue is used to record account status change events. This method of determining the account status based on the target message queue effectively ensures that the obtained account status is the latest status of the target account, thus guaranteeing the reliability of the account status.
[0034] The method provided in this embodiment further includes: receiving the usage permission judgment rules corresponding to the target system through the visual interface of the rule configuration backend, and saving the received usage permission judgment rules into the memory of the permission judgment engine. The rule configuration backend can provide a visual interface for service providers such as administrators and sales personnel. The visual interface can display interface elements for setting usage permission rules, such as configuration controls for various permission reference factors. In addition, it can provide a new control so that service providers can flexibly add the required permission reference factors according to their needs. Through this method, it is possible to achieve dynamic and convenient rule configuration directly using a visual approach without manually writing or modifying the code used to control permissions. That is, dynamically adjusting rules using the configuration backend can improve the reliability of permission control to a certain extent.
[0035] The rule configuration backend can save the latest access permission judgment rules to the memory of the access permission judgment engine, which helps improve the rule retrieval speed. The access permission judgment engine is the processing module used to determine whether an account has access to the target system. In some specific examples, the process of retrieving the current access permission judgment rules for the target system, and generating the access permission judgment result for the target account based on the target account's account status and the access permission judgment rules, includes: retrieving the current access permission judgment rules for the target system from the access permission judgment engine's memory, and using the access permission judgment engine to generate the access permission judgment result for the target account based on the target account's account status and the access permission judgment rules. This method can directly leverage the access permission judgment engine to perform access permission judgment operations, improving processing efficiency; and by retrieving the latest access permission judgment rules from memory, it avoids high-concurrency latency issues, further reducing access permission judgment time.
[0036] To ensure the reliability of the permission determination results, in some implementations, the number of permission reference factors is multiple; the steps described above for generating the permission determination results corresponding to the target account based on the target account's account status and usage permission determination rules can be performed with reference to steps A to C below: Step A involves determining the target set to which the target account's account status belongs from a pre-defined set of multiple account status categories. This embodiment of the disclosure can divide various account statuses into multiple account status sets based on the commonalities of permission judgment logic. The specific set can be flexibly configured according to the actual scenario, and this method of division by set facilitates subsequent analysis and processing. Step B involves determining the permission determination logic corresponding to the target set based on the permission determination rules, and then executing the permission determination logic for the target set. Different account state sets correspond to different permission determination logic. That is, account states within the same account state set correspond to the same permission determination logic, while account states in different account state sets correspond to different permission determination logics.
[0037] For example, the multiple account status sets include a first set of account statuses, a second set of account statuses, and a third set of account statuses. For example, the first set of account statuses includes one or more of the following account statuses: currently in use of the target system, pending account cancellation, account cancellation in progress, and account cancellation completed. The second set of account statuses includes one or more of the following: the account does not support the target system, or the business of the target system is skipped. The third set of account statuses includes one or more of the following account statuses: pending account opening, pending contract signing, etc.
[0038] If the target set is the first type of account status set, then the permission determination logic corresponding to the target set is: determine whether the target account has the right to use the target system. That is, if the target account's account status belongs to the first type of account status set, no further determination is needed, and it can be directly regarded as having the right to use the target system.
[0039] If the target set is a set of second-type account states, the permission determination logic for the target set is as follows: determine that the target account does not have the permission to use the target system. That is, if the target account's account state belongs to the set of second-type account states, no further determination is needed, and it can be directly regarded as not having the permission to use the target system.
[0040] If the target set is a third-category account status set, the permission determination logic for the target set includes: retrieving information on the additional reference factors corresponding to the target account, and determining whether the target account has the right to use the target system based on the information on the additional reference factors; the additional reference factors are other permission reference factors besides account status among various permission reference factors. That is, if the target account's account status belongs to the third-category account status set, it is necessary to further obtain additional reference factors to determine whether it has the right to use the target system.
[0041] Step C: Based on the execution result of the permission judgment logic corresponding to the target set, obtain the permission judgment result corresponding to the target account.
[0042] By dividing various account statuses into three categories and setting corresponding permission judgment logic for each category, the permission judgment logic corresponding to the account status of the target account can be determined quickly and efficiently, and the corresponding permission judgment processing can be performed.
[0043] This disclosure further provides an implementation example of determining whether a target account has access to the target system based on the aforementioned information of additional reference factors, which can be performed as follows (1) to (4): (1) Obtain the reference priority corresponding to each additional reference factor, and the conditions that each additional reference factor must meet. In practical applications, the above reference priorities can be flexibly set according to needs, or set by the access permission judgment rules. In some examples, the reference priorities can be divided based on the judgment difficulty of each additional reference factor, and in other examples, the reference priorities can be divided based on the importance of each additional reference factor. The specific settings can be flexibly configured and are not restricted here. In practical applications, the access permission judgment rules can be used to indicate the conditions that each additional reference factor must meet. For example, if the additional reference factor is the contract type factor, then the account with access to the target system must meet the requirement that the contract type is personal contract; or if the additional reference factor is the decoration project node, then the account with access to the target system must meet the requirement that the decoration project node is that water and electricity acceptance has not been carried out.
[0044] (2) Based on the reference priority from high to low, verify the information of the additional reference factors corresponding to the target account one by one to see if they meet the conditions corresponding to the additional reference factors, until all additional reference factors have been verified, or until an additional reference factor that does not meet the corresponding conditions is found. For example, if the additional reference factors include factor A, factor B and factor C, and are sorted from high to low priority, then the information of factor A corresponding to the target account will be verified first to see if it meets the conditions corresponding to factor A. If it does not meet the conditions, the verification will end, indicating that the target account does not have the right to use the target system. If it does meet the conditions, then the information of factor B corresponding to the target account will be verified to see if it meets the conditions corresponding to factor B, and so on.
[0045] (3) If no additional reference factors that do not meet the corresponding conditions are found, then the target account is determined to have access to the target system. In other words, the target account is determined to have access to the target system only if all additional reference factors meet the corresponding conditions.
[0046] (4) If any additional reference factor that does not meet the corresponding conditions is found, it is determined that the target account does not have the right to use the target system. That is, as long as one additional reference factor that does not meet the corresponding conditions is found, it can be directly determined that the target account has the right to use the target system.
[0047] By using the above-mentioned multi-dimensional factors for judgment, the reliability of system access control can be further improved.
[0048] For easier understanding, please refer to Figure 2The diagram shown illustrates the structure of a permission determination system, primarily showcasing the interaction between three modules: the permission determination engine, the configuration backend, and the account status module. Figure 2 In this example, a user request to access an application triggers a permission determination event, assuming the target system is a fund custody system. The application can interact with the permission determination engine through an API (Application Programming Interface) gateway or microservice to determine whether the user has permission to use the fund custody system. Specifically, if the user has permission, the entry point to the fund custody system is displayed; otherwise, it is not displayed. The permission determination engine can first determine whether to display the entry point or whether further determination is needed based on the account status. If further determination is needed, it can make determinations based on permission reference factors such as contract type, project progress, and payment ratio. It can also further determine permissions based on factors such as the project whitelist and whether the service provider supports fund custody, until a permission determination result is obtained. The configuration backend and account status module provide data support for the permission judgment engine. Specifically, administrators can dynamically configure permission judgment rules via API on the configuration backend. The account status module provides account status information, categorized into three types: display entry points, non-display entry points, and conditionally displayed entry points. The account status module can monitor account status change events in real time through Kafka (a stream processing platform), accurately determining the current account status of the target account. Furthermore, both rule data and status data can be stored in a database for later retrieval. It should be noted that... Figure 2 This is intended to illustrate the interaction between the three modules: the permission judgment engine, the configuration backend, and the account status module. The specific account status, permission judgment rules, permission reference factors involved in the permission judgment engine, and the judgment logic executed can all be flexibly adjusted and are not restricted here.
[0049] Taking a fund custody system as an example, one can also refer to... Figure 3 The diagram illustrates a permission processing flow, showing how user identity verification is used as the trigger for permission determination. The user's account is the target account. First, based on the account status, three types of permission determination logic are established: the first directly confirms that the account has custody permissions, i.e., directly displays the custody entry point; the second directly confirms that the account does not have custody permissions, i.e., does not display the custody entry point; the third requires considering various permission reference factors such as contract type, renovation project milestones, the whitelist of fund custody projects, whether the service provider supports fund custody services, and whether payments are received, to determine whether the account has custody permissions. It should be noted that... Figure 3This is merely an example of applying the permission processing method provided in the embodiments of this disclosure in the home decoration field, and should not be regarded as a limitation. In practice, the reference factors and judgment order of each permission can be flexibly set according to the actual application scenario and business needs, and no restrictions are imposed here.
[0050] In summary, the permission processing method provided in this disclosure allows relevant personnel to flexibly and conveniently define dynamic permission judgment rules through a configuration backend. Furthermore, it allows setting access conditions for the target system based on a combination of multi-dimensional factors, facilitating unified management. In addition, it can obtain the latest account status, and by combining the permission judgment rules and the account status, it can accurately and dynamically determine whether the target account currently has the necessary permissions to use the target system. This provides strong real-time performance, and can promptly adjust system usage permissions when the account status changes, achieving timely risk interception. This effectively ensures the reliability of permission judgment results, protecting the security of the target system and the user experience. Corresponding to the aforementioned permission processing method, this disclosure further provides a permission processing apparatus. Figure 4 This is a schematic diagram of a permission processing device provided in an embodiment of the present disclosure. The device can be implemented by software and / or hardware, and is generally integrated into an electronic device, such as... Figure 4 As shown, the permission processing device includes: The account status acquisition module 402 is used to acquire the current account status of the target account in response to the target account triggering a permission judgment event; The rule retrieval module 404 is used to retrieve the current usage permission judgment rule of the target system; wherein, the usage permission judgment rule is an adjustable rule set based on at least one permission reference factor, and the at least one permission reference factor includes account status factor; The discrimination result generation module 406 is used to generate a permission discrimination result corresponding to the target account based on the account status of the target account and the usage permission discrimination rule; wherein, the permission discrimination result is used to indicate whether the target account currently has usage permission of the target system; The interface display module 408 is used to display interface information corresponding to the permission judgment result for the target account.
[0051] The aforementioned device does not directly use static methods such as username and password to determine whether the target account has access to the target system. Instead, it fully considers the impact of account status on system access permissions and dynamically obtains the current account status of the target account and the current access permission judgment rules of the target system. This allows it to dynamically determine whether the target account currently has access to the target system. This device has strong real-time performance, which can effectively ensure the reliability of the permission judgment results and further ensure the rationality of the interface information displayed to the target account.
[0052] The permission processing device provided in this disclosure can execute the permission processing method provided in any embodiment of this disclosure, and has the corresponding functional modules and beneficial effects of the execution method.
[0053] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the above-described device embodiments can be referred to the corresponding process in the method embodiments, and will not be repeated here.
[0054] This disclosure provides an electronic device, which includes: a storage device storing a computer program thereon; and a processing device for executing the computer program in the storage device to implement the steps of any method of this disclosure.
[0055] The following is for reference. Figure 5 This diagram illustrates a structural schematic of an electronic device 500 suitable for implementing embodiments of the present disclosure. The terminal devices in these embodiments may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.
[0056] like Figure 5 As shown, electronic device 500 may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 501, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 502 or a program loaded from storage device 508 into random access memory (RAM) 503. RAM 503 also stores various programs and data required for the operation of electronic device 500. Processing unit 501, ROM 502, and RAM 503 are interconnected via bus 504. Input / output (I / O) interface 505 is also connected to bus 504.
[0057] Typically, the following devices can be connected to I / O interface 505: input devices 506 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 507 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 508 including, for example, magnetic tapes, hard disks, etc.; and communication devices 509. Communication device 509 allows electronic device 500 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 5An electronic device 500 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.
[0058] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 509, or installed from a storage device 508, or installed from a ROM 502. When the computer program is executed by the processing device 501, it performs the functions defined in the methods of the embodiments of this disclosure.
[0059] In addition to the methods and devices described above, embodiments of this disclosure can also be computer program products, comprising computer program instructions that, when executed by a processor, cause the processor to perform the methods provided in the embodiments of this disclosure. The computer program product can be written in any combination of one or more programming languages to perform the operations of the embodiments of this disclosure. These programming languages include object-oriented programming languages such as Java and C++, as well as conventional procedural programming languages such as C or similar languages. The program code can be executed entirely on a user computing device, partially on a user device, as a standalone software package, partially on a user computing device and partially on a remote computing device, or entirely on a remote computing device or server.
[0060] Furthermore, embodiments of this disclosure may also be computer-readable storage media storing computer program instructions thereon, which, when executed by a processor, cause the processor to perform the permission processing method provided in embodiments of this disclosure.
[0061] The computer-readable storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.
[0062] This disclosure also provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the permission processing method in this disclosure.
[0063] It is understood that before using the technical solutions disclosed in the various embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.
[0064] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the software or hardware, such as the electronic device, application, server, or storage medium performing the operations of this disclosed technical solution, based on the prompt message.
[0065] As an optional but non-limiting implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device.
[0066] It is understood that the above notification and user authorization process are merely illustrative and do not constitute a limitation on the implementation of this disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this disclosure.
[0067] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0068] The above description is merely a specific embodiment of this disclosure, enabling those skilled in the art to understand or implement it. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims
1. A method of handling rights, characterized by The method comprises: in response to a target account triggering a permission determination event, obtaining a current account state of the target account; calling a current corresponding use permission determination rule of a target system; wherein the use permission determination rule is an adjustable rule based on at least one permission reference factor, and the at least one permission reference factor includes an account state factor; based on the account state of the target account and the use permission determination rule, generating a permission determination result corresponding to the target account; wherein the permission determination result is used to indicate whether the target account currently has the use permission of the target system; displaying interface information corresponding to the permission determination result for the target account.
2. The method of claim 1, wherein, The number of the permission reference factors is multiple; and the generating of the permission determination result corresponding to the target account based on the account state of the target account and the use permission determination rule comprises: determining a target set to which the account state of the target account belongs from a pre-set multiple account state set; determining the permission determination logic corresponding to the target set based on the use permission determination rule, and executing the permission determination logic corresponding to the target set; wherein the permission determination logic corresponding to different account state sets is different; obtaining the permission determination result corresponding to the target account based on the execution result of the permission determination logic corresponding to the target set.
3. The method of claim 2, wherein, The multiple account state sets include a first account state set, a second account state set and a third account state set; wherein if the target set is the first account state set, the permission determination logic corresponding to the target set is to determine that the target account has the use permission of the target system; if the target set is the second account state set, the permission determination logic corresponding to the target set is to determine that the target account does not have the use permission of the target system; if the target set is the third account state set, the permission determination logic corresponding to the target set includes calling information of an additional reference factor corresponding to the target account, and determining whether the target account has the use permission of the target system based on the information of the additional reference factor; the additional reference factor is another permission reference factor except the account state in the multiple permission reference factors.
4. The method of claim 3, wherein, The determining whether the target account has the use permission of the target system based on the information of the additional reference factor comprises: obtaining a reference priority corresponding to each additional reference factor, and a condition to be met by each additional reference factor; based on the order from high to low of the reference priority, checking whether the information of the additional reference factor corresponding to the target account meets the condition corresponding to the additional reference factor one by one, until all additional reference factors have been checked, or until an additional reference factor not meeting the corresponding condition is found; if no additional reference factor not meeting the corresponding condition is found, it is determined that the target account has the use permission of the target system; if an additional reference factor not meeting the corresponding condition is found, it is determined that the target account does not have the use permission of the target system.
5. The method of claim 1, wherein, The target account current account state is acquired, including: The latest state of the target account is determined based on a target message queue, and the latest state of the target account is taken as the target account current account state; wherein the target message queue is used to record account state change events.
6. The method of claim 1, wherein, The method further includes: The use permission discrimination rule corresponding to the target system is received through a visual interface of a rule configuration background, and the received use permission discrimination rule is saved to the memory of the permission discrimination engine; The use permission discrimination rule corresponding to the target system is called, and the permission discrimination result corresponding to the target account is generated based on the account state of the target account and the use permission discrimination rule, including: The use permission discrimination rule corresponding to the target system is called from the memory of the permission discrimination engine, and the permission discrimination result corresponding to the target account is generated based on the account state of the target account and the use permission discrimination rule by the permission discrimination engine.
7. The method of claim 1, wherein, The interface information corresponding to the permission discrimination result is displayed for the target account, including: If the permission discrimination result indicates that the target account has the use permission of the target system, first interface information is displayed on the user interface corresponding to the target account; wherein the first interface information includes an entry of the target system; If the permission discrimination result indicates that the target account does not have the use permission of the target system, second interface information is displayed on the user interface corresponding to the target account; wherein the second interface information does not include the entry of the target system.
8. The method according to any one of claims 1 to 7, characterized in that, The target system includes a fund custodian system; The permission reference factors further include one or more of the following: a subscription type, a project node type, a payment type, whether a service party corresponding to the target account supports the target system, regional information corresponding to the target account, and whether a project corresponding to the target account is located on a project list that unconditionally permits the use of the target system.
9. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, and the computer program is used to execute the permission processing method in any one of claims 1-8.
10. A computer program product, characterised in that, The computer program is used to implement the permission processing method in any one of claims 1-8 when executed by a processor.