CN112231617A

CN112231617A - Service call checking method and device, storage medium and electronic equipment

Info

Publication number: CN112231617A
Application number: CN202011085353.8A
Authority: CN
Inventors: 刘宏侠
Original assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd; Shenzhen Huantai Technology Co Ltd
Current assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd; Shenzhen Huantai Technology Co Ltd
Priority date: 2020-10-12
Filing date: 2020-10-12
Publication date: 2021-01-15

Abstract

The embodiment of the application discloses a service call checking method, a service call checking device, a storage medium and electronic equipment, wherein the method comprises the following steps: the method comprises the steps of obtaining a service calling request corresponding to a webpage, determining a service calling interface corresponding to the service calling request, determining a target authority level corresponding to the service calling interface, and verifying the service calling request by adopting a target verification mode corresponding to the target authority level. By adopting the embodiment of the application, the safety risk of service calling can be reduced.

Description

Service call checking method and device, storage medium and electronic equipment

Technical Field

The present application relates to the field of computer technologies, and in particular, to a service invocation checking method, apparatus, storage medium, and electronic device.

Background

At present, more and more electronic devices provide convenient Web services to users through running Web pages, applications developed based on Web technologies (hypertext markup language (HTML), JavaScript, CSS, and the like) run based on clients such as browsers, applications, applets, and the like, and the clients running in the electronic devices provide local function interfaces for upper-layer Web pages to use, for example, Web pages can realize Web page loading and updating by calling interface services corresponding to the local function interfaces.

In the process of calling the webpage interfaces, the webpage calls interfaces related to user privacy, equipment information and the like and having security leakage risks, and if the webpage calls the interfaces to share the acquired interface data to other equipment or execute some illegal operations according to the interfaces, serious security risks exist.

Disclosure of Invention

The embodiment of the application provides a service call checking method, a service call checking device, a storage medium and electronic equipment, and can reduce the safety risk of service call. The technical scheme of the embodiment of the application is as follows:

in a first aspect, an embodiment of the present application provides a service call checking method, where the method includes:

acquiring a service calling request corresponding to a webpage, and determining a service calling interface corresponding to the service calling request;

determining a target authority level corresponding to the service calling interface;

and verifying the service calling request by adopting a target verification mode corresponding to the target authority level.

In a second aspect, an embodiment of the present application provides a service invocation checking apparatus, where the apparatus includes:

the calling request acquisition module is used for acquiring a service calling request corresponding to a webpage and determining a service calling interface corresponding to the service calling request;

the permission level determining module is used for determining a target permission level corresponding to the service calling interface;

and the calling request checking module is used for checking the service calling request by adopting a target checking mode corresponding to the target authority level.

In a third aspect, embodiments of the present application provide a computer storage medium storing a plurality of instructions adapted to be loaded by a processor and to perform the above-mentioned method steps.

In a fourth aspect, an embodiment of the present application provides an electronic device, which may include: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to perform the above-mentioned method steps.

The beneficial effects brought by the technical scheme provided by some embodiments of the application at least comprise:

in one or more embodiments of the present application, a client obtains a service invocation request corresponding to a web page, determines a service invocation interface corresponding to the service invocation request, determines a target permission level corresponding to the service invocation interface, and verifies the service invocation request by using a target verification manner corresponding to the target permission level. The target permission level corresponding to the service calling interface to be called is determined according to the service calling request of the webpage, and the service calling request is verified according to the verification mode corresponding to the target permission level, so that the safety risk occurring when the webpage directly calls the interface provided by the client in the related technology can be reduced, the permission level based on the service calling interface is verified by adopting the corresponding verification mode, different permission levels can use different safer verification modes, the safety of service calling verification is improved, and the safety risk in the service calling process corresponding to the interface is reduced.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.

Fig. 1 is a schematic flowchart of a service call checking method according to an embodiment of the present application;

fig. 2 is a schematic flowchart of another service call checking method provided in an embodiment of the present application;

fig. 3 is a schematic flowchart of a request check provided in an embodiment of the present application;

fig. 4 is a schematic flowchart of a third verification method according to an embodiment of the present application;

fig. 5 is a schematic flowchart of acquiring a white list of an interface according to an embodiment of the present disclosure;

fig. 6 is a schematic flowchart of another service call checking method provided in the embodiment of the present application;

fig. 7 is a schematic structural diagram of a service call checking apparatus according to an embodiment of the present application;

FIG. 8 is a schematic structural diagram of a first inspection unit provided in an embodiment of the present application;

FIG. 9 is a schematic structural diagram of a third inspection unit provided in the embodiments of the present application;

fig. 10 is a schematic structural diagram of an electronic device provided in an embodiment of the present application;

FIG. 11 is a schematic structural diagram of an operating system and a user space provided in an embodiment of the present application;

FIG. 12 is an architectural diagram of the android operating system of FIG. 10;

FIG. 13 is an architectural diagram of the IOS operating system of FIG. 10.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

In the description of the present application, it is to be understood that the terms "first," "second," and the like are used for descriptive purposes only and are not to be construed as indicating or implying relative importance. In the description of the present application, it is noted that, unless explicitly stated or limited otherwise, "including" and "having" and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, article, or apparatus that comprises a list of steps or elements is not limited to only those steps or elements listed, but may alternatively include other steps or elements not listed, or inherent to such process, method, article, or apparatus. The specific meaning of the above terms in the present application can be understood in a specific case by those of ordinary skill in the art. Further, in the description of the present application, "a plurality" means two or more unless otherwise specified. "and/or" describes the association relationship of the associated objects, meaning that there may be three relationships, e.g., a and/or B, which may mean: a exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship.

The present application will be described in detail with reference to specific examples.

In one embodiment, as shown in fig. 1, a service call verification method is proposed, which may be implemented in dependence on a computer program, which may run on a von neumann based service call verification device. The computer program may be integrated into the application or may run as a separate tool-like application.

Specifically, the service call checking method includes:

step S101: the method comprises the steps of obtaining a service calling request corresponding to a webpage and determining a service calling interface corresponding to the service calling request.

When a user browses a web page in a client (e.g., an electronic device with an application), resonance, interest, and a demand may be generated on a web page address, a web page element in the web page, and the web page corresponding to the client needs to call a corresponding interface to perform web page processing, for example, call a search interface to perform search, call a payment interface to perform payment, call a voice recognition interface to perform recognition, call a sharing interface to perform sharing, call an information acquisition interface to perform information acquisition, and the like.

Further, in the actual application process after the developer completes development, when the developer implements the above functions or displays web page elements (text, animation, etc.), a corresponding service call request is generated, where the service call request is used to request or instruct the client to call a corresponding service call interface to provide a corresponding interface service, where the service call interface may be understood as various APIs that may be used when building an application program or an application service provided by an application framework layer corresponding to the client, and the web page developer may also build its own web page and drawing, processing, and user interaction events associated with the web page by using these APIs, response gestures, and the like, such as activity interaction time, window interface, view interface, notification event, location management, and the like.

