Unauthorized access control method, device, equipment and medium

Abstract

The present invention discloses a method, apparatus, device, and medium for controlling unauthorized access. The method includes the following steps: receiving an API access request, the API access request including API information of a pre-accessed first API and user information of a first user who pre-accessed the first API; judging, based on an initial API set and the API access request, whether the first user's access to the first API is authorized access or a first unauthorized access; based on the first user's authorized access to the first API, receiving a data access request from the first user, the data access request including data information of pre-accessed first data; obtaining a first data type corresponding to the first API based on the first user's user information and the data information of the first data; judging, based on a plug-in corresponding to the first data type, whether the first user's access to the first data is authorized access or a second unauthorized access. The present invention can effectively protect the operation and data security of API backend software by controlling users' unauthorized access to APIs and corresponding data.

Description

Technical Field

[0001] The present invention relates to the field of computer network technology, and in particular to a method, device, equipment and medium for controlling unauthorized access. Background Art

[0002] Providing business capabilities to external applications (including web applications, mobile apps, mini-programs, PC application software, etc.) based on APIs is a common technical means of outputting API backend software capabilities. The software defines a series of APIs that implement different business functions, and external applications access the corresponding APIs according to business needs. However, the process of API access is also accompanied by various illegal access and brute force attacks. The vulnerabilities of the API itself can also easily become attack points. For example, due to poor design of API access authentication, it can easily lead to unauthorized access.

[0003] Unauthorized access includes vertical unauthorized access and horizontal unauthorized access. Vertical unauthorized access refers to an external application attempting to obtain high-level access permissions with a low-level permission. Simply put, this means an external application attempts to access an API to which it does not have permission. Horizontal unauthorized access refers to an external application attempting to access other users' resources or data with equal or identical permissions. Simply put, this means an external application attempts to access the data of unauthorized users other than itself through the same API.

[0004] In the existing technology, the key to vertical unauthorized access control is to control which API access rights users of external applications have. Common technical solutions include: manually configuring the API URL method; selecting from an API list, or first classifying the APIs and selecting the configuration method for a specific category of APIs. The first method mentioned above is suitable for situations where the number of APIs provided by the API backend software is small. The second method requires the selector to be very familiar with the functions of each API, otherwise it is easy to make a wrong choice. The key to horizontal unauthorized access control is to control that users of external applications cannot access the data of other users without authorization. The common technical solution is to first implement the unauthorized access control logic in the implementation logic code of each API: check whether the user of the external application wants to access the data of other users, and then check whether the user has the permission to access the data of the specified other users. This method can better control horizontal unauthorized access, but each API contains unauthorized access control logic, which causes the access control logic to spread uncontrollably and also destroys the neatness of the API business logic code. Summary of the Invention

[0005] The purpose of the present invention is to provide a method, device, equipment and medium for controlling unauthorized access, so as to solve the problem that the existing API access authentication is poorly designed, resulting in easy unauthorized access.

[0006] To solve the above technical problems, a technical solution adopted by the present invention is to provide an unauthorized access control method, which includes the following steps: receiving an API access request, the API access request including API information of a pre-accessed first API, and user information of a first user who pre-accesses the first API, the API information including an API unique identifier, and the user information including a user unique identifier and a user role; judging whether the first user's access to the first API is authorized access or a first unauthorized access based on a preset initial API set and the API access request; receiving a data access request from the first user based on the first user's authorized access to the first API, the data access request including data information of a pre-accessed first data; obtaining a first data type corresponding to the first API based on the user information of the first user and the data information of the first data; judging whether the first user's access to the first data is authorized access or a second unauthorized access based on the plug-in corresponding to the first data type.

[0007] In some embodiments, the method further comprises the step of configuring the initial API set according to the type of the external application, wherein the initial API set includes a plurality of APIs accessible to users of the external application.

[0008] In some embodiments, the type of the external application includes a first application type, and configuring the initial API set based on the type of the external application includes the steps of: defining a function menu set, the function menu set including multiple function menus, the function menu including multiple APIs that users can access through pages corresponding to the function menus; defining multiple user roles, and authorizing specific function menu permissions for each user role; and determining the initial API set accessible to users corresponding to each user role.

[0009] In some embodiments, the type of the external application includes a second application type, and configuring the initial API set according to the type of the external application includes the step of manually configuring the initial API set accessible to users of the external application.

[0010] In some embodiments, the determining, based on a preset initial API set and the API access request, whether the first user's access to the first API is authorized access or the first unauthorized access, includes the steps of: determining, based on the user information of the first user, that the initial API set accessible to the first user is the first API set; determining whether the first API is included in the first API set; and if the first API is included in the first API set, determining that the first user's access to the first API is authorized access.

[0011] In some embodiments, the determining, based on a preset initial API set and the API access request, whether the first user's access to the API is authorized access or the first unauthorized access, includes the steps of: determining whether the external application is a legitimate application; if the external application is a legitimate application, determining that the initial API set is a second API set; determining whether the second API set includes the first API; if the second API set includes the first API, determining that the first user's access to the first API is authorized access.

