Detailed Description
Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While certain embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be embodied in various forms and should not be construed as limited to the embodiments set forth herein, but rather are provided for a more complete and thorough understanding of the present disclosure. It should be understood that the drawings and embodiments of the disclosure are for illustration purposes only and are not intended to limit the scope of the disclosure.
It should be understood that the various steps recited in the method embodiments of the present disclosure may be performed in a different order, and/or performed in parallel. Moreover, method embodiments may include additional steps and/or omit performing the illustrated steps. The scope of the present disclosure is not limited in this respect.
The term "include" and variations thereof as used herein are open-ended, i.e., "including but not limited to". The term "based on" is "based, at least in part, on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Relevant definitions for other terms will be given in the following description.
It should be noted that the terms "first", "second", and the like in the present disclosure are only used for distinguishing the devices, modules or units, and are not used for limiting the devices, modules or units to be different devices, modules or units, and also for limiting the sequence or interdependence relationship of the functions executed by the devices, modules or units.
It is noted that references to "a", "an", and "the" modifications in this disclosure are intended to be illustrative rather than limiting, and that those skilled in the art will recognize that "one or more" may be used unless the context clearly dictates otherwise.
The names of messages or information exchanged between devices in the embodiments of the present disclosure are for illustrative purposes only, and are not intended to limit the scope of the messages or information.
Referring to fig. 1, the present disclosure provides a user right verification method, which is performed by a system to be verified, where the system to be verified may be a virtual server or an entity server, the system to be verified includes at least two levels of nodes, and a relationship between the nodes of each level is: if a user has an access right to a node of a certain level, the user must have an access right to a node of a previous level of the node, for example, if the user has an access right to a node of an n +1 th level, the user must have an access right to a node of the 1 st level up to the node of the n th level, where n is an integer greater than 0. Based on this, the method of the present disclosure comprises:
step S101, when an instruction of sending data corresponding to a first target node to a user is detected, acquiring a pre-cached permission verification set, wherein the permission verification set comprises user information that permission of a node of any hierarchy in a system to be verified passes verification;
when a system to be verified detects an instruction for sending data corresponding to a first target node to a user, the system to be verified acquires a pre-cached permission verification set, the first target node is a node of any hierarchy in the system to be verified, the permission verification set comprises user information that permission of the node of each hierarchy is verified to pass, the user information can be a user Identifier (ID), the permission verification set further comprises a key of each node, and a node ID of each node can be used as the key of each node.
And S102, verifying the access authority of the user based on the authority verification set to determine whether the user has the access authority of the first target node.
The system to be verified extracts necessary information required for performing authority verification on the first target node from the authority verification set based on the authority verification set, and if the user has the access authority of the node at the n +1 th level, the user necessarily has the access authority of the node at the 1 st level to the node at the n th level, that is, if the access authority of the node at any level after the first target node is present and the access authority of the first target node is necessarily present, the necessary information for performing the authority verification may be user information that the authority of the first target node has been verified and user information that the authority of the node at each level after the first target node has been verified, the number of the nodes at the level after the first target node may be one or more, and the access authority of the user is verified based on the necessary information to obtain a verification result, so as to determine whether the user has the access authority of the first target node.
It can be seen that, in this embodiment, an instruction for sending data corresponding to a first target node to a user is detected, a pre-cached permission verification set may be obtained, the permission verification set includes user information that permission of a node of any level in a system to be verified passes verification, so that access permission of the user may be verified based on the permission verification set, and whether the user has access permission of the first target node is determined.
Optionally, the instructions include at least one of:
data feedback instructions in response to the user access request;
and data feedback instructions triggered by data updating events.
In this embodiment, the instruction may be a data feedback instruction in response to the user access request, that is, when the system to be verified receives an access request from a user to access the first target node, the system to be verified verifies the access right of the user to the first target node; the instruction may also be a data feedback instruction triggered by a data update event, that is, after the data of the first target node is updated, the system to be verified verifies the access authority of the user for the first target node, and after the verification is passed, the updated data of the first target node is sent to the user.
Optionally, verifying the access right of the user based on the right verification set to determine whether the user has the access right of the first target node, including:
verifying the access authority of the user based on the user information which is included in the authority verification set and passes the authority verification aiming at the first target node;
if the verification result is that the user has the access right of the first target node, outputting the verification result;
if the verification result is that the user does not have the access authority of the first target node, judging whether the first target node is the node of the lowest level;
if the first target node is the node of the lowest level, outputting a verification result;
and if the first target node is not the node of the lowest hierarchy, taking the node of the next hierarchy of the first target node as the first target node, executing the step of verifying the access authority of the user based on the user information of the first target node in the authority verification set until a verification result is output or the first target node is determined to be the node of the lowest hierarchy.
In this embodiment, a specific process of the system to be verified verifying whether the user has the access right of the first target node is shown in fig. 2, and includes:
step S201, verifying whether a user has the access authority of the first target node or not based on the user information which is included in the authority verification set and passes the authority verification aiming at the first target node;
step S202, if the verification result is that the user has the access authority of the first target node, outputting the verification result;
when the system to be verified verifies whether the user has the right of the first target node, the node id of the first target node may be used as a key, the system to be verified acquires the key and the user id from the user (as described above, if the system to be verified receives the user access request, the access request carries the key and the user id, if the first target node of the system to be verified has data update, the system to be verified actively acquires the key and the user id from the user), based on the key and the user id of the user, the system to be verified determines user information corresponding to the same key in the pre-cached right verification set, the user information is user information that the right of the first target node passes verification, whether the user id is stored in the user information that the right of the first target node passes verification is determined, if the user id is stored, the user passes verification, the user has the access right of the first target node, and the system to be verified directly outputs a verification result.
Step S203, if the verification result shows that the user does not have the access authority of the first target node, judging whether the first target node is the node of the lowest level;
if the user id is not stored in the user information that the authority of the first target node is verified, the verification fails, and the user does not have the access authority of the first target node, further, the system to be verified judges whether the first target node is a node of the lowest hierarchy, the node of the lowest hierarchy may also be referred to as a node of the last hierarchy, for example, if the system to be verified has m hierarchies, the node of the lowest hierarchy is a node of the mth hierarchy, and m is an integer greater than 0.
Step S204, if the first target node is the node of the lowest level, outputting a verification result;
if the first target node is the node of the lowest hierarchy, the system to be verified directly outputs the verification result whether the verification is passed or not, and the verification result can be verification success or verification failure in this case.
Step S205, if the first target node is not the node of the lowest hierarchy, taking the node of the next hierarchy of the first target node as the first target node, returning to step S201, and performing the step of verifying the access right of the user based on the user information of the first target node in the right verification set until the verification result is output or the first target node is determined to be the node of the lowest hierarchy.
If the first target node is not the node of the lowest hierarchy, further determining whether the user has the access right of the node of the next hierarchy of the first target node, and if the user has the access right of the node of the next hierarchy, the user must have the access right of the first target node, specifically, the system to be verified may take the node of the next hierarchy of the first target node as the first target node, return to step S201, thereby repeatedly executing the processes of step S201 to step S205 until the verification result obtained by verification is that the user has the access right of the first target node, or stop the cycle until the first target node is determined to be the node of the lowest hierarchy.
Optionally, the nodes of at least two levels include: the node OKR node of the first level, the node Objective node of the second level, and the node Key Result node of the third level.
In this embodiment, the system to be verified may be a target and Key achievement method (objections and Key Results, OKR) system, and the OKR system includes a first-level node OKR, a second-level node Objective node, and a third-level node Key Result, where authority relationships among the nodes are as shown in fig. 3, N objection nodes are located under OKR, N Key Result nodes are located under objection nodes, authority verification of the N objection nodes is performed after authority verification of the OKR node is completed, and authority verification of the N Result nodes is performed after authority verification of the objection node Key Result is completed. When the authority verification is carried out on any node, the user information of which the authority of each node passes the verification is cached in advance, so that the authority verification can be started at any node through cached data, and the authority verification is not required to be carried out on nodes before any node, and on the basis, the method has the following possible application scenes:
1. verifying user's authority to OKR node
When data of a OKR node needs to be pushed to a user after being updated, or when a OKR node receives a user access request, the access right of the user is verified through a pre-cached right verification set, the right verification set is stored in a Redis database, and the right verification set can also be called a Redis set.
The first step is as follows: searching a Redis set taking the id of the OKR node as key, wherein the Redis set is a Redis set of OKR node, and storing user information that the authority of the OKR node passes verification;
a. if the user id is in the Redis set, the authority verification is passed, and the verification result is output as that the user has the access authority of OKR nodes;
b. otherwise, carrying out the next step;
the second step is that: traversing all the Objective nodes (the number of the Objective nodes can be one or more) under the OKR node, and for any Objective node, searching a Redis set taking id of OKR node as key, wherein the Redis set is the Redis set of the Objective node, and the Redis set stores user information that the authority of the Objective node passes verification;
a. if the user id is in the Redis set corresponding to any Objective node, the permission verification is passed, and the verification result is output as that the user has the access permission of OKR nodes;
b. otherwise, carrying out the next step;
the third step: traversing all Key Result nodes (the number of the Key Result nodes can be one or more than one) under the Objective node, and for any Key Result node, searching a Redis set taking the id of the Key Result node as a Key, wherein the Redis set is the Redis set of the Key Result node, and the Redis set stores user information that the authority of the Key Result node passes verification;
a. if the user id is in a Redis set corresponding to any Key Result node, the permission verification is passed, and the verification Result is output as that the user has the access permission of OKR nodes;
b. otherwise, the verification result is output that the user does not have the access authority of the OKR node.
2. Verifying user's rights to Objective node
When data of the Objective node needs to be pushed to a user after being updated, or when the Objective node receives a user access request, the access permission of the user is verified through a pre-cached permission verification set, the permission verification set is stored in a Redis database, and the permission verification set can also be called a Redis set.
The first step is as follows: searching a Redis set taking the id of the Objective node as a key, wherein the Redis set is the Redis set of the Objective node and stores user information of which the authority of the Objective node is verified;
a. if the user id is in the Redis set, the permission verification is passed, and the verification result is output as the access permission of the Objective node of the user;
b. otherwise, carrying out the next step;
the second step is that: traversing all Key Result nodes (the number of the Key Result nodes can be one or more than one) under the Objective node, and for any Key Result node, searching a Redis set taking the id of the Key Result node as a Key, wherein the Redis set is the Redis set of the Key Result node, and the Redis set stores user information that the authority of the Key Result node passes verification;
a. if the user id is in a Redis set corresponding to any Key Result node, the permission verification is passed, and the verification Result is output as the access permission of the user with the Objective node;
b. otherwise, outputting a verification result that the user does not have the access authority of the Objective node;
3. verifying user authority to Key Result node
When data of the Key Result node needs to be pushed to a user after being updated, or when the Key Result node receives a user access request, the access right of the user is verified through a pre-cached right verification set, the right verification set is stored in a Redis database, and the right verification set can also be called a Redis set.
Searching a Redis set taking the id of the Key Result node as a Key, wherein the Redis set is the Redis set of the Key Result node and stores user information that the authority of the Key Result node passes verification;
a. if the user id is in the Redis set, the authority verification is passed, and the access authority of the user with a Key Result node is output;
b. otherwise, outputting the verification Result that the user does not have the access authority of the Key Result node.
As mentioned above, when any node in the system to be verified is verified, the authority verification can be performed only on part of the OKR node, the Objective node and the Key Result node, the authority verification can be performed in real time while the data of each node is safely displayed to the user, and the time for the authority verification is reduced, so that the time delay for the user to obtain the node data in the system to be verified is reduced, and the time delay can be controlled within millisecond level. Specific experiments show that the time delay of the authority verification can be controlled within 10 ms.
Optionally, before obtaining the pre-cached permission verification set, the method further includes:
receiving an authority verification request from at least one user, and performing authority verification on nodes of corresponding levels based on key information aiming at nodes of at least one level of a system to be verified, which is carried in the authority verification request, so as to obtain a verification result;
and storing the user information which passes the verification of the authority of the node of at least one hierarchy in the verification result.
Optionally, after storing the user information in the verification result that the authority of the node for at least one hierarchy has been verified, the method further includes:
and receiving an authority verification updating message, and updating the user information of which the authority of the node of at least one hierarchy is verified based on the authority verification updating message.
In this embodiment, the set of rights verifications is obtained by:
the method comprises the steps that a system to be verified receives an authority verification request from at least one user, for one user, the authority verification request of the user carries Key information aiming at nodes of at least one hierarchy in the system to be verified, the Key information comprises Key values and value values, the nodes of all hierarchies are subjected to authority configuration in advance, the Key values and the value values are also configured, the system to be verified conducts authority verification on the nodes of the corresponding hierarchy through the Key information, namely whether the value values corresponding to the Key values of the nodes are changed or not is verified, a verification Result can be obtained, if the value values are not changed, the verification Result is verification passing, the user information of the user is used as user information with the authority verified passing, the user information is stored in a redis set of the nodes of the corresponding hierarchy, for example, the Key information is the Key information of a Reskey ult node, if the authority verification is conducted on the basis of the Key information, the user is indicated that the user has the access authority of the Key Result node, and the user information of the user is stored in the redis set corresponding to the Key Result node.
In this embodiment, the authentication of the user Key information may be based on the authority configuration of OKR node, objective node and Key Result node, and the authentication Result is returned, the data format of the returned event for the initial authentication of authority is as shown in fig. 4 (only the node id and the user id that the user has access authority are returned), and the explanation about the fields in fig. 4 is as follows:
the following OKR is OKR node, objective is Objective node, and Key Result is Key Result node.
self _ permission, which indicates whether the viewing right of the current field is given from itself or from a next level object (the next level object is a node of the next level). In the example, if self _ permission of obj _1 (obj _1 is the node id of the Objective node) is false, it means that the user has the right to view obj _1 (i.e. has the right to view the data of the Objective node), but the right comes not from obj _1 itself, but because the user has the right to view kr _1 (kr _1 is the node id of the Key Result node), and kr _1 is the node id of the Key Result node associated with the object _1 lower level, the user must have the right to view obj _1 (i.e. the user has the access right of the Key Result node, and thus has the access right of the Objective node).
Because the Key Result has no object at the next level, the viewing authority of the Key Result comes from itself completely, so there is no "self _ permission" field in the Key Result, or specifically, self _ permission = true for all authorities of the Key Result.
In this embodiment, each node is traversed to determine the verification result, and the object with self _ permission is cached:
the authority of the buffer OKR node is verified to pass the user information, namely the id of the OKR node is taken as key, and the user id of the user is added into the set of Redis;
the permission of the caching Objective node is verified to pass through user information, namely the id of the Objective node is taken as a key, and the user id of the user is added into a set of Redis;
the authority of the caching Key Result node is verified to pass user information, namely the id of the Key Result node is taken as a Key, and the user id of the user is added into a set of Redis.
In this implementation, after the user information of at least one user that passes the verification is stored in the corresponding redis set, the stored user information may also be updated, so the permission verification set may also be obtained after the user information is updated, and the system to be verified may receive the permission update message, so that the user information that the permission of the node of one or more levels passes the verification is updated based on the permission update message, specifically, the updating process is as follows:
optionally, the user information that the authority of the node in at least one hierarchy is verified to pass is updated based on the authority verification update message, and the method includes at least one of the following steps:
if the authority verification updating message comprises an authority canceling message of any user aiming at the second target node, based on the authority canceling message, deleting the stored user information of any user aiming at the second target node and having the authority verified;
and if the permission verification updating message comprises a permission verification passing message of any user for the third target node, newly adding and storing the user information of any user for which the permission of the third target node is verified based on the permission verification passing message.
In this embodiment, if the update message includes an authority cancel message of any user for the second target node, the authority cancel message includes a key of the second target node and a user id of any user, and the system to be authenticated searches, based on the key, a user id whose authority has been authenticated and passes corresponding to the same key in the authority authentication set, and deletes the user id of any user stored in the user id whose authority has been authenticated and passes, for example, may cancel the authority of a user of a certain user in the users whose authority has been authenticated and passes OKR node.
If the update message includes an authority verification passing message of any user for the third target node, the authority verification passing message includes a key of the third target node and a user id of any user, the system to be verified searches the user id of which the authority is verified and passes corresponding to the same key in the authority verification set based on the key, and newly adds and stores the user id of any user for which the authority of the third target node is verified, so that the user id of any user is added into the user id of which the authority of the third target node is verified and passes, for example, the user id of a certain user can be added into the user id of which the authority of the OKR node is verified and passes.
In this embodiment, when the authority of the OKR node, objective node or Key Result node changes, for example, when the owner of the OKR node changes the authority configuration, it is necessary to record the authority change in real time. Thus, from the point of time when the rights are changed, any real-time information push of the OKR node or user access to the OKR node can verify the user's access rights in real time. The data format of the system to be verified for the user right update event is shown in fig. 5:
the fields in fig. 5 are explained as follows:
target _ type, which is an object whose authority has been changed, "1" indicates the authority change of OKR node, "2" indicates the authority change of Objective node, and "3" indicates the authority change of Key Result node.
okr _ id — id of OKR node of the rights change object, if target _ type is "2" or "3", it indicates id of OKR node associated with Objective node or Key Result node, respectively.
object _ id — the id of the object node of the rights change object, and if the target _ type is "1", this field is empty, and if the target _ type is "3", this field indicates the id of the object node associated with the Key Result node.
Key _ Result _ id — id of Key Result node of rights change object, and if target _ type is "1" or "2", this field is left blank.
add _ user _ id _ l ist — list of user ids to which viewing rights are newly assigned.
remove _ user _ id _ list — list of user ids with viewing rights revoked.
In the following, the embodiments of permission update are described with reference to specific application scenarios:
1. permission to update OKR node (OKR in this embodiment is OKR node)
When the tartget _ type is "1", updating the permission configuration of OKR;
acquiring the current user set OKR under monitoring, and setting the user set as S1;
parsing add _ user _ id _ list (corresponding to the above-mentioned permission verification pass message) in the permission update data (i.e. update message), and formatting into a user set A1;
parsing remove _ user _ id _ list (corresponding to the above-mentioned permission cancellation message) in the permission update data, and formatting into a user set R1;
then the newly added set of users with permission to view U1= S1 ≠ A1 (i.e. increases the access permission of U1 to OKR nodes);
then the set of revoked users without permission to view U2= S1 andbr1 (i.e., revoke U2' S access permission to OKR node);
obtain the user set U3 currently having the right to view the OKR;
then the new set of users U4= (U1 utou3) -U2 that have the right to view that OKR;
u4 is added to the set of Redis of OKR with the node id of OKR as key.
2. Permission of update Objective node (Objective in this embodiment is Objective node)
When the target _ type is "2", update the permission configuration of Objective;
acquiring a user set OKR associated with the current Objective being listened to, and setting the user set to S1;
parsing add _ user _ id _ list (corresponding to the above-mentioned permission verification pass message) in the permission update data (i.e. update message), and formatting into a user set A1;
parsing remove _ user _ id _ list (corresponding to the above-mentioned permission cancellation message) in the permission update data, and formatting into a user set R1;
then the newly added set of users with permission to view U1= S1 ≧ A1 (i.e., the access permission of U1 to the Objective node is added);
then the set of revoked users without permission to view U2= S1 ≦ R1 (i.e., revoke U2' S access permission to Objective nodes);
obtain the set U3 of users currently having the right to view the Objective;
then the new set of users U4= (U1 utou3) -U2 that have access to view that Objective;
add U4 to the set of Objective Redis with Objective id as key.
3. Permission of updating Key Result node (Key Result in this implementation is Key Result node)
When the tartget _ type is "3", the authority configuration of Key Result is updated;
acquiring a user set of OKR associated with the current Key Result being listened to, and setting the user set as S1;
parsing add _ user _ id _ list (corresponding to the above-mentioned permission verification pass message) in the permission update data (i.e. update message), and formatting into a user set A1;
parsing remove _ user _ id _ list (corresponding to the above-mentioned permission cancellation message) in the permission update data, and formatting into a user set R1;
then the newly added set of users with permission to view U1= S1 ≧ A1 (i.e. the access permission of U1 to Key Result node is added);
then the set of revoked users without permission to view U2= S1 ≠ R1 (i.e. revoke U2' S access to Key Result node);
obtaining a set U3 of users currently having authority to view the Key Result;
then the new user set U4= (U1 utou 3) -U2 that has the right to view the Key Result;
and taking the id of the Key Result as a Key, and adding the U4 into the set of the Redis.
It can be seen that, in this embodiment, the user information whose authority has been verified in any node in the system to be verified can be updated, so that the access authority of the user for each node in the system to be verified can be adjusted, and meanwhile, the update of the user information of the present disclosure can be directly positioned to the OKR node, the bjective node, or the Key Result node to update the user information whose authority has been verified, so that the authority configuration in each node can be updated in real time, the update speed is also fast, and the update delay can be controlled within millisecond level. Specific experiments show that the time delay of the user authority updating in the method can be controlled within 10 ms.
Fig. 6 is a schematic structural diagram of a user right verification apparatus provided in an embodiment of the present disclosure, where the apparatus includes at least two levels of nodes, and as shown in fig. 6, the apparatus in an embodiment of the present disclosure may include:
an obtaining module 601, configured to obtain a pre-cached permission verification set when detecting an instruction for sending data corresponding to a first target node to a user, where the permission verification set includes user information that permission of a node in any hierarchy in a system to be verified has passed verification;
and the permission verification module 602 is configured to verify the access permission of the user based on the permission verification set to determine whether the user has the access permission of the first target node.
Optionally, the instructions include at least one of:
data feedback instructions in response to the user access request;
and data feedback instructions triggered by data updating events.
Optionally, the permission verification module 602 is specifically configured to:
verifying the access authority of the user based on the user information which is included in the authority verification set and passes the authority verification aiming at the first target node;
if the verification result is that the user has the access right of the first target node, outputting the verification result;
if the verification result indicates that the user does not have the access authority of the first target node, judging whether the first target node is the node of the lowest level;
if the first target node is the node of the lowest level, outputting a verification result;
and if the first target node is not the node of the lowest hierarchy, taking the node of the next hierarchy of the first target node as the first target node, executing the step of verifying the access authority of the user based on the user information of the first target node in the authority verification set until a verification result is output or the first target node is determined to be the node of the lowest hierarchy.
Optionally, the apparatus further comprises a receiving module and a storage module;
before the obtaining module 601 obtains the pre-cached permission verification set, the receiving module is configured to receive a permission verification request from at least one user, perform permission verification on a node of a corresponding hierarchy based on key information, which is carried in the permission verification request and is specific to the node of at least one hierarchy of the system to be verified, and obtain a verification result;
and the storage module is used for storing the user information which passes the verification of the authority of the node of at least one hierarchy in the verification result.
Optionally, the apparatus further includes an updating module, where after the storage module stores the user information that the authority of the node in the at least one hierarchy in the verification result is verified, the updating module is configured to receive the authority verification updating message, and update the user information that the authority of the node in the at least one hierarchy is verified based on the authority verification updating message.
Optionally, the update module is specifically configured to perform at least one of the following operations:
if the authority verification updating message comprises an authority canceling message of any user aiming at the second target node, based on the authority canceling message, deleting the stored user information that the authority of any user aiming at the second target node is verified;
and if the permission verification updating message comprises a permission verification passing message of any user aiming at the third target node, newly adding and storing the user information of any user aiming at the third target node, wherein the permission verification passing message of any user aims at the third target node.
Optionally, the nodes of at least two levels include: the node OKR node of the first level, the node Objective node of the second level, and the node Key Result node of the third level.
Referring now to FIG. 7, a schematic diagram of an electronic device (e.g., the system under verification of FIG. 1) 600 suitable for use in implementing embodiments of the present disclosure is shown. The system to be authenticated in the embodiments of the present disclosure may be applied to mobile terminals such as mobile phones, notebook computers, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., car navigation terminals), and the like, and fixed terminals such as digital TVs, desktop computers, and the like. The electronic device shown in fig. 7 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present disclosure.
The electronic device includes: a memory and a processor, wherein the processor may be referred to as the processing device 601 hereinafter, and the memory may include at least one of a Read Only Memory (ROM) 602, a Random Access Memory (RAM) 603 and a storage device 608 hereinafter, which are specifically shown as follows:
as shown in fig. 7, the electronic device 600 may include a processing means (e.g., central processing unit, graphics processor, etc.) 601 that may perform various appropriate actions and processes in accordance with a program stored in a Read Only Memory (ROM) 602 or a program loaded from a storage means 608 into a Random Access Memory (RAM) 603. In the RAM 603, various programs and data necessary for the operation of the electronic apparatus 600 are also stored. The processing device 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input/output (I/O) interface 605 is also connected to bus 604.
Generally, the following devices may be connected to the I/O interface 605: input devices 606 including, for example, a touch screen, touch pad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, or the like; output devices 607 including, for example, a Liquid Crystal Display (LCD), a speaker, a vibrator, and the like; storage 608 including, for example, tape, hard disk, etc.; and a communication device 609. The communication means 609 may allow the electronic device 600 to communicate with other devices wirelessly or by wire to exchange data. While fig. 7 illustrates an electronic device 600 having various means, it is to be understood that not all illustrated means are required to be implemented or provided. More or fewer devices may alternatively be implemented or provided.
In particular, the processes described above with reference to the flow diagrams may be implemented as computer software programs, according to embodiments of the present disclosure. For example, embodiments of the present disclosure include a computer program product comprising a computer program carried on a non-transitory computer readable medium, the computer program containing program code for performing the method illustrated by the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network via the communication means 609, or may be installed from the storage means 608, or may be installed from the ROM 602. The computer program, when executed by the processing device 601, performs the above-described functions defined in the methods of the embodiments of the present disclosure.
It should be noted that the computer readable medium of the present disclosure may be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present disclosure, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In contrast, in the present disclosure, a computer readable signal medium may comprise a propagated data signal with computer readable program code embodied therein, either in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: electrical wires, optical cables, RF (radio frequency), etc., or any suitable combination of the foregoing.
In some embodiments, the clients, servers may communicate using any currently known or future developed network Protocol, such as HTTP (HyperText Transfer Protocol), and may interconnect with any form or medium of digital data communication (e.g., a communications network). Examples of communication networks include a local area network ("LAN"), a wide area network ("WAN"), the Internet (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future developed network.
The computer readable medium may be embodied in the electronic device; or may exist separately without being assembled into the electronic device.
The computer readable medium carries one or more programs which, when executed by the electronic device, cause the electronic device to: when an instruction of sending data corresponding to a first target node to a user is detected, acquiring a pre-cached permission verification set, wherein the permission verification set comprises user information that permission of a node of any hierarchy in a system to be verified passes verification; and verifying the access right of the user based on the right verification set to determine whether the user has the access right of the first target node.
Computer program code for carrying out operations for the present disclosure may be written in any combination of one or more programming languages, including but not limited to an object oriented programming language such as Java, smalltalk, C + +, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider).
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The modules or units described in the embodiments of the present disclosure may be implemented by software or hardware. Where the name of a module or unit does not in some cases constitute a limitation on the unit itself, for example, the retrieving module may also be described as a "module that retrieves a pre-cached set of authentication permissions".
The functions described herein above may be performed, at least in part, by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: field Programmable Gate Arrays (FPGAs), application Specific Integrated Circuits (ASICs), application Specific Standard Products (ASSPs), system on a chip (SOCs), complex Programmable Logic Devices (CPLDs), and the like.
In the context of this disclosure, a machine-readable medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
According to one or more embodiments of the present disclosure, a method for verifying user rights is provided, where the method is applied to a system to be verified, and the system to be verified includes at least two levels of nodes, and the method includes:
when an instruction of sending data corresponding to a first target node to a user is detected, acquiring a pre-cached permission verification set, wherein the permission verification set comprises user information that permission of a node of any hierarchy in a system to be verified passes verification;
and verifying the access right of the user based on the right verification set to determine whether the user has the access right of the first target node.
Optionally, the instructions include at least one of:
data feedback instructions in response to the user access request;
and data feedback instructions triggered by data updating events.
Optionally, verifying the access right of the user based on the right verification set to determine whether the user has the access right of the first target node, including:
verifying the access authority of the user based on the user information which is included in the authority verification set and passes the authority verification aiming at the first target node;
if the verification result is that the user has the access right of the first target node, outputting the verification result;
if the verification result indicates that the user does not have the access authority of the first target node, judging whether the first target node is the node of the lowest level;
if the first target node is the node of the lowest level, outputting a verification result;
and if the first target node is not the node of the lowest hierarchy, taking the node of the next hierarchy of the first target node as the first target node, executing the step of verifying the access authority of the user based on the user information of the first target node in the authority verification set until a verification result is output or the first target node is determined to be the node of the lowest hierarchy.
Optionally, before obtaining the pre-cached permission verification set, the method further includes:
receiving an authority verification request from at least one user, and performing authority verification on nodes of corresponding levels based on key information aiming at nodes of at least one level of a system to be verified, which is carried in the authority verification request, so as to obtain a verification result;
and storing the user information which passes the verification of the authority of the node of at least one hierarchy in the verification result.
Optionally, after storing the user information in the verification result that the authority of the node for at least one hierarchy has been verified, the method further includes:
and receiving an authority verification updating message, and updating user information of which the authority of the node of at least one hierarchy is verified based on the authority verification updating message.
Optionally, the user information that the authority of the node in at least one hierarchy is verified to pass is updated based on the authority verification update message, and the method includes at least one of the following steps:
if the authority verification updating message comprises an authority canceling message of any user aiming at the second target node, based on the authority canceling message, deleting the stored user information that the authority of any user aiming at the second target node is verified;
and if the permission verification updating message comprises a permission verification passing message of any user for the third target node, newly adding and storing the user information of any user for which the permission of the third target node is verified based on the permission verification passing message.
Optionally, the nodes of at least two levels include: the node OKR node of the first level, the node Objective node of the second level, the node Key Result node of the third level.
According to one or more embodiments of the present disclosure, there is also provided a user right verification apparatus including at least two hierarchical levels of nodes, the apparatus of an embodiment of the present disclosure may include:
the acquisition module is used for acquiring a pre-cached permission verification set when an instruction of sending data corresponding to a first target node to a user is detected, wherein the permission verification set comprises user information that permission of a node of any hierarchy in a system to be verified passes verification;
and the permission verification module is used for verifying the access permission of the user based on the permission verification set so as to determine whether the user has the access permission of the first target node.
Optionally, the instructions include at least one of:
data feedback instructions in response to the user access request;
and data feedback instructions triggered by data updating events.
Optionally, the permission verification module is specifically configured to:
verifying the access authority of the user based on the user information which is included in the authority verification set and passes the authority verification aiming at the first target node;
if the verification result is that the user has the access right of the first target node, outputting the verification result;
if the verification result indicates that the user does not have the access authority of the first target node, judging whether the first target node is the node of the lowest level;
if the first target node is the node of the lowest level, outputting a verification result;
and if the first target node is not the node of the lowest hierarchy, taking the node of the next hierarchy of the first target node as the first target node, executing the step of verifying the access authority of the user based on the user information of the first target node in the authority verification set until a verification result is output or the first target node is determined to be the node of the lowest hierarchy.
Optionally, the apparatus further comprises a receiving module and a storage module;
before the obtaining module obtains the pre-cached permission verification set, the receiving module is used for receiving a permission verification request from at least one user, and performing permission verification on nodes of a corresponding hierarchy based on key information aiming at nodes of at least one hierarchy of the system to be verified, which is carried in the permission verification request, so as to obtain a verification result;
and the storage module is used for storing the user information which passes the verification of the authority of the node of at least one hierarchy in the verification result.
Optionally, the apparatus further includes an updating module, where after the storage module stores the user information that the authority of the node in the at least one hierarchy in the verification result is verified, the updating module is configured to receive the authority verification updating message, and update the user information that the authority of the node in the at least one hierarchy is verified based on the authority verification updating message.
Optionally, the update module is specifically configured to perform at least one of the following operations:
if the authority verification updating message comprises an authority canceling message of any user aiming at the second target node, based on the authority canceling message, deleting the stored user information of any user aiming at the second target node and having the authority verified;
and if the permission verification updating message comprises a permission verification passing message of any user aiming at the third target node, newly adding and storing the user information of any user aiming at the third target node, wherein the permission verification passing message of any user aims at the third target node.
Optionally, the nodes of at least two levels include: the node OKR node of the first level, the node Objective node of the second level, and the node Key Result node of the third level.
The foregoing description is only exemplary of the preferred embodiments of the disclosure and is illustrative of the principles of the technology employed. It will be appreciated by those skilled in the art that the scope of the disclosure herein is not limited to the particular combination of features described above, but also encompasses other embodiments in which any combination of the features described above or their equivalents does not depart from the spirit of the disclosure. For example, the above features and (but not limited to) the features disclosed in this disclosure having similar functions are replaced with each other to form the technical solution.
Further, while operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order. Under certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are included in the above discussion, these should not be construed as limitations on the scope of the disclosure. Certain features that are described in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.