Specifically, in this embodiment, the service call checking method may be applied to a software and hardware environment formed by a terminal corresponding to the client. In some embodiments, the terminal has a client installed therein, the client supports an application running a web page, and the client receives a service invocation request (usually used for interface invocation) sent by the web page, further, the web page may be an actual web page application, that is, an application running on the web page and having no capability of directly invoking a system interface, or an actual application in an application installed at the client; the service invocation request is used for requesting a system interface (namely, a service invocation interface) of an operating system of the invocation terminal to execute target operations, such as resource acquisition, interaction, payment, search and the like.

In a possible implementation manner, the service invocation request may carry a target interface identifier of the service invocation interface; determining a service calling interface corresponding to the target interface identifier from the interface identifiers with the corresponding relation and a plurality of system interfaces; so as to respond to the service calling request to call the service calling interface to execute the corresponding target operation after the service calling verification of the embodiment is executed.

In a possible implementation manner, the service invocation request may carry interface parameter values, where the interface parameter values are used to characterize an interface called by the service invocation request of the web page. For the sake of distinction, the interface requested to be called by the service call request is referred to as a service call interface. Further, after the client can obtain the service calling request corresponding to the web page, the client performs request analysis on the service calling request to obtain the interface parameter value carried in the service calling request, so that the service calling interface corresponding to the interface parameter value of the service calling request can be determined according to the mapping relationship between at least one interface corresponding to the client and the interface parameter value.

Specifically, the application scenario may be, but not limited to, a scenario in which a web page calls a system interface corresponding to a client. The client may be, but not limited to, a client operating various types of supporting web pages, such as an online education client, an instant messaging client, a community space client, a game client, a shopping client, a browser client, a financial client, a multimedia client, a live broadcast client, and the like. Further, the present invention may be, but is not limited to, applied in a scenario where a web application in the instant messaging client calls a system interface, or may also be, but is not limited to, applied in a scenario where a web application in the browser client calls a system interface (that is, a service call interface), which is not limited in this embodiment.

Step S102: and determining a target authority level corresponding to the service calling interface.

In this embodiment, in the process of the web page performing the service invocation based on the service invocation request, there may be some important interfaces that are sensitive to the user security, the user privacy, and the like, such as obtaining user information, obtaining a user photo, obtaining a user short message, and the like, requested to invoke, or by invoking some interfaces, security restrictions on a device corresponding to the client are bypassed. If an illegal webpage (such as a front-end H5 page) can call the important interfaces, then important data are obtained according to the interfaces and reported to a corresponding server, the conditions that the privacy of a user is revealed or great potential safety hazards exist occur, and the safety risk is improved.

In this embodiment, in order to reduce the security risk of the web page call interface, an authority level set is obtained by performing authority level classification on at least one included interface on the electronic device corresponding to the client in advance according to interface attributes (such as an interface call type, interface call information, an interface function, call data corresponding to the interface, and the like), where the interface authority level set includes an authority level corresponding to the at least one interface, and a corresponding request verification manner is set in advance for one type of interfaces with different authority levels, so that the client can perform request verification in a verification manner corresponding to the corresponding authority level according to the authority level corresponding to the service call interface after determining the service call interface corresponding to the service call request. Therefore, the authority is hierarchically controlled based on the interface authority level set, and the service calling authority of the corresponding interface is requested and checked in a corresponding request checking mode, so that interface calling authority is hierarchically and hierarchically controlled according to the safety of the interface.

Specifically, in a preset interface permission level set, the terminal may search for a target permission level corresponding to an interface identifier in the interface permission level set based on the interface identifier of the service invocation interface, where the interface permission level set includes at least one permission level corresponding to the invocation interface.

Step S103: and verifying the service calling request by adopting a target verification mode corresponding to the target authority level.

In this embodiment, different authority levels correspond to different verification modes, the authority levels of different calling interfaces are divided according to the dimension of interface safe calling, corresponding verification modes are set for the corresponding authority levels, and when a client side verifies a calling interface of a service calling request, the client side only needs to adopt a target verification mode corresponding to a corresponding target authority level to verify the service calling request according to the target verification mode. For example, the interface permission level can be divided into a common permission, a primary permission, a secondary permission, a tertiary permission, and the like. If the interface authority level is the normal authority, the security level of the interface to be called of the service calling request is low, the webpage directly calls the calling interface corresponding to the normal authority based on the service calling request, and generally, no security risk exists, so that the interface calling method and the webpage calling system have the advantages of being safe and reliable. The common permission can be checked by directly setting the service calling request as a check pass so as to facilitate the direct checking of the webpage; for another example, when the interface permission level is the first-level permission, the security level of the interface to be called by the service calling request is medium, and the webpage directly calls the calling interface corresponding to the common permission based on the service calling request, so that certain security risk exists. The client may obtain an attribute tag (e.g., meta tag) corresponding to the service invocation request, perform verification in a verification manner such as an authority limit and list authentication, and perform verification. Further, after the client checks the service calling request, whether the webpage is allowed to call the corresponding service calling interface based on the service calling request is determined based on the checking result.

In the embodiment of the application, a client acquires a service calling request corresponding to a webpage, determines a service calling interface corresponding to the service calling request, determines a target permission level corresponding to the service calling interface, and verifies the service calling request by adopting a target verification mode corresponding to the target permission level. The target permission level corresponding to the service calling interface to be called is determined according to the service calling request of the webpage, and the service calling request is verified according to the verification mode corresponding to the target permission level, so that the safety risk occurring when the webpage directly calls the interface provided by the client in the related technology can be reduced, the permission level based on the service calling interface is verified by adopting the corresponding verification mode, different permission levels can use different safer verification modes, the safety of service calling verification is improved, and the safety risk in the service calling process corresponding to the interface is reduced.

Referring to fig. 2, fig. 2 is a schematic flowchart illustrating another embodiment of a service call checking method according to the present application. Specifically, the method comprises the following steps:

step S201: and acquiring a service calling request corresponding to the webpage.

Specifically, refer to step S101, which is not described herein again.

Step S202: and acquiring service calling information carried by the service calling request, and determining a service calling interface corresponding to the service calling information.

The service calling information is used for representing interface information to be called currently by the webpage, and the client can determine a corresponding service calling interface based on the service calling information.

In a specific implementation scenario, taking the service invocation information as an interface identifier as an example, the invocation request may carry the interface identifier of the service invocation interface; determining a service calling interface corresponding to the target interface identifier from the interface identifiers with the corresponding relation and a plurality of system interfaces; so as to respond to the service calling request to call the service calling interface to execute the corresponding target operation after the service calling verification of the embodiment is executed.

In a specific implementation scenario, taking the service invocation information as an interface parameter value as an example, the service invocation request may carry the interface parameter value, where the interface parameter value is used to represent an interface called by the service invocation request of the web page. For the sake of distinction, the interface requested to be called by the service call request is referred to as a service call interface. Further, after the client can obtain the service calling request corresponding to the web page, the client performs request analysis on the service calling request to obtain the interface parameter value carried in the service calling request, so that the service calling interface corresponding to the interface parameter value of the service calling request can be determined according to the mapping relationship between at least one interface corresponding to the client and the interface parameter value.

Step S203: and determining a target authority level corresponding to the service calling interface.