[0012] In some embodiments, the method further includes the steps of: designing multiple characteristic elements corresponding to API access, the multiple characteristic elements including the user ID for accessing the API, the set of user IDs to which the pre-access data belongs, and the data type ID of the pre-access data; defining a plug-in library, the plug-in library including multiple plug-ins, each of the plug-ins containing a permission judgment function; defining a plug-in framework, the plug-in framework including the plug-in, and the plug-in dynamically deployed to the plug-in framework in a plug-and-play manner, so that the plug-in implements the corresponding data access permission judgment through the permission judgment function.

[0013] The present invention also provides an unauthorized access control device, which includes: an API access receiving unit, used to receive an API access request, the API access request including API information of a pre-accessed first API, and user information of a first user who pre-accesses the first API, the API information including an API unique identifier, and the user information including a user unique identifier and a user role; a first judgment unit, used to determine whether the first user's access to the first API is authorized access or a first unauthorized access based on a preset initial API set and the API access request; a data access receiving unit, used to receive a data access request from the first user based on the first user's authorized access to the first API, the data access request including data information of the pre-accessed first data; a data type acquisition unit, used to obtain a first data type corresponding to the first API based on the user information of the first user and the data information of the first data; a second judgment unit, used to determine whether the first user's access to the first data is authorized access or a second unauthorized access based on a plug-in corresponding to the first data type.

[0014] The present invention also provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the above method when executing the computer program.

[0015] The present invention also provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the above method are implemented.

[0016] The beneficial effects of the present invention are as follows: the present invention discloses an unauthorized access control method, apparatus, device and medium, the method comprising the following steps: receiving an API access request, the API access request including API information of a pre-accessed first API, and user information of a first user who pre-accesses the first API, the API information including an API unique identifier, and the user information including a user unique identifier and a user role; judging whether the first user's access to the first API is authorized access or a first unauthorized access based on a preset initial API set and the API access request; receiving a data access request from the first user based on the first user's authorized access to the first API, the data access request including data information of the pre-accessed first data; obtaining a first data type corresponding to the first API based on the first user's user information and the data information of the first data; judging whether the first user's access to the first data is authorized access or a second unauthorized access based on the plug-in corresponding to the first data type. The present invention controls the user's unauthorized access to the API and the corresponding data by controlling the first unauthorized access and the second unauthorized access, thereby effectively protecting the operation and data security of the API backend software. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 This is a flow chart of an embodiment of an unauthorized access control method of the present invention;

[0018] Figure 2 This is a specific flow chart of obtaining the corresponding initial API set in an embodiment of an unauthorized access control method of the present invention;

[0019] Figure 3 This is a schematic diagram of the relationship between user roles, function menus, and multiple APIs in an embodiment of an unauthorized access control method of the present invention;

[0020] Figure 4 This is a specific flow chart of step S2 corresponding to an external application of the first application type in an embodiment of an unauthorized access control method of the present invention;

[0021] Figure 5 This is a specific flow chart of step S2 corresponding to the external application of the second application type in an embodiment of an unauthorized access control method of the present invention;

[0022] Figure 6 This is a flow chart of implementing second unauthorized access control for a first user in an embodiment of an unauthorized access control method of the present invention;

[0023] Figure 7This is a structural block diagram of an embodiment of an unauthorized access control device of the present invention;

[0024] Figure 8 This is a schematic diagram of the architecture of an electronic device according to an embodiment of the present invention;

[0025] Figure 9 It is a schematic block diagram of an embodiment of a computer-readable storage medium of the present invention. DETAILED DESCRIPTION

[0026] To facilitate understanding of the present invention, the present invention will be described in more detail below with reference to the accompanying drawings and specific embodiments. Preferred embodiments of the present invention are shown in the accompanying drawings. However, the present invention can be implemented in many different forms and is not limited to the embodiments described in this specification. Rather, these embodiments are provided to provide a more thorough and comprehensive understanding of the disclosure of the present invention.

[0027] It should be noted that, unless otherwise defined, all technical and scientific terms used in this specification have the same meanings as those commonly understood by those skilled in the art to which this invention pertains. The terms used in this specification are intended solely for the purpose of describing specific embodiments and are not intended to limit the invention. The term "and / or" as used in this specification includes any and all combinations of one or more of the associated listed items.

[0028] Unless otherwise defined, technical or scientific terms used in this disclosure should have the same general meaning as those generally understood by persons skilled in the art in the art to which this disclosure pertains. The terms "first," "second," and similar terms used in this disclosure do not denote any order, quantity, or importance, but are merely used to distinguish different components.

[0029] like Figure 1 As shown, a method for controlling unauthorized access according to the present invention is shown, comprising the following steps:

[0030] Step S1: Receive an API access request.

[0031] It should be noted that all API accesses covered by this invention use the API gateway as a unified entry point. The API access request includes the API information of the first API to be accessed, as well as the user information of the first user to be accessed. The API information includes the API unique identifier, and the user information includes the user unique identifier and user role. The user unique identifier is the user ID for accessing the API.

