CN109472127B - Authority processing method and device, application side equipment and storage medium - Google Patents

Authority processing method and device, application side equipment and storage medium Download PDF

Info

Publication number
CN109472127B
CN109472127B CN201811184754.1A CN201811184754A CN109472127B CN 109472127 B CN109472127 B CN 109472127B CN 201811184754 A CN201811184754 A CN 201811184754A CN 109472127 B CN109472127 B CN 109472127B
Authority
CN
China
Prior art keywords
authority
identifier
permission
user
application
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201811184754.1A
Other languages
Chinese (zh)
Other versions
CN109472127A (en
Inventor
汪南
孙浩庭
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Sankuai Online Technology Co Ltd
Original Assignee
Beijing Sankuai Online Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Sankuai Online Technology Co Ltd filed Critical Beijing Sankuai Online Technology Co Ltd
Priority to CN201811184754.1A priority Critical patent/CN109472127B/en
Publication of CN109472127A publication Critical patent/CN109472127A/en
Priority to CA3058061A priority patent/CA3058061A1/en
Application granted granted Critical
Publication of CN109472127B publication Critical patent/CN109472127B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/45—Structures or tools for the administration of authentication

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)

Abstract

The embodiment of the disclosure discloses a permission processing method, a permission processing device, application side equipment and a storage medium. The method comprises the following steps: responding to an access request of a user, and determining an expected authority identifier of the user; calling an application authority control system, and inquiring whether a mapping relation between a user and an expected authority identifier exists in the application authority control system, wherein the application authority control system stores a first mapping relation between the user and the authority identifier; responding to the mapping relation between the user and the expected authority identification in the first mapping relation, and acquiring the authority identification corresponding to the user in the first mapping relation; and determining the components displayed by the client and/or the interface which can be called based on the authority identification corresponding to the user in the first mapping relation and the minimum requirement authority identification of the client. The technical scheme of the embodiment of the disclosure can avoid the situation that the service which is not in accordance with the maintained authority is provided for the user.

Description