Specifically, refer to step S102, which is not described herein again.

Step S204: if the target permission level is a first permission level, verifying the service calling request by adopting a first verification mode corresponding to the first permission level;

in this embodiment, if the target permission level is the first permission level, the security level of the interface to be called of the service calling request is the lowest, and the webpage directly calls the calling interface corresponding to the common permission based on the service calling request, so that there is usually no security risk, and if the webpage calls the calling interface without involving security risk, user privacy and the like.

Specifically, after determining a target permission level corresponding to a service invocation interface, if the target permission level is a first permission level, and at this time, an interface to be invoked based on a service invocation request of a web page is not an interface related to user privacy such as user information, photos, address books, and the like, and there is a security risk during invocation, the client may perform verification by using a first verification method corresponding to the first permission level.

Step S205: if the target permission level is a second permission level, verifying the service calling request by adopting a second verification mode corresponding to the second permission level;

in this embodiment, if the target permission level is the second permission level, the security level of the interface to be called by the service call request is low at this time, it can be understood that in this embodiment, the call interface corresponding to the second permission level is used, and when the web page calls the interface, the interface data acquired through the interface is not data (such as photos, information, and telephone) related to user privacy and information security and sensitive data, but compared with the first permission level, there is a case where the web page calls the call interface corresponding to the second permission level based on the service call request, and there is a security risk, for example, the web page calls the call interface related to the user interaction operation.

In this embodiment, the service invocation request may be verified in a second verification manner corresponding to the second permission level pair for invocation interfaces such as the second permission level pair, further, the interface corresponding to the second permission level pair for web page invocation generally does not operate user sensitive data, the security level is low, the verification decision reference standard thereof may be issued by the server corresponding to the client (for example, a permission white list), and the client performs further request verification based on the reference standard to further control the interface permission.

Specifically, if the target permission level is the second permission level, in this embodiment, when the interface corresponding to the second permission level is called by the web page, for example, when the web page loads a web page element, in order to implement accurate verification of the second permission level in this embodiment, before loading a web page code, an attribute tag may be written into the web page, and when the attribute tag is used for calling the interface of the second permission level on the client, the interface data of the service calling interface corresponding to the second permission level may be acquired based on the attribute tag after the request verification passes, in a specific implementation: after determining that the target permission level is the second permission level, the client generally obtains a service invocation request of the web page, where the service invocation request carries an attribute tag, and the attribute tag is used for the client to verify the request, that is, the client can verify the service invocation request based on the attribute tag.

Further, the attribute tag usually includes at least one attribute category, and each attribute category may correspond to a corresponding attribute value, for example, the attribute category at least includes a request category, a signature category for requesting authentication, a permission deadline time corresponding to the called permission interface, and the like. Corresponding attribute parameters are generally corresponded to each attribute category, for example, a request category may correspond to a specific request type (e.g., request picture data, text data, interactive data, etc.), for example, a signature category for requesting authentication may correspond to a signature value, for example, a permission deadline time category may correspond to a deadline time corresponding to the interface, and so on. Further, in some embodiments, the attribute tag also has a condition that the attribute tag does not contain the attribute parameter, and the embodiment explains how to verify the service invocation request by using a second verification method corresponding to the second permission level by combining a specific attribute tag and whether the attribute parameter exists. Referring to the following implementation steps, fig. 3 is a schematic flow chart of a request check.

S2051: judging whether the attribute label has attribute parameters;

in this embodiment, in order to verify the service invocation request by using a corresponding second verification method when the target permission level is the second permission level, a written attribute tag, such as a < meta > tag, may be developed during development of an HTML webpage, where an element in the < meta > tag may provide meta-information (meta-information) about the page, that is, different types of attribute parameters may be defined, where an attribute type at least includes a request type, a signature type for requesting authentication, a permission expiration time of a permission interface corresponding to invocation, and the like.

Illustratively, the format of the attribute tag may be as follows:

for example, the attribute tag may be:

for example, the attribute tag may be:

<metaname＝"api-permission"content＝"BrowserStat|sign1|expireTime1,BrowserWebBrowserWeb|sign2|expireTime2"...>

for example, the attribute tag may be:

<metaname＝"api-permission"content＝"BrowserStat|sign1|expireTime1,BrowserWeb|sign2|expireTime2"...>

the "parameter" may represent an meta-type name or an meta-type value of the web page corresponding to the attribute tag, and the "content" may specifically represent a corresponding attribute parameter in the attribute tag, such as a signature value corresponding to a representation signature category and an authority deadline time value corresponding to an authority deadline time category;

in this embodiment, it is determined whether the attribute tag has an attribute parameter, that is, the attribute tag is correspondingly analyzed according to a predetermined tag configuration rule, so as to determine whether the attribute parameter corresponding to each attribute type exists in the attribute tag, for example, whether the authority limit time type has an authority limit time value, and whether the signature type corresponds to a signature value, and further, the above example is used for explanation, whether the attribute parameter corresponding to each attribute type exists in the attribute tag may be determined whether an attribute value exists in a metaname ═., "or may be determined whether an attribute value exists in a content ═.," or the like.

S2052: if the attribute parameters exist in the attribute tag, determining an interface verification state based on the authority limit in the attribute parameters, performing signature verification on the service calling request based on the interface verification state, and determining that the service calling request passes the verification based on the verification result of the signature verification;

in this embodiment, by determining whether an attribute parameter exists in the attribute tag, if it is determined that the attribute parameter exists in the attribute tag, an attribute value exists in the parameter. Then, the client verifies the service call request according to the attribute parameters, which specifically comprises the following steps:

in a specific implementation manner, a client may first obtain an authority limit in an attribute parameter, where the authority limit is used to indicate a limit time corresponding to an interface to be called of a web page, and it can be understood that if the current time is greater than the limit time, at this time, an interface authority expires, and the web page cannot call the interface based on a service call request; if the current time is less than or equal to the deadline time, the interface authority is not expired at this time, and the interface can be called based on the service calling request after other verification judgment of the webpage is passed.

The interface verification state at least comprises an unexpired state and an expired state, the unexpired state can be understood as that the interface authority limit called by the current webpage is not expired, the interface can be normally called by the webpage, and the expired state can be understood as that the interface authority limit called by the current webpage is expired, and the interface cannot be normally called by the webpage.

Further, the client acquires the current system time, then compares the system time with the authority limit, and if the system time is greater than the authority limit, determines that the interface limit check is passed, and sets the interface check state to be an unexpired state; if the system time is less than or equal to the authority limit, determining that the interface limit verification fails, and setting the interface verification state to be an expired state.

Specifically, the client performs signature verification on the service call request based on the interface verification state, and when the signature verification is performed, the client performs signature verification on the service call request

The signature verification is performed on the service calling request based on the interface verification state, and the service calling request is determined to pass the verification based on the verification result of the signature verification, which specifically includes the following steps:

if the interface verification state is an unexpired state, the client may obtain a signature parameter in the attribute parameters, for example, may obtain an attribute value, such as a signature parameter (e.g., sign1 described above), existing in the content.

Specifically, the client determines the signature verification status of the service invocation request based on the attribute tag and the signature parameter.

In this embodiment, a signature is recalculated or constructed based on the attribute tag by using a preset signature algorithm to obtain an actual signature value, and then the actual signature value is compared with the signature parameter to determine a signature verification state.

The signature algorithm may be at least one of a Hash signature algorithm, a DSA signature algorithm, an RSA signature algorithm, and the like. For example, a Hash signature algorithm may be adopted, and a string sign 256(domain + api + secertykey + expiretime) code is executed by calling the Hash signature algorithm, so as to construct a signature based on attribute parameters (such as an authority limit, interface information, a secret key, and the like) in an attribute tag, obtain an actual signature value, and then compare the actual signature value with the signature parameters.

If the actual signature value is matched with the signature parameter, and if the actual signature value is consistent with the signature parameter, determining that the signature verification state is that the signature verification passes;

if the actual signature value is not matched with the signature parameter, and if the actual signature value is not consistent with the signature parameter, determining that the signature verification state is that the signature verification fails;

further, after determining that the signature verification state is signature verification pass, the client may determine that the service invocation request passes verification, at this time, all verification of the service invocation request initiated by the web page is completed, and generally, the web page may invoke a corresponding interface directly based on the service invocation request.

S2053: if the attribute parameters do not exist in the attribute tag, when the service calling interface is determined to exist in a pre-stored first interface white list, acquiring the authority limit of the service calling interface in the interface white list, and determining that the service calling request passes the verification.

According to some embodiments, the attribute parameter is absent from the attribute tag in a specific implementation:

the client degree is that the attribute tag is correspondingly analyzed according to a preset tag construction rule, so as to determine whether the attribute tag has the attribute parameter corresponding to each attribute type, if the attribute parameter does not exist in the attribute tag, for example, the authority time type does not have the authority time limit value, and the signature type does not have the corresponding signature value, further, the explanation is performed by the above example, the attribute parameter corresponding to each attribute type does not exist in the attribute tag, and may be an attribute value does not exist in a metaname.

At this time, if the attribute parameters do not exist in the attribute tag, the client acquires a pre-stored first interface white list to determine whether the service calling interface exists;

the first interface white list is how to further check the service call request under the condition that the attribute parameters do not exist in the attribute tag in the interface checking process corresponding to the second authority level issued by the web page or the server corresponding to the client. The first interface white list comprises at least one calling interface and interface information related to the calling interface (such as authority limit, interface identification and the like of the interface).

The client can search a service calling interface in a first interface white list based on an interface identifier (such as an interface name) of the service calling interface, and when the service calling interface is determined to exist in a pre-stored first interface white list, the authority limit of the service calling interface in the interface white list is acquired;

then, the client acquires the current system time, then compares the system time with the authority limit, if the system time is greater than the authority limit, at the moment, the interface limit check is determined to be passed, and the interface check state is set to be an unexpired state; if the system time is less than or equal to the authority limit, determining that the interface limit verification fails, and setting the interface verification state to be an expired state.

Further, when the interface verification state is set to the unexpired state by the client, it can be determined that the service invocation request verification is passed.

Step S206: and if the target permission level is a third permission level, verifying the service calling request by adopting a third verification mode corresponding to the third permission level, wherein the second permission level is greater than the first permission level and less than the third permission level.

In this embodiment, if the target permission level is the third permission level, the security level of the interface to be called by the service call request is low at this time, it can be understood that in this embodiment, the interface data acquired through the interface is usually data (such as photos, information, and phones) related to user privacy, information security, and sensitivity, and there is a risk of data leakage, and the security level is high, and it is necessary for the server to intervene in controlling the permission. In addition, in some embodiments, the third permission level may further include a super permission, where the interface corresponding to the super permission is used to report an operation log of the client, such as a log associated with a user data line, and the interface corresponding to the super permission is usually a primary authorization, and after the web page uses the interface based on the service invocation request for the first time, the interface cannot be used again to obtain corresponding interface data based on the current service invocation request for the second time.

The implementation process of verifying the service invocation request by using the third verification mode corresponding to the third permission level is specifically as follows: referring to fig. 4, fig. 4 is a schematic flow chart related to a third verification method.

S2061, obtaining locally stored time limit information corresponding to the service calling interface, and determining an interface verification state corresponding to the service calling interface based on the time limit information.

The client can firstly acquire the authority limit of the service calling interface in the local storage, wherein the authority limit is used for indicating the limit time corresponding to the interface to be called of the webpage, and it can be understood that if the current time is greater than the limit time, the interface authority is expired at this moment, and the webpage cannot call the interface based on the service calling request; if the current time is less than or equal to the deadline time, the interface authority is not expired at this time, and the interface can be called based on the service calling request after other verification judgment of the webpage is passed. In some embodiments, the authority limit of each calling interface is issued by the server and is used for checking the service calling request of the web page, for example, the second interface white list issued by the server may include the authority limit of each calling interface.

S2062, if the interface verification status is the unexpired status, when it is determined that the service invocation interface exists in a pre-stored second interface white list, it is determined that the service invocation request verification passes, and the second interface white list is sent by the server when the web page is initialized.

The second interface white list comprises at least one calling interface and interface information related to the calling interface (such as authority limit, interface identification and the like of the interface).

If the interface verification state is the unexpired state, the client may search for a service invocation interface in a second interface white list based on an interface identifier (such as an interface name) of the service invocation interface, and when it is determined that the service invocation interface exists in a pre-stored second interface white list, it is determined that the service invocation request verification passes, where the second interface white list is sent by the server when the web page is initialized.

Further, the following step of sending the second interface white list by the server side during web page initialization is explained in detail as follows: referring to fig. 5, fig. 5 is a schematic flow chart of obtaining a white list of an interface.

S301, when the webpage is initialized, acquiring an initial calling request of the webpage for a preset calling interface.

The web page initialization can be understood as a process of loading a web page and finally displaying the web page when the web page is initially opened, generally, in the web page initialization process, a Domain Name Server (DNS) domain name of the web page is analyzed, the domain name is converted into a corresponding IP address, then, a TCP three-way handshake is initiated, web page connection is established, request data is initiated to a server corresponding to the web page, the server receives and responds to the request, a browser analyzes resources including html, css, js, pictures and the like, and finally, the browser is laid out, an interface is drawn and displayed.

In this embodiment, the initial call request of the web page for the preset call interface is: when a web page needs to initiate request data to a server (also referred to as a server), a client monitors and acquires an initial call request generated in a process of loading web page request data, and usually sends the initial call request to the server.

The initial calling request is used for obtaining a second interface white list from the server, so that the client can conveniently perform request detection based on the second interface white list when a subsequent calling service of the webpage calls the service calling interface with a third permission level based on the second interface white list. In addition, in this embodiment, the preset call interface is set in advance when a web page is developed, and in some embodiments, the permission level corresponding to the preset call interface may be a first permission level or a second permission level. In some implementation scenarios, the preset calling interface may be a first permission level, and under the condition that the preset calling interface is the first permission level, the client may generally directly set the initial calling request to a verification passing state based on the initial calling request, so as to conveniently and timely respond to the request, conveniently obtain a second interface white list requested from the server, and improve the loading speed of the web page.

S302, based on the initial call request, sending an interface list obtaining request for the second interface white list to the server, where the second interface white list includes at least one call interface of the third permission level.

The interface list acquisition request is used for requesting the server to issue a second interface white list for requesting verification; after the client side obtains the initial calling request of the webpage, the client side responds to the initial calling request, then an interface list obtaining request can be generated, and then the client side sends the interface list obtaining request to the server side.

In some embodiments, the client and the server may have an identity authentication mechanism for issuing the second interface white list, and it can be understood that the client may receive the second interface white list issued by the server only after the identity authentication is passed, otherwise, the server may not issue the second interface white list to the client when the identity authentication is failed.

Specifically, in an initial call request on a web page acquired by a client, the initial call request carries a key string (e.g., secret key), the key string is usually acquired from a server during web page development and loading, and can also be understood as a key verification rule agreed with the server during web page development, so that the key string exists in source data corresponding to the web page, and when the web page is initialized, the initial call request can be generated based on the key string, the client can acquire a second interface white list conveniently, and a subsequent service call request can be subjected to request verification based on the second interface white list conveniently.

Further, when the initial calling request is generated by initial loading of the web page, the initial calling request also carries the service type corresponding to the web page, it can be understood that the types of the second interface white lists corresponding to different web pages are not consistent, the initial calling request can be generated on the web page side based on the key string and the service type corresponding to the web page, on one hand, the key string is used for identity authentication of a subsequent server to issue the second interface white list, and on the other hand, the service type is used for accurately issuing the second interface white list corresponding to the service type when the server stores the interface white lists corresponding to the web pages of various service types.

In specific implementation, a client acquires an initial calling request of a webpage for a preset calling interface, acquires a key string and a service type carried by the initial calling request, and then generates an interface list acquisition request based on the key string and the service type. The method comprises the steps of sending an interface list acquisition request to a server, receiving the interface list acquisition request by the server, firstly performing identity authentication based on a key string in the interface list acquisition request, setting the state of the key string to be a key string verification pass after the identity authentication passes, and then searching a second interface white list corresponding to a service type in a local storage based on the service type in the interface list acquisition request, wherein the second interface white list further comprises at least one calling interface of a third authority level, and in addition, the calling interface can correspond to the interface attribute (such as interface identification, authority limit and the like) of the calling interface in the second interface white list.

S303, receiving the second interface white list sent by the server.

Specifically, after receiving a second interface white list sent by the server, the client stores the second interface white list to the local so as to facilitate request verification of a service call request corresponding to a subsequent webpage.

In the embodiment of the application, a client acquires a service calling request corresponding to a webpage, determines a service calling interface corresponding to the service calling request, determines a target permission level corresponding to the service calling interface, and verifies the service calling request by adopting a target verification mode corresponding to the target permission level. The target permission level corresponding to the service calling interface to be called is determined according to the service calling request of the webpage, and the service calling request is verified according to the verification mode corresponding to the target permission level, so that the safety risk occurring when the webpage directly calls the interface provided by the client in the related technology can be reduced, the permission level based on the service calling interface is verified by adopting the corresponding verification mode, different permission levels can use different safer verification modes, the safety of service calling verification is improved, and the safety risk in the service calling process corresponding to the interface is reduced. And aiming at different authority levels, a corresponding verification mode is adopted, further improvement of the service calling verification process is realized based on multiple dimensions such as the authority period, the interface white list, the interface authority level and the like in the verification process, verification is carried out in a finer-grained verification mode aiming at various possible safety risk conditions, and the service calling verification effect is improved.

Referring to fig. 6, fig. 6 is a schematic flowchart illustrating another embodiment of a service call checking method according to the present application. Specifically, the method comprises the following steps:

step S401: and acquiring a service calling request corresponding to the webpage.

Specifically, refer to step S101, which is not described herein again.

Step S402: and determining a service calling interface corresponding to the service calling request, and determining a target permission level corresponding to the service calling interface.

Specifically, refer to steps S101-S102, which are not described herein.

Step S403: and verifying the service calling request by adopting a target verification mode corresponding to the target authority level.

Specifically, refer to step S103, which is not described herein again.

Step S404: and determining that the webpage contains a floating page, and monitoring interface calling of the floating page.

In some implementation scenarios, when a browser on a client accesses a web page based on a domain name of the web page, and a web page process loads the web page, there may be a case where a floating page is generated to be overlaid on a page element (such as an input control) of the web page, and a process of loading the overlay of the floating page is also implemented based on a network domain name corresponding to the floating page. In practical applications, for example, the main page domain name of the current web page is www.AAA.com, it is assumed that the main page domain name performs steps S401 to S403 in this embodiment, it is determined that the calling interface has a right to access, but a floating page (iframe page), such as a popup, an advertisement page, etc., may be embedded in the current web page, and the web page domain name in the iframe page may be www.BBB.com. If the call request initiated by the floating page of the webpage aims at a call interface corresponding to the conditions related to user privacy, security risks and the like, great potential safety hazards exist.

In this embodiment, when the client obtains the service invocation request of the web page, in the process of verifying the service invocation request, the client may detect the web page accordingly to determine whether the web page has a floating page, and if the floating page exists, perform request invocation monitoring on the floating page corresponding to the web page.

The detection process of the floating page of the web page may be to detect a source file (such as a web page configuration file, a script, a web page loading code) corresponding to the web page, and in practical application, may be to perform traversal detection based on a feature character corresponding to the floating page, and if the feature character exists, it may be determined that the floating page exists in the web page, and then the floating page of the web page is monitored, for example, the processes of calling a web page process resource, loading a web page element, compiling a web page source file, and the like are monitored.

In a possible implementation manner, the detection process for the web page may be that the client provides a specific interface when providing the interface for calling the floating page of the web page through the system kernel, the web page (which may be understood as the floating page of the web page) at the front end can only send a call request through the specific interface (that is, the reference call interface described below) when calling the interface, and the client only needs to monitor the specific interface for the request call.

Step S405: and if a target calling request of the floating page is received, checking the target calling request.

Specifically, in the process of performing relevant monitoring on the floating page of the webpage, if it is monitored that the webpage currently initiates a call request, the call request is actually initiated by the floating page, at this time, it is determined that the target call request of the floating page is received, then the target call request is verified, and after the target call request is verified, the floating page of the webpage is allowed to perform interface call.

Further, taking the above-mentioned "the front-end webpage (which may be understood as a floating page of the webpage) can only send a call request through a reference call interface when the call interface (which may be understood as a reference call interface in some embodiments) is called," if a target call request initiated by the floating page for the reference call interface is received, a feasible manner may be:

the client may use the reference call interface as the service call interface, use the target call request as the service call request, and perform the step of determining the target permission level corresponding to the service call interface, that is, perform step S402 to step S403, or perform step S202 to step S205.

Alternatively, one possible way may be:

the client acquires the domain name information carried by the target calling request and determines that a domain name value exists in the domain name information;

the domain name information includes domain name data associated with the web page, such as a facility name, a network name, a layer domain name. The domain name value can be understood as a domain name address where domain name data can be accessed, and if the domain name data has the domain name address and the network domain name can be accessed, the domain name value in the domain name information is determined;

and then, the client detects whether the reference calling interface exists in a white list of a third interface, and sets the target calling request to be in a verification passing state according to a detection result.

And the white list is issued by the third interface white name unit server and used for carrying out interface verification on the floating page of the webpage. In addition, a plurality of reference calling interfaces can be arranged, and each reference calling interface can correspond to different types of interfaces.

And when detecting that the reference calling interface exists in the white list of the third interface, the client sets the target calling request to be in a verification passing state.

The following are embodiments of the apparatus of the present application that may be used to perform embodiments of the method of the present application. For details which are not disclosed in the embodiments of the apparatus of the present application, reference is made to the embodiments of the method of the present application.

Referring to fig. 7, a schematic structural diagram of a service call checking apparatus according to an exemplary embodiment of the present application is shown. The service call checking means may be implemented as all or part of the apparatus in software, hardware or a combination of both. The device 1 comprises a call request acquisition module 11, a permission level determination module 12 and a call request verification module 13.

The calling request acquiring module 11 is configured to acquire a service calling request corresponding to a web page and determine a service calling interface corresponding to the service calling request;

the permission level determining module 12 is configured to determine a target permission level corresponding to the service invocation interface;

and the call request checking module 13 is configured to check the service call request by using a target checking manner corresponding to the target permission level.

Optionally, the invocation request obtaining module 11 is specifically configured to:

and acquiring service calling information carried by the service calling request, and determining a service calling interface corresponding to the service calling information.

Optionally, the permission level determining module 12 includes:

and determining a target permission level corresponding to the service calling interface in a preset interface permission level set, wherein the interface permission level set comprises permission levels corresponding to at least one calling interface.

Optionally, the invoking request checking module 13 includes:

a first checking unit 131, configured to, if the target permission level is a first permission level, check the service invocation request by using a first checking manner corresponding to the first permission level;

a second checking unit 132, configured to, if the target permission level is a second permission level, check the service invocation request by using a second checking manner corresponding to the second permission level;

a third checking unit 133, configured to, if the target permission level is a third permission level, check the service invocation request by using a third checking manner corresponding to the third permission level, where the second permission level is greater than the first permission level and is less than the third permission level.

Optionally, the first checking unit 131 is specifically configured to:

and setting the service calling request to be in a verification passing state.

Optionally, the second checking unit 132 is specifically configured to:

and acquiring an attribute tag carried by the service calling request, and checking the service calling request based on the attribute tag.

Alternatively, as shown in fig. 8, the first checking unit 132 includes:

a parameter determining subunit 1321, configured to determine whether an attribute parameter exists in the attribute tag;

a verification determining subunit 1322, configured to determine, if the attribute parameter exists in the attribute tag, an interface verification state based on an authority limit in the attribute parameter, perform signature verification on the service invocation request based on the interface verification state, and determine that the service invocation request passes verification based on a verification result of the signature verification;

the check determining subunit 1322 is further configured to, if the attribute parameter does not exist in the attribute tag, obtain the permission limit of the service invocation interface in the interface white list when the service invocation interface is determined to exist in a pre-stored first interface white list, and determine that the service invocation request passes the check.

Optionally, the verification determining subunit 1322 is specifically configured to:

if the interface verification state is an unexpired state, acquiring a signature parameter in the attribute parameters;

and determining the signature verification state of the service calling request based on the attribute tag and the signature parameter, and determining that the service calling request passes the verification based on the signature verification state.

Optionally, as shown in fig. 9, the third checking unit 133 includes:

a deadline information obtaining subunit 1331, configured to obtain locally stored deadline information corresponding to the service invocation interface, and determine an interface verification state corresponding to the service invocation interface based on the deadline information;

a request checking subunit 1332, configured to determine that the service call request is checked to be passed when it is determined that the service call interface exists in a pre-stored second interface white list if the interface checking state is the unexpired state, where the second interface white list is sent by the server when the web page is initialized.

Optionally, the apparatus 1 is further configured to:

when the webpage is initialized, acquiring an initial calling request of the webpage for a preset calling interface;

sending an interface list acquisition request aiming at the second interface white list to the server side based on the initial calling request, wherein the second interface white list comprises at least one calling interface with the third permission level;

and receiving the second interface white list sent by the server.

Optionally, the apparatus 1 is further configured to:

acquiring a key string carried by the initial calling request and a service type corresponding to the webpage, and generating an interface list acquisition request aiming at the second interface white list based on the key string and the service type;

and sending the interface list acquisition request to the server, wherein the interface list acquisition request is used for indicating the server to send the second interface white list corresponding to the service type to the client after the verification of the server based on the key string is passed.

Optionally, the apparatus 1 is further configured to:

determining that the webpage contains a floating page, and monitoring interface calling of the floating page;

and if the floating page is monitored to aim at a target calling request of a preset reference calling interface, checking the target calling request.

Optionally, the apparatus 1 is further configured to:

and taking the reference calling interface as the service calling interface, taking the target calling request as the service calling request, and executing the step of determining the target permission level corresponding to the service calling interface.

Optionally, the apparatus 1 is further configured to:

acquiring domain name information carried by the target calling request, and determining that a domain name value exists in the domain name information;

and detecting whether the reference calling interface exists in a white list of a third interface, and setting the target calling request to be in a verification passing state according to a detection result.

It should be noted that, when the service call checking apparatus provided in the foregoing embodiment executes the service call checking method, only the division of the functional modules is illustrated, and in practical applications, the function distribution may be completed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules, so as to complete all or part of the functions described above. In addition, the service invocation checking device and the service invocation checking method provided by the above embodiments belong to the same concept, and the details of the implementation process are referred to as method embodiments, which are not described herein again.

The above-mentioned serial numbers of the embodiments of the present application are merely for description and do not represent the merits of the embodiments.

An embodiment of the present application further provides a computer storage medium, where the computer storage medium may store a plurality of instructions, where the instructions are suitable for being loaded by a processor and executing the service call checking method according to the embodiments shown in fig. 1 to 6, and a specific execution process may refer to specific descriptions of the embodiments shown in fig. 1 to 6, which is not described herein again.

The present application further provides a computer program product, where at least one instruction is stored in the computer program product, where the at least one instruction is loaded by the processor and executes the service call checking method according to the embodiment shown in fig. 1 to 6, and a specific execution process may refer to specific descriptions of the embodiment shown in fig. 1 to 6, which is not described herein again.

Referring to fig. 10, a block diagram of an electronic device according to an exemplary embodiment of the present application is shown. The electronic device in the present application may comprise one or more of the following components: a processor 110, a memory 120, an input device 130, an output device 140, and a bus 150. The processor 110, memory 120, input device 130, and output device 140 may be connected by a bus 150.