[0032] Before step S1, it is necessary to create different types of external applications and configure an initial API set accessible to users of the external applications according to the type of the external applications. The initial API set includes multiple APIs that users can access through the corresponding external applications.

[0033] In this embodiment, the types of external applications include a first application type and a second application type. The external application of the first application type belongs to the same software system as the API background software, and the data of the two are stored in the same location. The external application of the first application type includes but is not limited to WEB application portals, APP applications, mini-program applications, desktop applications, etc. The external application of the second application type does not belong to the same software system as the API background software, and can be called a third-party application. Usually, the external application of the second application type has a smaller number of APIs that can be accessed by users through this type of external application. For third-party applications, taking Baidu as an example, Baidu can provide users with multiple APIs. For example, Baidu provides four APIs A, B, C, and D related to Baidu Map Services. If users use Baidu Map Services through the campus software platform of the Internet of Things Company, then the campus software platform is a third-party application relative to the API background software that provides Baidu Map Services.

[0034] For external applications of the first application type, a series of function menus are defined to configure multiple APIs that users can access through the pages corresponding to each function menu. Different user roles have different function menu access permissions. Based on the function menu access permissions corresponding to the user role and the multiple APIs corresponding to the function menus, all APIs accessible to users of the corresponding user role are obtained, that is, the initial set of APIs accessible to users of the corresponding user role is obtained.

[0035] Specifically, if Figure 2 As shown, for an external application of the first application type, obtaining an initial set of APIs accessible to users of the corresponding user role includes the following sub-steps:

[0036] Step S011: define a function menu set.

[0037] The function menu set includes multiple function menus corresponding to multiple pages of the external application, and each function menu includes multiple APIs that the user can access through the page corresponding to the function menu.

[0038] Step S012: define multiple user roles, and authorize specific function menu permissions for each user role.

[0039] Among them, after authorizing specific function menu permissions to each user role, the function menu accessible to users of each user role can be obtained.

[0040] Step S013: Determine the initial set of APIs accessible to users corresponding to each user role.

[0041] Among them, users with different user roles have different access rights on different pages. According to the multiple APIs corresponding to each function menu and the function menus accessible to users of each user role, the initial API set accessible to users corresponding to a specific user role can be determined.

[0042] It should be noted that different function menus may correspond to the same API. Therefore, each initial API set can actually be regarded as a union of multiple APIs corresponding to various function menus that users of corresponding user roles are authorized to access.

[0043] As an example, combining Figure 3 As shown, the function menu set can be represented as [menu_a, menu_b, menu_c, ...], where each element in the function menu set corresponds to function menu a, function menu b, function menu c, and so on. Since each function menu corresponds to multiple APIs, the function menu set can be further represented as {menu_a: [api_a, api_b, ...], menu_b: [api_a, api_c, api_d, ...], ...}; for menu_a: [api_a, api_b, ...], "api_a, api_b, ..." represents the unique API identifiers of the multiple APIs corresponding to function menu a. If user role userRoleA is granted the function menu permission userRoleA: [menu_a, menu_b, ...], then the initial set of APIs accessible to user role userRoleA is the union of the multiple APIs corresponding to the function menus authorized to user role userRoleA, resulting in: userRoleA: [api_a, api_b, api_c, api_d, ...]. This allows the user to obtain an initial set of APIs accessible to the specific user based on the external application of the first user type. By restricting access to only this initial set of APIs, the user is prevented from accessing unauthorized APIs through the external application. Subsequently, in step S2, the first user can be assigned to a specific user role based on the acquired user information, thereby determining the initial set of APIs accessible to the first user.

[0044] Among them, for external applications of the second application type, there is no need to distinguish user roles. The initial API set that can be accessed through the external application can be directly authorized to all users by manually configuring the API, preventing users from accessing unauthorized APIs through the external application.

[0045] Step S2: Based on the preset initial API set and the API access request, determine whether the first user's access to the first API is authorized access or a first unauthorized access.

[0046] It should be noted that the first unauthorized access refers to an external application user accessing an API for which he or she has no permission.

[0047] Among them, based on the API unique identifier of the first API in the API access request, it is determined whether there is an API with the same API unique identifier as the first API in the preset initial API set. If so, it is determined that the first user's access to the first API is authorized access, that is, the first user's access to the first API does not constitute the first unauthorized access, thereby achieving control of the first unauthorized access and preventing the first user from accessing an API to which he does not have access rights.

[0048] like Figure 4 As shown, for an external application of the first application type, step S2 includes the following sub-steps:

[0049] Step S211: According to the user information of the first user, determine that the initial API set accessible to the first user is the first API set.

[0050] Step S212: Determine whether the first API set includes the first API. If the first API set includes the first API, proceed to step S213. If the first API set does not include the first API, proceed to step S214.

[0051] Step S213: Determine whether the first user's access to the first API is authorized.

[0052] Step S214: Determine whether the first user has no right to access the first API.

[0053] Specifically, first, based on the user role of the first user, determine that the initial API set accessible to the first user is the first API set, which is a set of all APIs that the first user can access through the corresponding external application. Then, determine whether there is an API in the first API set that is identical to the API unique identifier of the first API; if there is an API in the first API set that is identical to the API unique identifier of the first API, it means that the first API is included in the first API set, and it can be determined that the first user has the right to access the first API, and the corresponding API access request is successful, and a prompt is displayed on the user side that the request is successful. If there is no API in the first API set that is identical to the API unique identifier of the first API, it means that the first user does not have the right to access the first API, and the corresponding API access request fails, and a prompt is displayed on the user side that the access is inaccessible.

[0054] like Figure 5 As shown, for an external application of the second application type, step S2 includes the following sub-steps:

[0055] Step S221: Determine whether the external application is a legitimate application. If the external application is a legitimate application, proceed to step S222. If the external application is an illegal application, proceed to step S225.

[0056] Step S222: Determine that the initial API set is the second API set.

[0057] Step S223: Determine whether the second API set includes the first API. If the second API set includes the first API, proceed to step S224. If the second API set does not include the first API, proceed to step S225.

[0058] Step S224: Determine whether the first user's access to the first API is authorized.

[0059] Step S225: Determine whether the first user has no right to access the first API.

[0060] Specifically, for external applications of the second application type, first, it is necessary to determine whether the external application used by the first user is a legal application. After determining that the external application is a legal application, the initial API set that the first user can access through the external application is obtained as the second API set; the second API set is a set of all APIs that the first user can access through the corresponding external application. Then, it is determined whether there is an API with the same API unique identifier as the first API in the second API set; if there is an API with the same API unique identifier as the first API in the second API set, it means that the first API is included in the second API set, and it can be determined that the first user has the right to access the first API, the corresponding API access request is successful, and a prompt is displayed on the user side that the request is successful. If there is no API with the same API unique identifier as the first API in the second API set, it means that the first user does not have the right to access the first API, the corresponding API access request fails, and a prompt is displayed on the user side that the access is inaccessible.

[0061] The legitimate application refers to an external application of the second application type created by the application management module of the API backend software. Based on the determination that the external application is a legitimate application, the first unauthorized access control is achieved by restricting the external application to only access APIs in the manually configured initial API set.

[0062] Step S3: Based on the first user's authorized access to the first API, a data access request from the first user is received.

[0063] It should be noted that after the first user successfully accesses the first API, they further make a data access request. The data access request includes data information of the pre-accessed first data. The first data is the data of a specific user that the first user may access within the first API. The data information includes a unique data identifier, which is the user ID of the user to which the data belongs and the data type ID of the data.

[0064] In this embodiment, before the first user accesses data through the first API, it is necessary to clarify which users' data and types the first user has the right to access, that is, to control the second unauthorized access of the first user.

[0065] Secondary unauthorized access refers to a user of an external application accessing the data of another user without authorization. Therefore, before step S1, secondary unauthorized access control must be implemented for all APIs. First, multiple characteristic elements of secondary unauthorized access control must be designed. These include: the user ID accessing the API, the user ID (set) to which the pre-accessed data belongs, and the data type ID of the pre-accessed data.

[0066] The second unauthorized access control logic must meet one of the following conditions:

[0067] Determine whether there is only one element in the user ID set to which the pre-access data belongs, and whether the element is the same as the user ID of the user accessing the API, and whether the user accessing the API has the right to access the data of the corresponding data type ID;

[0068] If there is at least one element in the user ID set to which the pre-access data belongs that is different from the user ID of the user accessing the API, then this set is recorded as the user ID replacement set. All user IDs to which the pre-access data belongs in the user ID replacement set are traversed, and all users accessing the API have access rights to the data of "user ID to which the pre-access data belongs + data type ID of the pre-access data".

[0069] like Figure 6As shown, for the second unauthorized access control for the first user, first, determine whether the first user ID is the only one in the first ID set. If so, the first user can access the corresponding data and the first user ID is recorded. If the first ID set does not contain the only one (does not contain the first user ID / includes other user IDs besides the first user ID), the first ID set is replaced with the second ID set that does not contain the first user ID. Second, determine whether the first user has access to the data corresponding to the nth user ID in the second ID set. If the first user has access to the data corresponding to the nth user ID in the second ID set, it indicates that the first user can access the data corresponding to the nth user ID and the nth user ID is recorded. If the first user does not have access to the data corresponding to the nth user ID in the second ID set, it indicates that the first user cannot access the data corresponding to the nth user ID. Then, determine whether all user IDs in the second ID set have been traversed; if not, set n=n+1 and return to the step of determining whether the first user has access rights to the data corresponding to the nth user ID in the second ID set; if all user IDs in the second ID set have been traversed, then obtain the user ID of the corresponding user for all data accessible by the first user.

[0070] It should be noted that the first user ID set is the set of user IDs corresponding to all data that the first user may access through the first API. The first user ID set corresponds to the user ID set to which the pre-access data belongs. If the first user has access rights to the data consisting of "the user ID to which the pre-access data belongs + the data type ID of the pre-access data", then the pre-access data corresponding to all user IDs in the first user ID set (the user ID set to which the pre-access data belongs) can be accessed by the first user, and all recorded user IDs correspond one-to-one with all user IDs in the first user ID set.

[0071] To ensure that the above solution is feasible, it is necessary to solve the problem of how to generate multiple feature element data and how to determine whether users accessing the API have access rights to the data of "user ID to which the pre-access data belongs + data type ID of the pre-access data".

[0072] First, we design multiple characteristic elements corresponding to API access (accessing specific data through the corresponding API). Second, we configure the corresponding plug-ins for each API. The plug-ins contain permission judgment functions that can determine data access permissions. This allows the plug-ins to implement the corresponding data access permission judgment functions.

[0073] In this embodiment, the multiple characteristic elements corresponding to the API access include the user ID accessing the API, the user ID (set) to which the pre-access data belongs, and the data type ID of the pre-access data. The user ID accessing the API is taken from the API Header request parameter. For the user ID set to which the pre-access data belongs (including the user IDs to which all pre-access data belongs), the API request body is a JSON structure. When defining the API, configure which nodes of the JSON structure the data corresponding to the user ID set to which the pre-access data belongs is obtained. For example, the JSON structure is , the value of the user ID set to which the pre-access data belongs is the node es and xs The corresponding node expression is: . The rule for node expression is: the path node sequence from the root node of the JSON structure to this node. If the path node is a mapping type, the value is K_ + the KEY value of the mapping; if the path node is an array type, the value is A_ + the subscript of the array where the path node is located, and the starting value of the subscript is 0. As for the data type ID of the pre-access data, when defining the API, a mapping relationship between the API URL (API website) and the data type ID of the pre-access data is configured. The corresponding data type ID of the pre-access data can be obtained based on the API URL.

[0074] Furthermore, a plug-in library is defined, which includes multiple plug-ins, each of which contains a corresponding permission judgment function. Then, a plug-in framework is defined, which includes the plug-ins in the plug-in library. Among them, the permission judgment function is Judge(userId, DataUserId, dataTypeId), and Judge() contains the corresponding permission judgment logic. UserId, DataUserId, and dataTypeId correspond to the user ID for accessing the API, the user ID to which the pre-accessed data belongs, and the data type ID of the pre-accessed data, respectively. Plug-ins are dynamically deployed to the plug-in framework in a plug-and-play manner. Different plug-ins can implement different permission judgment logic in the corresponding permission judgment function.

[0075] Among them, since the business carried by the business software is fixed and the category of the permission judgment logic is also fixed, a fixed plug-in library can be defined first. The plug-in library includes multiple plug-ins. These plug-ins can implement different permission judgment logic in the corresponding permission judgment function. For example, if it is determined that the user U2 to whom the pre-access data belongs belongs to the user role UserRoleA, and the user U1 accessing the API has access rights to the data of the user U2 to whom the pre-access data belongs, whose user role is UserRoleA and the corresponding data type is the second data type T2 (the corresponding data type ID is dataTypeId T2), then the user U1 accessing the API can access the data of the second data type T2 of user U2.

[0076] Based on this, users can use each API to access the data type of the corresponding data, use the corresponding plug-in, and according to the corresponding permission judgment function, determine whether the user accessing the corresponding API has the access permission to the data of "user ID to which the pre-access data belongs + data type ID of the pre-access data", that is, whether the user accessing the corresponding API has the permission to access the data of a certain user and a certain data type.

[0077] In this embodiment, after receiving the data access request of the first user, it is determined whether there is a user ID that is the same as the user ID of the user to which the first data belongs among the user IDs of the corresponding users of all the recorded data accessible to the first user; if there is a user ID that is the same as the user ID of the user to which the first data belongs, it indicates that the first user can access the first data, and the process goes to step S4; if there is no user ID that is the same as the user ID of the user to which the first data belongs, it indicates that the first user cannot access the first data, the corresponding data access request fails, and a prompt is displayed on the user side that the access is inaccessible.

[0078] Step S4: Obtain a first data type corresponding to the first API according to the user information of the first user and the data information of the first data.

[0079] It should be noted that when a user uses an API to access data, the API generally corresponds to one data type; when a user uses multiple APIs to access data, different APIs may correspond to the same data type or different types of data types.

[0080] In this embodiment, based on the API access request in step S1 and the data access request in step S3, the ID of the user accessing the first API is obtained as the first user ID (userId1), the user ID to which the first data to be pre-accessed belongs is the first data user ID (DataUserId1), and the data type ID of the pre-accessed first data is the first data type ID (DataTypeId1).

[0081] Among them, according to the user unique identifier of the first user (first user ID) and the data unique identifier of the first data (first data user ID and first data type ID), the first data type T1 corresponding to the first API is determined, thereby obtaining the first plug-in corresponding to the first data type T1. The first plug-in can be further used to determine whether the first user's access to the first data is authorized.

[0082] Step S5: judging, based on the plug-in corresponding to the first data type, whether the first user's access to the first data is authorized access or second unauthorized access.

[0083] It should be noted that when defining each API, you need to configure which plug-in to use for permission judgment for each API. Then, based on the access to the corresponding data in the API, you can call the permission judgment function in the corresponding plug-in to complete the data access permission judgment.

[0084] In this embodiment, a first plug-in in a plug-in library corresponding to the first API is called, and a permission determination function in the first plug-in is used to determine whether the first user has the right to access the first data.

[0085] Among them, when the first data is the data of the second user and the first data type, if the first user has the right to access the data of the second user and the first data type, it can be determined that the first user's access to the first data is authorized access; when the first data is the data of the third user and the first data type, if the first user has no right to access the data of the third user and the first data type, it can be determined that the first user's access to the first data is unauthorized access, that is, the second unauthorized access control is implemented for the first user.

[0086] In the above process, by controlling the second unauthorized access, the first user can be prevented from accessing the data of other unauthorized users.

[0087] In this application, by controlling the first unauthorized access and the second unauthorized access, the user's unauthorized access to the API and corresponding data is controlled, which can effectively ensure the operation security and data security of the API background software.

[0088] Based on the same inventive concept, Figure 7 As shown, the present invention also provides an unauthorized access control device, the device comprising:

[0089] The API access receiving unit 101 is used to receive an API access request, which includes API information of a pre-accessed first API and user information of a first user who pre-accesses the first API. The API information includes an API unique identifier, and the user information includes a user unique identifier and a user role.

[0090] The first determination unit 102 is configured to determine, based on a preset initial API set and an API access request, whether the first user's access to the first API is authorized access or a first unauthorized access.

[0091] The data access receiving unit 103 is configured to receive a data access request from a first user based on the first user's authorized access to the first API, where the data access request includes data information of the pre-accessed first data.

[0092] The data type acquiring unit 104 is configured to acquire a first data type corresponding to the first API according to the user information of the first user and the data information of the first data.

[0093] The second judgment unit 105 is configured to judge, based on the plug-in corresponding to the first data type, whether the first user's access to the first data is authorized access or second unauthorized access.

[0094] In this application, other technical features of the above-mentioned unauthorized access control device are the same as the features disclosed in the above-mentioned method embodiment, and will not be repeated here.

[0095] Based on the same inventive concept, the present application also provides an electronic device, which includes a processor, a memory and a communication circuit, and the processor is connected to the memory and the communication circuit respectively; wherein the communication circuit is used for communication connection, the memory is used to store a computer program, and the processor is used to execute the computer program to implement the above method.

[0096] See also Figure 8 The electronic device described in the embodiment of the present application may specifically include a processor 210 and a memory 220 . The memory 220 is coupled to the processor 210 .

[0097] Processor 210 is used to control the operation of the electronic device. Processor 210 may also be referred to as a CPU (Central Processing Unit). Processor 210 may be an integrated circuit chip with signal processing capabilities. Processor 210 may also be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component. A general-purpose processor may be a microprocessor, or processor 210 may be any conventional processor.

[0098] The memory 220 is used to store computer programs and can be RAM, ROM, or other types of storage terminals. Specifically, the memory 220 may include one or more computer-readable storage media, which may be non-transitory or transient. The memory 220 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage terminals and flash memory storage terminals. In some embodiments, the non-transitory computer-readable storage medium in the memory 220 is used to store at least one program code.

[0099] The processor 210 is configured to execute the computer program stored in the memory 220 to implement the methods described in the various method embodiments of the present application.

[0100] In some embodiments, the electronic device may further include a peripheral terminal interface 230 and at least one peripheral terminal. The processor 210, memory 220, and peripheral terminal interface 230 may be connected via a bus or signal lines. Each peripheral terminal may be connected to the peripheral terminal interface 230 via a bus, signal lines, or circuit boards. Specifically, the peripheral terminal includes at least one of a radio frequency circuit 240, a display screen 250, an audio circuit 260, and a power supply 270.

[0101] The peripheral terminal interface 230 can be used to connect at least one peripheral terminal related to I / O (Input / Output) to the processor 210 and the memory 220. In some embodiments, the processor 210, the memory 220, and the peripheral terminal interface 230 are integrated on the same chip or circuit board; in some other implementations, any one or two of the processor 210, the memory 220, and the peripheral terminal interface 230 can be implemented on separate chips or circuit boards, which is not limited in this embodiment.

[0102] The RF circuit 240 is used to receive and transmit RF (Radio Frequency) signals, also known as electromagnetic signals. The RF circuit 240 communicates with communication networks and other IoT devices via electromagnetic signals, and is therefore the communication circuitry of the electronic device. The RF circuit 240 converts electrical signals into electromagnetic signals for transmission, or converts received electromagnetic signals into electrical signals. Optionally, the RF circuit 240 includes an antenna system, an RF transceiver, one or more amplifiers, a tuner, an oscillator, a digital signal processor, a codec chipset, an operator identification module card, and the like. The RF circuit 240 can communicate with other terminals via at least one wireless communication protocol. Such wireless communication protocols include, but are not limited to, the World Wide Web, metropolitan area networks, intranets, various generations of mobile communication networks (2G, 3G, 4G, and 5G), wireless local area networks, and / or WiFi (Wireless Fidelity) networks. In some embodiments, the RF circuit 240 may also include circuitry related to Near Field Communication (NFC), although this application does not limit this.

[0103] The display screen 250 is used to display a user interface (UI). This UI may include graphics, text, icons, videos, or any combination thereof. When the display screen 250 is a touch screen, it is also capable of collecting touch signals on or above the surface of the display screen 250. These touch signals can be input as control signals to the processor 210 for processing. In this case, the display screen 250 can also be used to provide virtual buttons and / or a virtual keyboard, also known as soft buttons and / or a soft keyboard. In some embodiments, there can be one display screen 250, disposed on the front panel of the electronic device; in other embodiments, there can be at least two display screens 250, disposed on different surfaces of the electronic device or in a foldable design; in still other embodiments, the display screen 250 can be a flexible display, disposed on a curved or foldable surface of the electronic device. Furthermore, the display screen 250 can be configured as a non-rectangular irregular shape, i.e., a special-shaped screen. The display screen 250 can be made of materials such as LCD (Liquid Crystal Display) and OLED (Organic Light-Emitting Diode).

[0104] The audio circuit 260 may include a microphone and a speaker. The microphone is used to collect sound waves from the operator and the environment, and convert the sound waves into electrical signals to be input into the processor 210 for processing, or input into the radio frequency circuit 240 to achieve voice communication. For the purpose of stereo acquisition or noise reduction, there may be multiple microphones, which are respectively arranged in different parts of the electronic device. The microphone may also be an array microphone or an omnidirectional acquisition microphone. The speaker is used to convert the electrical signals from the processor 210 or the radio frequency circuit 240 into sound waves. The speaker may be a traditional thin film speaker or a piezoelectric ceramic speaker. When the speaker is a piezoelectric ceramic speaker, it can not only convert the electrical signals into sound waves audible to humans, but also convert the electrical signals into sound waves inaudible to humans for purposes such as ranging. In some embodiments, the audio circuit 260 may also include a headphone jack.

[0105] Power supply 270 is used to power various components in the electronic device. Power supply 270 can be AC power, DC power, a disposable battery, or a rechargeable battery. When power supply 270 includes a rechargeable battery, the rechargeable battery can be a wired rechargeable battery or a wireless rechargeable battery. A wired rechargeable battery is a battery that is charged via a wired line, while a wireless rechargeable battery is a battery that is charged via a wireless coil. The rechargeable battery can also be used to support fast charging technology.

[0106] For a detailed description of the functions and execution processes of the various functional modules or components in the electronic device embodiments of the present application, reference can be made to the descriptions in the above-mentioned method embodiments of the present application, which will not be repeated here.

[0107] In the several embodiments provided in this application, it should be understood that the disclosed electronic devices and methods can be implemented in other ways. For example, the various embodiments of the electronic devices described above are merely illustrative. For example, the division of modules or units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0108] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0109] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0110] Based on the same inventive concept, the present application also provides a computer-readable storage medium storing a computer program, which can be executed by a processor to implement the above method.

[0111] See also Figure 9 If the above-mentioned integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium 300. Based on this understanding, the technical solution of the present application, or the part that contributes to the existing technology, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a number of instructions / computer programs to enable an IoT device (which can be a personal computer, server, or network terminal, etc.) or a processor to execute all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes various media such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, as well as electronic terminals such as computers, mobile phones, laptops, tablet computers, cameras, etc. that have the above-mentioned storage media.

[0112] For the description of the execution process of the program data in the computer-readable storage medium, reference can be made to the description in the above-mentioned method embodiments of the present application, which will not be repeated here.

[0113] It can be seen that the present invention discloses an unauthorized access control method, device, equipment and medium, which includes the following steps: receiving an API access request, the API access request including API information of a pre-accessed first API, and user information of a first user who pre-accesses the first API, the API information including an API unique identifier, and the user information including a user unique identifier and a user role; judging whether the first user's access to the first API is authorized access or a first unauthorized access based on a preset initial API set and the API access request; receiving a data access request from the first user based on the first user's authorized access to the first API, the data access request including data information of the pre-accessed first data; obtaining a first data type corresponding to the first API based on the first user's user information and the data information of the first data; judging whether the first user's access to the first data is authorized access or a second unauthorized access based on the plug-in corresponding to the first data type. The present invention controls the user's unauthorized access to the API and the corresponding data by controlling the first unauthorized access and the second unauthorized access, thereby effectively protecting the operation and data security of the API background software.