Authority processing method and device, application side equipment and storage medium
Technical Field
The present disclosure relates to the field of electronic information, and in particular, to a method and an apparatus for processing a permission, an application side device, and a storage medium.
Background
A single page application is a special web application. A single page application confines all referenced activities to one web page. Only when the web page is initialized, corresponding hypertext Markup Language (HTML), JavaScript (JavaScript), Cascading Style Sheets (CSSs), and the like are loaded. Once the network page is connected to the completion, the single-page application does not perform reloading or jumping of the page due to the operation of the user. Due to the fact that reloading of the page is avoided, operation is smoother, and the application range of single-page application is wider and wider.
Disclosure of Invention
The embodiment of the disclosure provides a permission processing method and device, application side equipment and a storage medium, which can avoid the situation that a service which does not conform to the maintained permission is provided for a user.
In a first aspect, an embodiment of the present disclosure provides an authority processing method, including: responding to an access request of a user, and determining an expected authority identifier of the user, wherein the expected authority identifier is an authority identifier corresponding to the authority expected by the user; calling an application authority control system, and inquiring whether a mapping relation between a user and an expected authority identifier exists in the application authority control system, wherein the application authority control system stores a first mapping relation between the user and the authority identifier; responding to the mapping relation between the user and the expected authority identification in the first mapping relation, and acquiring the authority identification corresponding to the user in the first mapping relation, wherein the authority identification corresponding to the user in the acquired first mapping relation comprises the expected authority identification; and determining the components displayed by the client and/or the interface which can be called based on the authority identification corresponding to the user in the first mapping relation and the minimum requirement authority identification of the client.
In a second aspect, an embodiment of the present disclosure provides an authority processing apparatus, including: the response module is used for responding to the access request of the user and determining the expected authority identification of the user, wherein the expected authority identification is the authority identification corresponding to the authority expected by the user; the authority control calling module is used for calling an application authority control system, inquiring whether a mapping relation between a user and an expected authority identifier exists in the application authority control system, and storing a first mapping relation between the user and the authority identifier in the application authority control system; the authority identifier acquisition module is used for responding to the mapping relation between the user and the expected authority identifier in the first mapping relation, acquiring the authority identifier corresponding to the user in the first mapping relation, wherein the acquired authority identifier corresponding to the user in the first mapping relation comprises the expected authority identifier; and the determining module is used for determining the displayed component and/or the interface which can be called based on the authority identification corresponding to the user in the first mapping relation and the minimum requirement authority identification of the client.
In a third aspect, an embodiment of the present disclosure provides an application-side device, where the application-side device includes: a memory and a processor; the memory is used for storing executable program codes; the processor is configured to read the executable program code stored in the memory to execute the permission processing method in the technical solution of the first aspect.
In a fourth aspect, the disclosed embodiments provide a storage medium having stored thereon computer program instructions; the computer program instructions, when executed by the processor, implement the method for processing permissions in the technical solutions of the first aspect.
The embodiment of the disclosure provides a permission processing method, a permission processing device, application side equipment and a storage medium, wherein a client can respond to an access request sent by a user and determine an expected permission identifier of the user according to the access request. And calling an application authority system, and inquiring whether a mapping relation between the user and the expected authority identifier exists in a first mapping relation between the user and the authority identifier stored in the application authority control system. And responding to the mapping relation between the user and the expected authority identification in the application authority control system, and indicating that the authority corresponding to the expected authority identification is allowed for the user. The component exposed at the front end of the application and/or the interface which can be called by the background of the application can be determined based on the permission identifier corresponding to the permitted permission of the user and the minimum requirement permission identifier. In the case of maintaining the authority of the user (which may include adding the authority, deleting the authority, changing the authority, etc.), only the first mapping relationship between the user and the authority identifier stored in the application authority control system needs to be maintained. When a user sends an access request, the application authority control system is called, the first mapping relation after maintenance is inquired, and the service which accords with the authority after maintenance is provided for the user, so that the condition that the service which does not accord with the authority after maintenance is provided for the user is avoided.
Drawings
The present disclosure may be better understood from the following description of specific embodiments thereof taken in conjunction with the accompanying drawings, in which like or similar reference numerals identify like or similar features.
FIG. 1 is a schematic diagram of a scenario involved in a single-page application in an embodiment of the present disclosure;
FIG. 2 is a flowchart illustrating a method for privilege processing according to an embodiment of the present disclosure;
FIG. 3 is a flow chart of a method of privilege processing in another embodiment of the present disclosure;
FIG. 4 is a schematic structural diagram of a privilege processing apparatus according to an embodiment of the present disclosure;
fig. 5 is a block diagram of an exemplary hardware architecture of an application-side device in an embodiment of the present disclosure.
Detailed Description
Features and exemplary embodiments of various aspects of the present disclosure will be described in detail below. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. It will be apparent, however, to one skilled in the art, that the present disclosure may be practiced without some of these specific details. The following description of the embodiments is merely intended to provide a better understanding of the present disclosure by illustrating examples of the present disclosure. The present disclosure is in no way limited to any specific configuration and algorithm set forth below, but rather covers any modifications, substitutions, and alterations of elements, components, and algorithms without departing from the spirit of the present disclosure. In the drawings and the following description, well-known structures and techniques are not shown in order to avoid unnecessarily obscuring the present disclosure.
The embodiment of the disclosure provides an authority processing method, an authority processing system, an authority processing device and a storage medium, which can be applied to various single-page applications for providing different authorities for different users. For example, the method can be applied to a management and control platform, an advertisement putting platform and the like. When different users log in the single-page application and perform various accesses, the service under the authority can be provided for the users according to the authority of the users, and unauthorized access is avoided.
Fig. 1 is a schematic view of a scene involved in a single-page application in an embodiment of the present disclosure. As shown in fig. 1, a single page application involves a client 10 and an application rights control system 11. The client may be a program that locally provides a service for the user, or may be an application-side device that locally installs a service for the user, which is not limited herein. Wherein the client 10 may invoke the application right control system 11. In some examples, client 10 may include an application front-end 101 and an application back-end 102. The application front end 101 is mainly responsible for displaying pages of an application, and may display various components, such as sidebars, pictures, floating windows, tables, linked drop-down boxes, and the like, where the types and the number of the components are not limited herein. The Application background 102 may provide a calling Interface for the Application front end 101, such as an Application Programming Interface (API) corresponding to a component calling the Application front end 101. The application authority control system 11 stores a first mapping relationship between a user and an authority identifier. The rights identification is used to identify the rights. The rights may include a preview right, a read right, a write right, a delete right, etc., and the kind of the rights is not limited herein. The permissions have different heights, for example, the permissions include a preview permission, a read permission, a write permission and a delete permission, and the previewing permission, the read permission, the write permission and the delete permission can be arranged in the sequence from low to high. Permissions and permission identities for components of the application front-end may also be defined. For example, the rights identifications of the read rights of different components are different. The permission of the component can be preset according to specific situations, for example, the reading permission of the table is higher than that of the picture. For the convenience of comparing the rights, the rights identifier may also reflect the height of the rights, and the specific content will be described later.
Fig. 2 is a flowchart of a method for processing permissions in an embodiment of the present disclosure. The permission processing method can be used for the client. As shown in fig. 2, the authority processing method may include steps S201 to S204.
In step S201, in response to the access request of the user, the desired authority identification of the user is determined.
The user can send out an access request through operation. An interceptor may be set at the client to intercept the access request before it reaches the application front-end. After receiving the access request of the user, the client responds to the access request of the user, and determines the expected authority identification of the user according to the access request. In some examples, the access request may include a desired permission identification for the user, and does not limit the number of desired permission identifications included in the access request. The expected authority identifier is the authority identifier corresponding to the authority expected by the user. The rights desired by the user may include rights that the user is allowed and may also include rights that the user is not allowed. And determining whether the expected authority corresponding to the expected authority identification of the user is allowed or not according to the expected authority identification of the user in the access request.
In step S202, the application authority control system is called, and whether a mapping relationship between the user and the desired authority identifier exists is queried in the application authority control system.
The application authority control system stores the mapping relation between the user and the authority identification. That is, the authority that each user has can be determined according to the first mapping relation stored in the application authority control system. It should be noted that the mapping relationship between the user and the authority identifier is not stored in the client. And determining whether the authority corresponding to the expected authority identification in the access request of the user is effective or not, and inquiring in the application authority control system.
Therefore, when the mapping relationship between the user and the authority identifier needs to be maintained, only the first mapping relationship stored in the application authority control system needs to be maintained. For the access requests of the access client, an application authority system can be called, the mapping relation between the expected authority identifier in the access request and the user of the access request is inquired in the application authority system, whether the mapping relation exists in a first mapping relation maintained in the application authority control system or not is judged, and whether the authority indicated by the expected authority identifier in the access request is valid or not is determined.
For example, the first mapping relationship between the user and the authority identifier may be stored in a table form in the application authority control system. For example, the first table is a first mapping relation between users and authority identifiers stored in the application authority control system. The authority identifier corresponding to the user A comprises readlan1, writeable 3 and prewin1, and the authority identifier corresponding to the user B comprises readlan2, readtable4 and prewin 1. readlan1 indicates read rights for sidebar content 1; writetable3 indicates the write rights of Table 3; prewin1 indicates the preview authority to hover window 1; readlan2 indicates read rights for sidebar content 2; readtable4 indicates the read permission of table 4.
Watch 1
Figure BDA0001825900940000051
In step S203, in response to the existence of the mapping relationship between the user and the desired permission identifier in the first mapping relationship, the permission identifier corresponding to the user in the first mapping relationship is obtained.
It should be noted that the authority identifier corresponding to the user in the first mapping relationship obtained by the client includes an expected authority identifier of the user, but is not limited to the expected authority identifier of the user, and may also include other authority identifiers corresponding to the user in the first mapping relationship stored in the application authority control system.
If the mapping relation between the user and the expected permission identifier exists in the first mapping relation, it indicates that the permission corresponding to the expected permission identifier of the user is allowed, and the permission identifier corresponding to the user can be provided for the client, so that the client can acquire the permission identifier corresponding to the user, display the component according to the permission allowed by the user, and/or call the interface according to the permission allowed by the user.
If the mapping relation between the user and the expected authority identifier does not exist in the first mapping system, it indicates that the authority corresponding to the expected authority identifier of the user is not allowed, the expected authority identifier corresponding to the unallowable authority in the access request can be intercepted, and the expected authority identifier corresponding to the unallowable authority is not provided for the application front end and/or the application background of the client. On the basis that the expected permission identification corresponding to the unallowed permission is not provided for the application front end and/or the application background of the client, whether the permission identification corresponding to the user in the mapping relation stored in the application permission control system is provided for the application front end and/or the application background of the client can be selected according to a specific working scene.
For example, the first mapping relation stored in the application authority control system is set as shown in table one. If the access request sent by the user a includes two expected right identifiers, one expected right identifier indicates the write right of the table3, and the other expected right identifier indicates the preview right of the floating window 3. Then a lookup may be performed in the first mapping relationship shown in table one to determine that the mapping relationship between user a and the desired permission identifier indicating the write permission of table3 exists in the first mapping relationship, but the mapping relationship between user a and the preview permission indicating the floating window 3 does not exist in the first mapping relationship. The desired permission identification writetable3 indicating the write permissions of table3 may be provided to the client as well as to the application front-end and/or application back-end of the client. The desired rights identification writeable 3 indicating the write rights of table3, and the other rights identifications readlan1 and prewin1 corresponding to user a in table one, may also be provided to the client and to the client's application front-end and/or application back-end.
In step S204, based on the authority identifier corresponding to the user in the first mapping relationship and the minimum required authority identifier of the client, the component displayed by the client and/or the interface that can be invoked are determined.
The minimum authority identifier of the application side can be configured for the client in advance, and the minimum requirement authority identifier is the limited authority identifier of the authority with the lowest allowed level of the client.
In some examples, the client includes an application front-end and an application back-end. Accordingly, the minimum requirement authority identifier may include a front-end minimum requirement authority identifier and a background minimum requirement authority identifier. The front-end minimum requirement permission identifier can be configured at the application front end. The background minimum requirement authority identification can be configured in the application background. The front-end minimum requirement authority identifier is the authority identifier of the authority with the lowest allowed level of the limited application front end. The background minimum requirement authority identification is the authority identification of the authority with the lowest allowed level in the background of the limited application. In the process of developing the authority of the authority processing system, the application front side is more important than the display effect, and the application background side is more important than the call (i.e. access) to the interface. The application front end and the application background have different emphasis points. However, by setting various permissions, the permission of the application front-end display component and/or the permission of the application background calling interface can be respectively set. The expected permission identifier determined according to the access request of the user can comprise a permission identifier used for indicating the permission of the application front-end display component and/or a permission identifier used for indicating the permission of the application background calling interface. Therefore, the conflict of the side emphasis points of the application front end and the application background is avoided.
The rights identification corresponding to the user is the right of the rights the user is allowed to, but it is possible that the rights allowed for the user are not allowed by the client. Therefore, the lowest requirement authority identification can be utilized to determine the authority of the authority identification corresponding to the user allowed by the client.
Specifically, if it is determined that the permission indicated by the permission identifier corresponding to the user in the first mapping relationship is higher than or equal to the permission indicated by the minimum required permission identifier, the client may display the component indicated by the permission identifier corresponding to the user and/or may call an interface indicated by the permission identifier corresponding to the user. And if the permission indicated by the permission identifier corresponding to the user in the first mapping relation is determined to be lower than the permission indicated by the lowest requirement permission identifier, the application side does not display the component indicated by the permission identifier corresponding to the user and can not call the interface indicated by the permission identifier corresponding to the user.
In some examples, a route of the permission indicated by the permission identifier corresponding to the user allowed by the client may be calculated according to the permission identifier corresponding to the user allowed by the client, and a jump between component displays may be performed according to the calculated route. For example, the route of the initial permission corresponding to the user indicates a sidebar displayed by a single-page application on the client, and the route of the next permission corresponding to the user indicates a picture to be displayed by the single-page application on the client, so that the client displays the picture to be displayed by skipping from the sidebar.
In the embodiment of the disclosure, the client may respond to an access request sent by a user, and determine a desired permission identifier of the user according to the access request. And calling an application authority system, and inquiring whether a mapping relation between the user and the expected authority identifier exists in a first mapping relation between the user and the authority identifier stored in the application authority control system. If the mapping relation between the user and the expected authority identification exists in the application authority control system, the fact that the authority corresponding to the expected authority identification is allowed for the user is indicated. The component exposed at the front end of the application and/or the interface which can be called by the background of the application can be determined based on the permission identifier corresponding to the permitted permission of the user and the minimum requirement permission identifier. In the case of maintaining the authority of the user (which may include adding the authority, deleting the authority, changing the authority, etc.), only the first mapping relationship between the user and the authority identifier stored in the application authority control system needs to be maintained. When a user sends an access request, the application authority control system is called, the first mapping relation after maintenance is inquired, and the service which accords with the authority after maintenance is provided for the user, so that the condition that the service which does not accord with the authority after maintenance is provided for the user is avoided. Such as to avoid user override. The maintainability and operability of the authority processing are improved.
In a specific operation, the address of the request may be adjusted according to specific requirements, for example, an address (e.g., endpoint) of the route pointing to the component exposed by the client and/or an address (e.g., endpoint) of the callable interface, and therefore, the address (e.g., endpoint) of the route pointing to the component exposed by the client and/or the address (e.g., endpoint) of the callable interface are both prone to change and are unstable. In the disclosed embodiment, the rights are relatively stable, and thus the rights identification is also relatively stable. And determining the components displayed by the client and/or the interface which can be called according to the authority identification corresponding to the authority, thereby enhancing the stability of the single-page application.
In some examples, permission triplets for all kinds of permissions may be configured to clients. All rights here refer to all kinds of rights that the client can support. For example, the client supports the preview authority, the read authority and the write authority, and even if the request of some or all users does not include the preview authority, the read authority and the write authority, the client is required to be configured with respective authority triples of the preview authority, the read authority and the write authority.
Each permission triple comprises a first permission identifier, a second permission identifier and a third permission identifier. The first authority identifier is an authority variable name recorded by the client. The second privilege identification is a privilege value used for transmission and privilege comparison. The third authority mark is the authority token name recorded by the application authority control system. And the first authority identifier, the second authority identifier and the third authority identifier in the same authority triple represent the same authority.
For example, a rights triple may be represented as (Key, Code, Token). The first authority identifier is Key, the second authority identifier is Code, and the third authority identifier is Token. It should be noted that, in the permission triplet, the order of the first permission identifier, the second permission identifier, and the third permission identifier may be changed, and is not limited herein. For example, the right triple of the read right of table3 may be represented as (ta3_ re, 3, table3 read), where the first right identifier ta3_ re, the second right identifier 3, and the third right identifier table3 read all indicate the read right of table 3. And according to any one identifier of the first authority identifier, the second authority identifier and the third authority identifier, the other identifier can be found in the authority triple.
In some examples, the client is generally developer-oriented, and thus the first privilege identification may be a variable name defined in development programming used to indicate the privilege.
The second rights identification is used for transfer and rights comparison. For ease of transmission and for ease of comparing the rights levels, the second rights identifier may be an integer value used to indicate the rights. In the permission comparison, it may be set that the larger the second permission flag is, the higher the permission indicated by the second permission flag is. Thereby realizing the comparability of the authority.
The application rights control system is generally operator oriented, so the third rights identifier may be a readily readable token string for indicating rights.
Under the requirements of different areas and different functions, the mutual conversion among the first authority identifier, the second authority identifier and the third authority identifier in the same authority triple can be carried out according to the authority triple.
In the above embodiment, the access request is used to transmit the desired permission identifier, and the desired permission identifier in the access request may be the second permission identifier. And if the first mapping relation is stored in the application authority control system, the authority identifier in the first mapping relation is the third authority identifier.
The process of querying whether a mapping relationship between a user and an expected permission identifier exists in the application permission control system in step S202 of the foregoing embodiment may specifically be: converting the expected authority identifier into a third authority identifier corresponding to the expected authority identifier according to the authority triple; and inquiring whether a mapping relation between the user and a third authority identifier which is expected to be converted by the authority identifier exists in the application authority control system.
For ease of transmission, the desired permission identifier in the access request is the second permission identifier. But the authority identifier in the first mapping relation stored in the application authority control system is the third authority identifier. For the convenience of searching, the expected permission identifier in the access request can be converted into a corresponding third permission identifier according to the permission triple, and then whether a mapping relation between the user and the third permission identifier converted from the expected permission identifier exists in the first mapping relation is searched.
In step S204 of the foregoing embodiment, based on the authority identifier corresponding to the user in the first mapping relationship and the minimum requirement authority identifier of the client, the content of the component and/or the interface that can be called and displayed by the client is determined, which may specifically be: converting the authority identifier corresponding to the user and the lowest requirement authority identifier in the first mapping relation into a second authority identifier according to the authority triple; and the second authority identifier of the user is greater than or equal to the second authority identifier converted from the minimum authority identifier at the application side, and a second target component and/or a second target interface which can be called and displayed at the client side are/is determined.
And the second authority identifier of the user is the second authority identifier converted from the authority identifier corresponding to the user in the first mapping relation. The second target component and the second target interface both correspond to the second authority identifier of the user.
And the target component and the target interface both correspond to the second authority identifier of the user. That is, the target component is a component corresponding to the user's second rights identification. The target interface is an interface corresponding to the second authority identification of the user.
The authority identifier in the first mapping relation in the application authority control system is the third authority identifier. And the minimum authority identifier configured at the application side of the client is the first authority identifier. For comparison, the authority identifier corresponding to the user and the lowest requirement authority identifier in the first mapping relation are converted into the second authority identifier according to the authority triple for comparison. The second privilege identification is a privilege value used for privilege comparison. The second authority identifier of the user is larger than or equal to the second authority identifier converted by the lowest requirement authority identifier, and the second authority identifier indicates that the authority indicated by the second authority identifier of the user is higher than or equal to the authority indicated by the lowest requirement authority identifier. The client may expose the target component and/or may invoke the target interface.
In some examples, the client includes an application front-end and an application back-end. Accordingly, the minimum requirement permission identifier may include a front-end minimum requirement permission identifier and/or a background minimum requirement permission identifier. Similarly, if the second authority identifier of the user is greater than or equal to the second authority identifier converted from the lowest requirement authority identifier of the front end, the front end is applied to display the target component. The application front end displays the target component and needs to call an interface corresponding to the target component. And if the second authority identification of the user is larger than or equal to the second authority identification converted by the background minimum requirement authority identification, the application background can call the target interface.
In some examples, it is determined that the client has not received the permission full query request of the user, and the permission identifiers corresponding to the user in the first mapping relationship obtained in the foregoing embodiment are all permission identifiers corresponding to the user.
It can be determined whether the user has issued a request for a full amount of permissions before the user's request for access this time. In some examples, whether a user issues a full-rights query request may be determined by detecting whether a full-rights query interface is invoked.
The permission full query request is used for querying all permission identifications corresponding to the user in a first mapping relation stored in the application permission control system. For example, before the access request, when the user performs a registration operation or a login operation within the valid time, it may be considered that the user has issued the full-permission query request.
If the user is determined not to send the permission full query request, all permission identifications corresponding to the user can be queried in a first mapping relation which is queried and stored in the application permission control system, and all permission identifications corresponding to the user in the first mapping relation are obtained. For example, the first mapping relationship is shown in table one above, and the user is user B. All the authority identifiers corresponding to the user B, which are obtained by querying in the first mapping relation, comprise readlan2, readtable4 and prewin 1.
In some examples, the authority identifiers in the first mapping relation are all third authority identifiers. All the third permission identifications corresponding to the user and obtained by query can be converted into the second permission identifications and transmitted to the client. And comparing the transmitted second authority identifier with the second authority identifier converted by the lowest requirement authority identifier to determine the components displayed by the client and/or the callable interface. And the transmitted second authority identifier can be converted into the first authority identifier and recorded in an application background of the client, so that the developer can conveniently check the first authority identifier.
Fig. 3 is a flowchart of a method for privilege processing according to another embodiment of the disclosure. As shown in fig. 3, the method of authority processing includes steps S301 to S306.
In step S301, a request for a full amount of authority inquiry of a user is received.
For a description of the permission full query request, reference may be made to the above embodiments, and details are not described herein.
In step S302, the application authority control system is invoked, and all the authority identifiers corresponding to the users are searched in the first mapping relationship.
And receiving a permission full query request sent by a user, and in some examples, calling a permission full query interface to obtain all permission identifications corresponding to the user in the first mapping relation.
In step S303, all the authority identifiers corresponding to the users in the first mapping relationship are cached in the client. When the expected permission identification of the user exists in the cache of the client, the displayed component and/or the interface which can be called of the client are determined based on the permission identification corresponding to the user in the cache of the client and the minimum requirement permission identification.
The cache of the client is a local cache. And after responding to the permission full query request sent by the user, obtaining all permission identifications corresponding to the user in the first mapping relation, and caching all permission identifications corresponding to the user in the mapping relation stored by the application permission control system at the client. So that when the same user sends out an access request again, the client can directly inquire in the cache of the client.
In step S304, in response to the access request of the user, the desired authority identification of the user is determined.
The relevant content of step S304 can refer to the relevant description of step S201 in the above embodiment, and is not described herein again.
In step S305, in response to the existence of the desired permission identifier in the cache of the client, the components and/or the callable interfaces displayed by the client are determined based on the permission identifier corresponding to the user in the cache of the client and the minimum required permission identifier.
And the authority identifier corresponding to the user in the cache of the client comprises an expected authority identifier.
When the user sends out the access request again, whether the expected permission identification exists is inquired in the cache of the client. The method comprises the steps that an expected permission identifier exists in a cache of a client, the permission corresponding to the expected permission identifier of a user is allowed, whether the permission of the user is allowed to the client or not can be further judged based on the permission identifier corresponding to the user in the cache of the client and a minimum requirement permission identifier, and a component displayed by the client and an interface which can be called are determined.
In step S305, the processing of the desired permission identifier at the client may refer to the search of the desired permission identifier in the application permission control system in the above embodiment, and the client determines the content of the component and/or the interface that can be invoked and displayed by the client according to the permission identifier corresponding to the user and the minimum requirement permission identifier.
In step S306, in response to that the expected permission identifier does not exist in the cache of the client, prompt information is presented at the client.
Wherein the hint information indicates an initial valid route. The initial valid route is a path where a route corresponding to the desired permission identifier is located, and the permission identifier is a starting route existing in a cache of the client. That is, the initial valid route is the first authorized route of the user among the client's allowed permissions. For example, the initial valid route is a route of a sidebar that the client can expose to the user.
In some examples, to prevent the permission identification in the client's cache from not being synchronized with the maintained application permission control system, the application permission control system may be invoked again and queried for verification in the application permission control system. And the authority triples can be utilized to be mutually converted in the first authority identifier, the second authority identifier and the third authority identifier in the authority triples.
Specifically, it is determined that the second authority identifier of the user is greater than or equal to the second authority identifier converted by the lowest requirement authority identifier, and the second authority identifier corresponding to the user is converted into a third authority identifier. And calling an application authority control system, and inquiring whether a mapping relation between the user and a third authority identifier of the user exists in the first mapping relation. And determining a first target component and/or a first target interface which can be called and is displayed at the client side in response to the mapping relation between the user and the third authority identifier of the user existing in the first mapping relation.
And the third authority identifier of the user is the third authority identifier converted from the second authority identifier corresponding to the user. And the first target component and the first target interface both correspond to the third authority identification of the user. For querying whether the third permission identifier exists between the user and the user in the first mapping relationship, and determining the content of the target component and/or the invokable target interface displayed at the client, reference may be made to the relevant description in the above embodiments, and details are not described herein again.
Fig. 4 is a schematic structural diagram of a permission processing apparatus in an embodiment of the disclosure. As shown in fig. 4, the authority processing device 400 may include a response module 401, an authority control calling module 402, an authority identification obtaining module 403, and a determination module 404.
The response module 401 is configured to determine a desired permission identifier of a user in response to an access request of the user.
The expected authority identification is the authority identification corresponding to the authority expected by the user.
And an authority control calling module 402, configured to call an application authority control system, and query whether a mapping relationship between a user and an expected authority identifier exists in the application authority control system.
The application authority control system stores a first mapping relation between a user and an authority identifier.
The authority identifier obtaining module 403 is configured to, in response to a mapping relationship between a user and an expected authority identifier existing in the first mapping relationship, obtain an authority identifier corresponding to the user in the first mapping relationship.
And acquiring a first mapping relation, wherein the authority identification corresponding to the user in the acquired first mapping relation comprises an expected authority identification.
A determining module 404, configured to determine a displayed component and/or a callable interface based on the permission identifier and the minimum requirement permission identifier corresponding to the user in the first mapping relationship.
In some examples, the rights processing apparatus 400 may further include a configuration module 405, and the configuration module 405 is configured to configure the rights triplets of all kinds of rights to the rights processing apparatus 400 synchronously.
Each permission triple comprises a first permission identifier, a second permission identifier and a third permission identifier. The first authority identification is an authority variable name recorded by the authority processing apparatus 400. The second privilege identification is a privilege value used for transmission and privilege comparison. The third authority mark is the authority token name recorded by the application authority control system. And the first authority identifier, the second authority identifier and the third authority identifier in the same authority triple represent the same authority.
In some examples, the desired permission identifier is a second permission identifier, and the permission identifier in the first mapping relationship is a third permission identifier.
The permission control calling module 402 is specifically configured to convert the expected permission identifier into a third permission identifier corresponding to the expected permission identifier according to the permission triplet; and inquiring whether a mapping relation between the user and a third authority identifier which is expected to be converted by the authority identifier exists in the application authority control system.
In some examples, it is determined that the permission processing apparatus 400 has not received the permission full query request of the user, and the permission identifiers corresponding to the user in the first mapping relationship acquired by the permission identifier acquisition module 403 are all permission identifiers corresponding to the user.
In some examples, the permission processing apparatus 400 may further include a receiving module 406 and a caching module 407. Rights processing apparatus 400 may also include a cache query module 408 and a prompt module 409.
A receiving module 406, configured to receive a request for querying the full amount of rights of the user.
The authority control calling module 402 is further configured to call an application authority control system, and search all authority identifiers corresponding to the user in the first mapping relationship.
The caching module 407 is configured to cache all the authority identifiers corresponding to the users in the first mapping relationship in the authority processing apparatus 400, so that when the desired authority identifier of the user exists in the cache of the authority processing apparatus 400, the displayed components and/or the callable interfaces of the authority processing apparatus 400 are determined based on the authority identifier corresponding to the user in the cache of the authority processing apparatus 400 and the minimum required authority identifier.
And a cache query module 408, configured to query whether the desired permission identifier exists in the cache.
The determining module 404 is further configured to determine, based on the permission identifier corresponding to the user in the cache and the minimum requirement permission identifier, the exposed component and/or the callable interface if the desired permission identifier exists in the cache.
And the authority identifier corresponding to the user in the cache comprises an expected authority identifier.
A prompt module 409, configured to display prompt information on the authority processing apparatus 400 when the expected authority identifier does not exist in the cache of the authority processing apparatus 400.
Wherein the hint information indicates an initial valid route. The initial valid route is the path in which the route corresponding to the desired permission identifier is located, and the permission identifier is the starting route present in the cache of the permission processing apparatus 400.
In some examples, the rights processing apparatus 400 is configured with rights triplets, each including a first rights identification, a second rights identification, and a third rights identification.
In some examples, the determining module 404 may be specifically configured to: converting the authority identifier corresponding to the user and the lowest requirement authority identifier in the first mapping relation into a second authority identifier according to the authority triple; the second user permission identifier is greater than or equal to the second permission identifier converted from the lowest required permission identifier, and a second target component and/or a second target interface which can be called and displayed on the permission processing device 400 are determined, wherein the second target component and the second target interface both correspond to the second user permission identifier, and the second user permission identifier is the second permission identifier converted from the permission identifier corresponding to the user in the first mapping relationship.
In the embodiment of the disclosure, the response module may respond to an access request sent by a user, and determine a desired permission identifier of the user according to the access request. And the authority control calling module calls an application authority system and inquires whether a mapping relation between the user and the expected authority identifier exists in a first mapping relation between the user and the authority identifier stored in the application authority system. If the mapping relation between the user and the expected authority identification exists in the application authority control system, the fact that the authority corresponding to the expected authority identification is allowed for the user is indicated. The determining module may determine the component exposed by the application front end and/or the interface that can be called by the application background based on the permission identifier corresponding to the permission allowed by the user and the minimum requirement permission identifier. In the case of maintaining the authority of the user (which may include adding the authority, deleting the authority, changing the authority, etc.), only the first mapping relationship between the user and the authority identifier stored in the application authority control system needs to be maintained. When a user sends an access request, the application authority control system is called, the first mapping relation after maintenance is inquired, and the service which accords with the authority after maintenance is provided for the user, so that the condition that the service which does not accord with the authority after maintenance is provided for the user is avoided. Such as to avoid user override. The maintainability and operability of the authority processing are improved.
Fig. 5 is a block diagram of an exemplary hardware architecture of an application side device capable of implementing the method and apparatus for processing a right according to an embodiment of the present disclosure. As shown in fig. 5, the application-side device 500 includes an input device 501, an input interface 502, a central processor 503, a memory 504, an output interface 505, and an output device 506. The input interface 502, the central processing unit 503, the memory 504, and the output interface 505 are connected to each other through a bus 510, and the input device 501 and the output device 506 are connected to the bus 510 through the input interface 502 and the output interface 505, respectively, and further connected to other components of the application side device 500.
Specifically, the input device 501 receives input information from the outside and transmits the input information to the central processor 503 through the input interface 502; the central processor 503 processes input information based on computer-executable instructions stored in the memory 504 to generate output information, temporarily or permanently stores the output information in the memory 504, and then transmits the output information to the output device 506 through the output interface 505; the output device 506 outputs the output information to the outside of the application-side device 500 for use by the user.
That is, the server shown in fig. 5 may also be implemented to include: a memory storing computer-executable instructions; and a processor, which when executing computer executable instructions can implement the permission processing method and apparatus in the above embodiments.
The disclosed embodiments also provide a storage medium having computer program instructions stored thereon; the computer program instructions, when executed by a processor, implement the privilege processing method provided by the embodiments of the present disclosure.
The functional blocks shown in the above structural block diagrams may be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, it may be, for example, an electronic circuit, an Application Specific Integrated Circuit (ASIC), suitable firmware, plug-in, function card, or the like. When implemented in software, the elements of the present disclosure are the programs or code segments used to perform the required tasks. The program or code segments may be stored in a machine-readable medium or transmitted by a data signal carried in a carrier wave over a transmission medium or a communication link. A "storage medium" may include any medium that can store or transfer information. Examples of storage media include electronic circuitry, semiconductor memory devices, ROM, flash memory, Erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, Radio Frequency (RF) links, and so forth. The code segments may be downloaded via computer networks such as the internet, intranet, etc.
It will be understood by those skilled in the art that in the claims, the term "comprising" does not exclude other devices or steps; the indefinite article "a" does not exclude a plurality; the terms "first" and "second" are used to denote a name and not to denote any particular order.
It should be clear that the embodiments in this specification are described in a progressive manner, and the same or similar parts in the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. For apparatus embodiments, application-side device embodiments and storage medium embodiments, reference may be made to the description of the method embodiments for relevant aspects and advantages. The present disclosure is not limited to the particular steps and structures described above and shown in the drawings. Those skilled in the art may make various changes, modifications, and additions or change the order between the steps after appreciating the spirit of the present disclosure. Also, a detailed description of known process techniques is omitted herein for the sake of brevity.