Processor 110 may include one or more processing cores. The processor 110 connects various parts within the overall electronic device using various interfaces and lines, and performs various functions of the electronic device 100 and processes data by executing or executing instructions, programs, code sets, or instruction sets stored in the memory 120 and calling data stored in the memory 120. Alternatively, the processor 110 may be implemented in hardware using at least one of Digital Signal Processing (DSP), field-programmable gate Array (FPGA), and Programmable Logic Array (PLA). The processor 110 may integrate one or more of a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), a modem, and the like. Wherein, the CPU mainly processes an operating system, a user interface, an application program and the like; the GPU is used for rendering and drawing display content; the modem is used to handle wireless communications. It is understood that the modem may not be integrated into the processor 110, but may be implemented by a communication chip.

The Memory 120 may include a Random Access Memory (RAM) or a read-only Memory (ROM). Optionally, the memory 120 includes a non-transitory computer-readable medium. The memory 120 may be used to store instructions, programs, code sets, or instruction sets. The memory 120 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for implementing at least one function (such as a touch function, a sound playing function, an image playing function, etc.), instructions for implementing various method embodiments described below, and the like, and the operating system may be an Android (Android) system, including a system based on Android system depth development, an IOS system developed by apple, including a system based on IOS system depth development, or other systems. The data storage area may also store data created by the electronic device during use, such as phone books, audio and video data, chat log data, and the like.

Referring to fig. 11, the memory 120 may be divided into an operating system space, in which an operating system runs, and a user space, in which native and third-party applications run. In order to ensure that different third-party application programs can achieve a better operation effect, the operating system allocates corresponding system resources for the different third-party application programs. However, the requirements of different application scenarios in the same third-party application program on system resources are different, for example, in a local resource loading scenario, the third-party application program has a higher requirement on the disk reading speed; in the animation rendering scene, the third-party application program has a high requirement on the performance of the GPU. The operating system and the third-party application program are independent from each other, and the operating system cannot sense the current application scene of the third-party application program in time, so that the operating system cannot perform targeted system resource adaptation according to the specific application scene of the third-party application program.

In order to enable the operating system to distinguish a specific application scenario of the third-party application program, data communication between the third-party application program and the operating system needs to be opened, so that the operating system can acquire current scenario information of the third-party application program at any time, and further perform targeted system resource adaptation based on the current scenario.

Taking an operating system as an Android system as an example, programs and data stored in the memory 120 are as shown in fig. 12, and a Linux kernel layer 320, a system runtime library layer 340, an application framework layer 360, and an application layer 380 may be stored in the memory 120, where the Linux kernel layer 320, the system runtime library layer 340, and the application framework layer 360 belong to an operating system space, and the application layer 380 belongs to a user space. The Linux kernel layer 320 provides underlying drivers for various hardware of the electronic device, such as a display driver, an audio driver, a camera driver, a bluetooth driver, a Wi-Fi driver, power management, and the like. The system runtime library layer 340 provides a main feature support for the Android system through some C/C + + libraries. For example, the SQLite library provides support for a database, the OpenGL/ES library provides support for 3D drawing, the Webkit library provides support for a browser kernel, and the like. Also provided in the system runtime library layer 340 is an Android runtime library (Android runtime), which mainly provides some core libraries that can allow developers to write Android applications using the Java language. The application framework layer 360 provides various APIs that may be used in building an application, and developers may build their own applications by using these APIs, such as activity management, window management, view management, notification management, content provider, package management, session management, resource management, and location management. At least one application program runs in the application layer 380, and the application programs may be native application programs carried by the operating system, such as a contact program, a short message program, a clock program, a camera application, and the like; or a third-party application developed by a third-party developer, such as a game application, an instant messaging program, a photo beautification program, a service call verification program, and the like.

Taking an operating system as an IOS system as an example, programs and data stored in the memory 120 are shown in fig. 13, and the IOS system includes: a Core operating system Layer 420(Core OS Layer), a Core Services Layer 440(Core Services Layer), a Media Layer 460(Media Layer), and a touchable Layer 480(Cocoa Touch Layer). The kernel operating system layer 420 includes an operating system kernel, drivers, and underlying program frameworks that provide functionality closer to hardware for use by program frameworks located in the core services layer 440. The core services layer 440 provides system services and/or program frameworks, such as a Foundation framework, an account framework, an advertisement framework, a data storage framework, a network connection framework, a geographic location framework, a motion framework, and so forth, as required by the application. The media layer 460 provides audiovisual related interfaces for applications, such as graphics image related interfaces, audio technology related interfaces, video technology related interfaces, audio video transmission technology wireless playback (AirPlay) interfaces, and the like. Touchable layer 480 provides various common interface-related frameworks for application development, and touchable layer 480 is responsible for user touch interaction operations on the electronic device. Such as a local notification service, a remote push service, an advertising framework, a game tool framework, a messaging User Interface (UI) framework, a User Interface UIKit framework, a map framework, and so forth.

In the framework illustrated in FIG. 13, the framework associated with most applications includes, but is not limited to: a base framework in the core services layer 440 and a UIKit framework in the touchable layer 480. The base framework provides many basic object classes and data types, provides the most basic system services for all applications, and is UI independent. While the class provided by the UIKit framework is a basic library of UI classes for creating touch-based user interfaces, iOS applications can provide UIs based on the UIKit framework, so it provides an infrastructure for applications for building user interfaces, drawing, processing and user interaction events, responding to gestures, and the like.

The Android system can be referred to as a mode and a principle for realizing data communication between the third-party application program and the operating system in the IOS system, and details are not repeated herein.

The input device 130 is used for receiving input instructions or data, and the input device 130 includes, but is not limited to, a keyboard, a mouse, a camera, a microphone, or a touch device. The output device 140 is used for outputting instructions or data, and the output device 140 includes, but is not limited to, a display device, a speaker, and the like. In one example, the input device 130 and the output device 140 may be combined, and the input device 130 and the output device 140 are touch display screens for receiving touch operations of a user on or near the touch display screens by using any suitable object such as a finger, a touch pen, and the like, and displaying user interfaces of various applications. Touch displays are typically provided on the front panel of an electronic device. The touch display screen may be designed as a full-face screen, a curved screen, or a profiled screen. The touch display screen can also be designed to be a combination of a full-face screen and a curved-face screen, and a combination of a special-shaped screen and a curved-face screen, which is not limited in the embodiment of the present application.

In addition, those skilled in the art will appreciate that the configurations of the electronic devices illustrated in the above-described figures do not constitute limitations on the electronic devices, which may include more or fewer components than illustrated, or some components may be combined, or a different arrangement of components. For example, the electronic device further includes a radio frequency circuit, an input unit, a sensor, an audio circuit, a wireless fidelity (WiFi) module, a power supply, a bluetooth module, and other components, which are not described herein again.

In the embodiment of the present application, the main body of execution of each step may be the electronic device described above. Optionally, the execution subject of each step is an operating system of the electronic device. The operating system may be an android system, an IOS system, or another operating system, which is not limited in this embodiment of the present application.

The electronic device of the embodiment of the application can also be provided with a display device, and the display device can be various devices capable of realizing a display function, for example: a cathode ray tube display (CR), a light-emitting diode display (LED), an electronic ink panel, a Liquid Crystal Display (LCD), a Plasma Display Panel (PDP), and the like. A user may utilize a display device on the electronic device 101 to view information such as displayed text, images, video, and the like. The electronic device may be a smartphone, a tablet computer, a gaming device, an AR (Augmented Reality) device, an automobile, a data storage device, an audio playback device, a video playback device, a notebook, a desktop computing device, a wearable device such as an electronic watch, an electronic glasses, an electronic helmet, an electronic bracelet, an electronic necklace, an electronic garment, or the like.

In the electronic device shown in fig. 10, where the electronic device may be a terminal, the processor 110 may be configured to call the service call checking application stored in the memory 120, and specifically perform the following operations:

In an embodiment, when the processor 110 executes the service invocation interface corresponding to the service invocation request, the following operations are specifically executed:

In an embodiment, when the processor 110 determines, in the preset clusters of different types of processors, a target type of processor cluster corresponding to the thread identifier, the following operation is specifically performed:

In an embodiment, when the processor 110 performs the target verification method corresponding to the target permission level to verify the service invocation request, the following operations are specifically performed:

if the target permission level is a first permission level, verifying the service calling request by adopting a first verification mode corresponding to the first permission level;

if the target permission level is a second permission level, verifying the service calling request by adopting a second verification mode corresponding to the second permission level;

and if the target permission level is a third permission level, verifying the service calling request by adopting a third verification mode corresponding to the third permission level, wherein the second permission level is greater than the first permission level and less than the third permission level.

In an embodiment, when the processor 110 performs the verification on the service invocation request by using the first verification manner corresponding to the first permission level, the following operations are specifically performed:

and setting the service calling request to be in a verification passing state.

In an embodiment, when the processor 110 performs the verification on the service invocation request by using the second verification manner corresponding to the second permission level, the following operations are specifically performed:

In an embodiment, when the processor 110 performs the verification of the service invocation request based on the attribute tag, the following steps are specifically performed:

judging whether the attribute label has attribute parameters;

if the attribute parameters exist in the attribute tag, determining an interface verification state based on the authority limit in the attribute parameters, performing signature verification on the service calling request based on the interface verification state, and determining that the service calling request passes the verification based on the verification result of the signature verification;

if the attribute parameters do not exist in the attribute tag, when the service calling interface is determined to exist in a pre-stored first interface white list, acquiring the authority limit of the service calling interface in the interface white list, and determining that the service calling request passes the verification.

In an embodiment, when performing the signature verification on the service invocation request based on the interface verification state and determining that the service invocation request verification passes based on a verification result of the signature verification, the processor 110 specifically performs the following steps:

In an embodiment, when the processor 110 performs the verification on the service invocation request by using a third verification manner corresponding to a third permission level if the target permission level is the third permission level, the following steps are specifically performed:

acquiring locally stored time limit information corresponding to the service calling interface, and determining an interface verification state corresponding to the service calling interface based on the time limit information;

and if the interface verification state is the unexpired state, when the service calling interface is determined to exist in a pre-stored second interface white list, determining that the service calling request verification is passed, wherein the second interface white list is sent by the server side when the webpage is initialized.

In one embodiment, the processor 110, when executing the service call checking method, further performs the following steps:

and receiving the second interface white list sent by the server.

In one embodiment, the processor 110, in executing sending, to the server, an interface list acquisition request for the second interface white list based on the initial invocation request, further performs the following steps:

In an embodiment, when the processor 110 performs the verification on the target call request, the following steps are specifically performed:

It is clear to a person skilled in the art that the solution of the present application can be implemented by means of software and/or hardware. The "unit" and "module" in this specification refer to software and/or hardware that can perform a specific function independently or in cooperation with other components, where the hardware may be, for example, a Field-ProgrammaBLE Gate Array (FPGA), an Integrated Circuit (IC), or the like.

It should be noted that, for simplicity of description, the above-mentioned method embodiments are described as a series of acts or combination of acts, but those skilled in the art will recognize that the present application is not limited by the order of acts described, as some steps may occur in other orders or concurrently depending on the application. Further, those skilled in the art should also appreciate that the embodiments described in the specification are preferred embodiments and that the acts and modules referred to are not necessarily required in this application.

In the foregoing embodiments, the descriptions of the respective embodiments have respective emphasis, and for parts that are not described in detail in a certain embodiment, reference may be made to related descriptions of other embodiments.

In the embodiments provided in the present application, it should be understood that the disclosed apparatus may be implemented in other manners. For example, the above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one type of division of logical functions, and there may be other divisions when actually implementing, for example, a plurality of units or components may be combined or may be integrated into another system, or some features may be omitted, or not implemented. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection of some service interfaces, devices or units, and may be an electrical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable memory. Based on such understanding, the technical solution of the present application may be substantially implemented or a part of or all or part of the technical solution contributing to the prior art may be embodied in the form of a software product stored in a memory, and including several instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method described in the embodiments of the present application. And the aforementioned memory comprises: various media capable of storing program codes, such as a usb disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a removable hard disk, a magnetic disk, or an optical disk.

Those skilled in the art will appreciate that all or part of the steps in the methods of the above embodiments may be implemented by a program, which is stored in a computer-readable memory, and the memory may include: flash disks, Read-Only memories (ROMs), Random Access Memories (RAMs), magnetic or optical disks, and the like.

The above description is only an exemplary embodiment of the present disclosure, and the scope of the present disclosure should not be limited thereby. That is, all equivalent changes and modifications made in accordance with the teachings of the present disclosure are intended to be included within the scope of the present disclosure. Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure herein. This application is intended to cover any variations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

Claims

1. A service call checking method is applied to a client, and comprises the following steps:

2. The method of claim 1, wherein the determining the service invocation interface corresponding to the service invocation request comprises:

3. The method of claim 1, wherein the determining the target permission level corresponding to the service invocation interface comprises:

4. The method of claim 1, wherein the verifying the service invocation request in a target verification manner corresponding to the target permission level comprises:

5. The method of claim 4, wherein the verifying the service invocation request in a first verification manner corresponding to the first permission level comprises:

and setting the service calling request to be in a verification passing state.

6. The method according to claim 4, wherein the verifying the service invocation request by using the second verification manner corresponding to the second permission level comprises:

7. The method of claim 6, wherein the verifying the service invocation request based on the attribute tag comprises:

judging whether the attribute label has attribute parameters;

8. The method of claim 7, wherein the signature checking the service invocation request based on the interface checking state, and determining that the service invocation request is checked to pass based on a checking result of the signature checking, comprises:

9. The method of claim 4, wherein if the target permission level is a third permission level, checking the service invocation request by using a third checking manner corresponding to the third permission level comprises:

10. The method of claim 9, further comprising:

and receiving the second interface white list sent by the server.

11. The method of claim 10, wherein sending an interface list acquisition request for the second interface white list to the server based on the initial invocation request comprises:

12. The method of claim 1, further comprising:

13. The method of claim 12, wherein said verifying said target invocation request comprises:

14. The method of claim 12, wherein said verifying said target invocation request comprises:

15. A computer storage medium, characterized in that it stores a plurality of instructions adapted to be loaded by a processor and to carry out the method steps according to any one of claims 1 to 14.

16. An electronic device, comprising: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to perform the method steps of any of claims 1 to 14.