[0114] The above are merely embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any equivalent structural transformations made using the contents of the present invention's description and drawings, or directly or indirectly applied to other related technical fields, are included in the scope of protection of the present invention.

Claims

1. A method for controlling unauthorized access to an API by different types of external applications, characterized in that: The method comprises the following steps: Creating external applications of a first application type and a second application type respectively, wherein the external application of the first application type and the API backend software belong to the same software system, and the external application of the second application type and the API backend software do not belong to the same software system; Receive an API access request, the API access request including API information of a first API to be pre-accessed and user information of a first user who is to pre-access the first API, the API information including an API unique identifier, and the user information including a user unique identifier and a user role; Determining, based on a preset initial API set and the API access request, whether the first user's access to the first API is authorized access or a first unauthorized access, wherein the initial API set is configured based on the type of the external application, the initial API set includes multiple APIs that the user can access through the corresponding external application, and: Determine whether it is authorized access or first unauthorized access as follows: Determining, based on the user information of the first user, that the initial API set accessible to the first user is a first API set; Determine whether the first API is included in the first API set; If the first API is included in the first API set, determining that the first user has the right to access the first API; Or determine whether it is authorized access or first unauthorized access as follows: Determining whether the external application is a legitimate application; If the external application is a legitimate application, determining that the initial API set is a second API set; Determine whether the second API set includes the first API; If the second API set includes the first API, it is determined that the first user has the right to access the first API: Based on the first user's authorized access to the first API, receiving a data access request from the first user, the data access request including data information of pre-accessed first data; Obtaining a first data type corresponding to the first API according to the user information of the first user and the data information of the first data; According to the plug-in corresponding to the first data type, it is determined whether the first user's access to the first data is authorized access or second unauthorized access.

2. The unauthorized access control method according to claim 1, characterized in that: The method further comprises the steps of: The initial API set is configured according to the type of the external application, and includes a plurality of APIs accessible to users of the external application.

3. The unauthorized access control method according to claim 2, characterized in that: The type of the external application includes a first application type, and configuring the initial API set according to the type of the external application includes the steps of: Defining a function menu set, wherein the function menu set includes multiple function menus, and the function menu includes multiple APIs that a user can access through a page corresponding to the function menu; Define multiple user roles and authorize specific function menu permissions for each user role; Determine an initial set of APIs accessible to users corresponding to each user role.

4. The unauthorized access control method according to claim 2, wherein: The type of the external application includes a second application type, and configuring the initial API set according to the type of the external application includes the steps of: The initial API set accessible to users of the external application is manually configured.

5. The unauthorized access control method according to claim 1, characterized in that: The method further comprises the steps of: Designing multiple characteristic elements corresponding to API access, wherein the multiple characteristic elements include a user ID for accessing the API, a set of user IDs to which pre-access data belongs, and a data type ID of the pre-access data; Define a plug-in library, the plug-in library includes multiple plug-ins, each of the plug-ins includes a permission judgment function; A plug-in framework is defined, the plug-in framework includes the plug-in, and the plug-in is dynamically deployed into the plug-in framework in a plug-and-play manner, so that the plug-in implements corresponding data access permission judgment through the permission judgment function.

6. An unauthorized access control device, characterized in that: The device comprises: An external application creation unit, configured to create external applications of a first application type and a second application type, respectively, wherein the external applications of the first application type and the API backend software belong to the same software system, and the external applications of the second application type and the API backend software do not belong to the same software system; An API access receiving unit is configured to receive an API access request, wherein the API access request includes API information of a first API to be pre-accessed and user information of a first user who pre-accesses the first API, wherein the API information includes an API unique identifier, and the user information includes a user unique identifier and a user role; A first determination unit is configured to determine, based on a preset initial API set and the API access request, whether the first user's access to the first API is authorized access or a first unauthorized access, wherein the initial API set is configured based on the type of the external application, the initial API set includes multiple APIs that the user can access through the corresponding external application, and: The first judgment unit is configured to judge whether it is authorized access or first unauthorized access in the following manner; Determining, based on the user information of the first user, that the initial API set accessible to the first user is a first API set; Determine whether the first API is included in the first API set; If the first API is included in the first API set, determining that the first user has the right to access the first API; Alternatively, the first judgment unit is configured to judge whether the access is authorized or the first unauthorized access in the following manner: Determining whether the external application is a legitimate application; If the external application is a legitimate application, determining that the initial API set is a second API set; Determine whether the second API set includes the first API; If the second API set includes the first API, determining that the first user has the right to access the first API; a data access receiving unit, configured to receive a data access request from the first user based on the first user's authorized access to the first API, the data access request including data information of pre-accessed first data; a data type acquiring unit, configured to acquire a first data type corresponding to the first API according to the user information of the first user and the data information of the first data; The second judgment unit is used to judge whether the first user's access to the first data is authorized access or second unauthorized access based on the plug-in corresponding to the first data type.

7. An electronic device, characterized in that: The method comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the method according to any one of claims 1 to 5 when executing the computer program.

8. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 5 are implemented.

Images