Claims (8)

1. A method of privilege processing, comprising:
responding to an access request of a user, and determining an expected authority identifier of the user, wherein the expected authority identifier is an authority identifier corresponding to the authority expected by the user;
calling an application authority control system, and inquiring whether a mapping relation between the user and the expected authority identifier exists in the application authority control system, wherein the application authority control system stores a first mapping relation between the user and the authority identifier;
responding to the mapping relation between the user and the expected authority identifier in the first mapping relation, and acquiring the authority identifier corresponding to the user in the first mapping relation, wherein the acquired authority identifier corresponding to the user in the first mapping relation comprises the expected authority identifier;
determining a component displayed by the client and/or a callable interface based on the authority identifier corresponding to the user in the first mapping relation and the minimum requirement authority identifier of the client;
before the responding to the access request of the user, the method further comprises the following steps:
synchronously configuring the authority triples of all kinds of authorities to the client;
each permission triple comprises a first permission identifier, a second permission identifier and a third permission identifier, wherein the first permission identifier is a permission variable name recorded by the client, the second permission identifier is a permission numerical value used for transmission and permission comparison, and the third permission identifier is a permission token name recorded by the application permission control system; the first permission identifier, the second permission identifier and the third permission identifier in the same permission triple represent the same permission.
2. The method according to claim 1, wherein the desired permission identifier is the second permission identifier, and the permission identifier in the first mapping relationship is a third permission identifier;
the querying whether the mapping relationship between the user and the expected authority identifier exists in the application authority control system comprises the following steps:
converting the expected permission identifier into a third permission identifier corresponding to the expected permission identifier according to the permission triple;
and inquiring whether a mapping relation between the user and the third authority identifier converted by the expected authority identifier exists in an application authority control system.
3. The method of claim 1, further comprising, prior to determining the desired privilege identification of the user in response to the user's access request:
receiving a permission full-quantity query request of the user;
calling the application authority control system, and searching all the authority identifications corresponding to the user in the first mapping relation;
caching all the authority identifications corresponding to the user in the first mapping relation at the client so as to determine the components and/or the callable interfaces displayed by the client based on the authority identifications corresponding to the user in the cache of the client and the minimum requirement authority identification when the expected authority identifications of the user exist in the cache of the client.
4. The method according to claim 3, wherein in response to not receiving the request for querying the full amount of permissions of the user, the obtained permission identifiers corresponding to the user in the first mapping relationship are all the permission identifiers corresponding to the user.
5. The method according to claim 1, wherein the determining the components and/or the callable interfaces displayed by the client based on the permission identifier corresponding to the user and the minimum permission identifier of the client in the first mapping relationship comprises:
converting the authority identifier corresponding to the user and the lowest requirement authority identifier in the first mapping relation into the second authority identifier according to the authority triple;
and determining a second target component and/or a second target interface which can be called and is displayed at the client in response to the second permission identifier of the user, wherein the second permission identifier is larger than or equal to the second permission identifier converted by the lowest requirement permission identifier, the second target component and the second target interface both correspond to the second permission identifier of the user, and the second permission identifier of the user is the second permission identifier converted by the permission identifier corresponding to the user in the first mapping relation.
6. An authority processing apparatus characterized by comprising:
the response module is used for responding to an access request of a user and determining an expected authority identifier of the user, wherein the expected authority identifier is an authority identifier corresponding to the authority expected by the user;
the authority control calling module is used for calling an application authority control system, inquiring whether a mapping relation between the user and the expected authority identifier exists in the application authority control system, and storing a first mapping relation between the user and the authority identifier in the application authority control system;
an authority identifier obtaining module, configured to obtain an authority identifier corresponding to the user in the first mapping relationship in response to a mapping relationship between the user and the expected authority identifier existing in the first mapping relationship, where the authority identifier corresponding to the user in the obtained first mapping relationship includes the expected authority identifier;
the determining module is used for determining the displayed component and/or the interface which can be called based on the authority identifier corresponding to the user in the first mapping relation and the lowest requirement authority identifier;
the device, still include:
the configuration module is used for synchronously configuring the authority triples of all kinds of authorities to the authority processing device;
each permission triple comprises a first permission identifier, a second permission identifier and a third permission identifier, wherein the first permission identifier is a permission variable name recorded by the permission processing device, the second permission identifier is a permission numerical value used for transmission and permission comparison, and the third permission identifier is a permission token name recorded by the application permission control system; the first permission identifier, the second permission identifier and the third permission identifier in the same permission triple represent the same permission.
7. An application-side device, comprising: a memory and a processor;
the memory is used for storing executable program codes;
the processor is configured to read the executable program code stored in the memory to execute the privilege processing method according to any one of claims 1 to 5.
8. A storage medium having computer program instructions stored thereon; the computer program instructions, when executed by a processor, implement a rights processing method as claimed in any one of claims 1 to 5.
CN201811184754.1A 2018-10-11 2018-10-11 Authority processing method and device, application side equipment and storage medium Active CN109472127B (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201811184754.1A CN109472127B (en) 2018-10-11 2018-10-11 Authority processing method and device, application side equipment and storage medium
CA3058061A CA3058061A1 (en) 2018-10-11 2019-10-09 Permission processing method, device, application side device and storage media

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201811184754.1A CN109472127B (en) 2018-10-11 2018-10-11 Authority processing method and device, application side equipment and storage medium

Publications (2)

Publication Number Publication Date
CN109472127A CN109472127A (en) 2019-03-15
CN109472127B true CN109472127B (en) 2021-01-22

Family

ID=65665080

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201811184754.1A Active CN109472127B (en) 2018-10-11 2018-10-11 Authority processing method and device, application side equipment and storage medium

Country Status (2)

Country Link
CN (1) CN109472127B (en)
CA (1) CA3058061A1 (en)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111143824B (en) * 2019-12-31 2022-06-10 奇安信科技集团股份有限公司 Method and device for determining redundancy permission, computer equipment and readable storage medium
US20220300635A1 (en) * 2021-03-18 2022-09-22 International Business Machines Corporation Managing search queries using encrypted cache data
CN113204790B (en) * 2021-05-25 2024-03-01 北京字跳网络技术有限公司 View authority processing method, device, equipment and medium
CN115766296B (en) * 2023-01-09 2023-05-23 广东中思拓大数据研究院有限公司 Authority control method, device, server and storage medium for user account

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007021823A2 (en) * 2005-08-09 2007-02-22 Tripwire, Inc. Information technology governance and controls methods and apparatuses
CN101499906A (en) * 2008-02-02 2009-08-05 厦门雅迅网络股份有限公司 Method for implementing subscriber authority management based on role function mapping table
CN104486357A (en) * 2014-12-30 2015-04-01 北京经开投资开发股份有限公司 Method for achieving role-based access control (RBAC) based on SSH website

Also Published As

Publication number Publication date
CN109472127A (en) 2019-03-15
CA3058061A1 (en) 2020-04-11

Similar Documents

Publication Publication Date Title
CN109472127B (en) Authority processing method and device, application side equipment and storage medium
US10412176B2 (en) Website access method, apparatus, and website system
US8667578B2 (en) Web management authorization and delegation framework
EP2106087B1 (en) Method and apparatus for handling security level of device on network
US9143389B2 (en) Methods, appratuses, and computer program products for determining a network interface to access a network resource
CN106462430B (en) Application upgrade package obtaining method and device
US9317681B2 (en) Information processing apparatus, information processing method, and computer program product
KR101198437B1 (en) Method, apparatus and computer program product for providing context triggered distribution of context models
CN110197075B (en) Resource access method, device, computing equipment and storage medium
CN113452780B (en) Access request processing method, device, equipment and medium for client
CN109600458B (en) Website access method and device
US9015791B2 (en) Method of managing web application policy using smart card, and web server and mobile terminal for implementing the same
US20050060315A1 (en) Metadata database lookup system
KR20050013961A (en) Method and apparatus for late-binding/dynamic pathname resolution
CN103269353A (en) Web cache and return optimization method and Web cache system
US20040122877A1 (en) Permission token managemnet system, permission token management method, program and recording medium
CN111753268B (en) Single sign-on method, single sign-on device, storage medium and mobile terminal
KR102021269B1 (en) method for sharing location information of terminal of location information sharer
CN114143042A (en) Vulnerability simulation method and device, computer equipment and storage medium
US11057489B2 (en) Content deployment method and delivery controller
JP2013254352A (en) Management device, management system and management program
KR100601848B1 (en) Method for Processing Download Descriptor in Mobile Communication Terminal
JP2005284573A (en) Access management system
KR102582398B1 (en) Method and apparatus for controlling applications
KR101304393B1 (en) User data management server and operating method thereof, user terminal and recording medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant