CN113486344B

CN113486344B - Interface anti-brushing method and device, server side and storage medium

Info

Publication number: CN113486344B
Application number: CN202110797062.XA
Authority: CN
Inventors: 刘文才
Original assignee: Beijing QIYI Century Science and Technology Co Ltd
Current assignee: Beijing QIYI Century Science and Technology Co Ltd
Priority date: 2021-07-14
Filing date: 2021-07-14
Publication date: 2023-09-05
Anticipated expiration: 2041-07-14
Also published as: CN113486344A

Abstract

The embodiment of the application provides an interface anti-brushing method, an interface anti-brushing device, a server side and a storage medium. The scheme is as follows: receiving an interface request sent by a user through a client, wherein the interface request comprises a target interface requested by the client; based on the interface request, acquiring user information of a user and/or equipment information of a client as target information; acquiring a shielding list and a shielding to-be-selected list at the current moment, wherein the shielding list is a subset of the shielding to-be-selected list; responding to the interface request when the target information is not included in the shielding list; and when the shielding candidate list and the shielding list both comprise target information, shielding the interface request. By adopting the technical scheme provided by the embodiment of the application, the adaptability of the interface anti-brushing method in different scenes is improved, the accuracy of shielding the interface request is improved, and the probability of occurrence of the error shielding phenomenon is reduced.

Description

Interface anti-brushing method and device, server side and storage medium

Technical Field

The present application relates to the field of internet technologies, and in particular, to an interface anti-brushing method, an apparatus, a server side, and a storage medium.

Background

In the server side, the client-oriented interface is at risk of being brushed. For example, an abnormal client or user may dislike sending a large number of interface requests to a certain interface of the server, which may seriously affect the response of the server to the normal interface requests, especially when the number of times a certain interface is momentarily flushed is excessive, which may cause the server to be knocked down.

Currently, the interface may be prevented from being brushed in the following manner. In one mode, the number of times of calling the interface in unit time by the user or the device is limited, namely, when the number of times of calling the interface in unit time by the user or the device exceeds the preset number of times, the interface request sent by the user or the device is directly shielded. In the second mode, the user or the device is authenticated by means of authentication, for example, an authentication code is sent, so that an interface request sent by the user or the device which does not pass authentication is shielded.

The interface brushing prevention method in the first mode is rough, and can easily cause the interface request sent by a normal user or normal equipment to be shielded, so that the phenomenon of error shielding occurs. The interface anti-brushing method in the second mode needs the user to manually complete the verification process, so that the user experience is seriously affected, and the method is not suitable for most application scenes.

Disclosure of Invention

The embodiment of the application aims to provide an interface anti-brushing method, an interface anti-brushing device, a server side and a storage medium, which can improve the accuracy of shielding an interface request and reduce the probability of occurrence of a false shielding phenomenon while improving the adaptability of the interface anti-brushing method in different scenes. The specific technical scheme is as follows:

in a first aspect of the present application, there is first provided an interface anti-brushing method, applied to a server, where the method includes:

receiving an interface request sent by a user through a client, wherein the interface request comprises a target interface requested by the client;

based on the interface request, acquiring user information of the user and/or equipment information of the client as target information;

acquiring a shielding list and a shielding candidate list at the current moment, wherein the shielding list is a subset of the shielding candidate list;

responding to the interface request when the target information is not included in the mask list;

when the shielding candidate list and the shielding list both comprise the target information, shielding the interface request;

the method comprises the steps that target information in a shielding candidate list is updated to the shielding candidate list when the number of times of requests of a user or a client to the target interface is matched with a first anti-brushing strategy, and the target information in the shielding list is updated to the shielding list when user behavior data of the user is matched with a second anti-brushing strategy.

Optionally, the method further comprises:

if the target information is not included in the shielding candidate list, counting a first frequency of receiving an interface request associated with the target information in a first time period before the current moment;

when the first frequency is greater than or equal to the second frequency, updating the target information to the shielding candidate list; and the second frequency is the frequency corresponding to the target interface and the target information in the first anti-brushing strategy.

Optionally, the method further comprises:

if the shielding candidate list comprises the target information, but the shielding list does not comprise the target information, acquiring first user behavior data in a second time period before the current time of the user;

updating the target information to the mask list when the first user behavior data matches the second user behavior data; and the second user behavior data are user behavior data corresponding to the target interface and the target information in the second anti-brushing strategy.

Optionally, the user behavior data includes a behavior category;

the step of obtaining the first user behavior data in the second time before the current time comprises the following steps:

Acquiring a second anti-brushing strategy comprising the target interface;

according to each behavior category included in the third user behavior data in the acquired second anti-brushing strategy, sending a data acquisition request comprising a feedback address to the client; after receiving the data acquisition request, the client acquires first user behavior data corresponding to the behavior of the user for executing each behavior category in a second time before the current time, and stores the first user behavior data to the feedback address;

and reading the first user behavior data from the feedback address.

Optionally, the user behavior data includes behavior categories and behavior values corresponding to each behavior category;

after the first user behavior data of the user in the second time before the current time is acquired, the method further comprises the following steps:

comparing a behavior value corresponding to the behavior category in the first user behavior data with a behavior value corresponding to the behavior category in the second user behavior data aiming at each behavior category in a second anti-brushing strategy comprising the target interface to obtain a first comparison result;

the step of updating the target information to the mask list when the first user behavior data matches the second user behavior data includes:

And when any one of the first comparison results indicates that the behavior numerical value included in the first user behavior data is greater than or equal to the behavior numerical value included in the second user behavior data, updating the target information to the shielding list.

Optionally, after obtaining user information of the user and/or device information of the client based on the interface request, the method further includes:

according to the received interface request, the number of requests corresponding to the target information stored in a preset remote dictionary service (Remote Dictionary Server, redis) is updated.

Optionally, the effective duration of the request times corresponding to the target information stored in the preset Redis is a first duration.

In a second aspect of the present application, there is also provided an interface anti-brushing device, applied to a server, the device including:

the receiving module is used for receiving an interface request sent by a user through a client, wherein the interface request comprises a target interface requested by the client;

the first acquisition module is used for acquiring user information of the user and/or equipment information of the client based on the interface request, and taking the user information and/or the equipment information of the client as target information;

The second acquisition module is used for acquiring a shielding list and a shielding to-be-selected list at the current moment, wherein the shielding list is a subset of the shielding to-be-selected list;

the response module is used for responding to the interface request when the target information is not included in the shielding list;

the shielding module is used for shielding the interface request when the shielding candidate list and the shielding list both comprise the target information;

Optionally, the apparatus further includes:

the statistics module is used for counting a first frequency of receiving interface requests associated with the target information in a first time period before the current moment if the target information is not included in the shielding candidate list;

the first updating module is used for updating the target information to the shielding candidate list when the first frequency is greater than or equal to the second frequency; and the second frequency is the frequency corresponding to the target interface and the target information in the first anti-brushing strategy.

Optionally, the apparatus further includes:

a third obtaining module, configured to obtain first user behavior data in a second duration before the current time of the user if the shielding candidate list includes the target information but the shielding list does not include the target information;

a second updating module, configured to update the target information to the mask list when the first user behavior data matches with second user behavior data; and the second user behavior data are user behavior data corresponding to the target interface and the target information in the second anti-brushing strategy.

Optionally, the user behavior data includes a behavior category;

the third acquisition module includes:

an acquisition sub-module for acquiring a second anti-brushing policy comprising the target interface;

a sending sub-module, configured to send a data acquisition request including a feedback address to the client according to each behavior category included in the third user behavior data in the acquired second anti-brushing policy; after receiving the data acquisition request, the client acquires first user behavior data corresponding to the behavior of the user for executing each behavior category in a second time before the current time, and stores the first user behavior data to the feedback address;

And the reading sub-module is used for reading the first user behavior data from the feedback address.

the apparatus further comprises:

the comparison module is used for comparing a behavior numerical value corresponding to the behavior category in the first user behavior data with a behavior numerical value corresponding to the behavior category in the second user behavior data for each behavior category in a second anti-brushing strategy comprising the target interface after the first user behavior data in a second time before the current time is acquired, so as to obtain a first comparison result;

the second updating module is specifically configured to update the target information to the mask list when any one of the first comparison results indicates that the behavior numerical value included in the first user behavior data is greater than or equal to the behavior numerical value included in the second user behavior data.

Optionally, the apparatus further includes:

and the third updating module is used for updating the request times corresponding to the target information stored in the preset Redis according to the received interface request after acquiring the user information of the user and/or the equipment information of the client based on the interface request as the target information.

In a third aspect of the present application, there is also provided a server, including a processor, a communication interface, a memory, and a communication bus, where the processor, the communication interface, and the memory complete communication with each other through the communication bus;

a memory for storing a computer program;

and the processor is used for realizing any one of the interface anti-brushing method steps when executing the program stored in the memory.

In a fourth aspect of the present application, there is also provided a computer readable storage medium having a computer program stored therein, the computer program when executed by a processor implementing any of the interface anti-brush methods described above.

In a fifth aspect of the application, there is also provided a computer program product containing instructions which, when run on a computer, cause the computer to perform any of the interface anti-brush methods described above.

According to the interface anti-brushing method, the device, the server and the storage medium, after receiving the interface request sent by the user through the client, the interface request is responded or shielded according to whether the shielding list and the shielding list comprise target information corresponding to the interface request. That is, when the target information is not included in the mask list, responding to the interface request; and when the shielding candidate list and the shielding list both comprise target information, shielding the interface request.

Compared with the related art, the method and the device have the advantages that the interface request is directly shielded through shielding the target information corresponding to the candidate list, the shielding list and the interface request, the process that a user needs to manually verify in the related art is avoided, and the interface anti-brushing process is simplified.

Furthermore, the information in the shielding candidate list is updated according to the number of requests of the user or the client to the interface and the first anti-brushing strategy; the information in the mask list is updated based on user behavior data of the user and the second anti-swipe policy. By timely updating the information in the shielding list to be selected and the shielding list, the accuracy of the shielding list to be selected and the shielding list can be effectively ensured, so that the accuracy of shielding the received interface request based on the shielding list and the shielding list to be selected is improved, namely the accuracy of shielding the interface request is improved, and the probability of error shielding is reduced.

In addition, through the multi-layer anti-brushing strategy, namely the setting of a first anti-brushing strategy related to the number of requests of a user or a client to an interface and a second anti-brushing strategy related to user behavior data of the user, the anti-brushing strategy can be adjusted according to different scenes, so that the interface anti-brushing method provided by the embodiment of the application can be suitable for different scenes, and the adaptability of the interface anti-brushing method in different scenes is improved.

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.

Fig. 1 is a schematic flow chart of a first method for preventing interface brushing according to an embodiment of the present application;

fig. 2 is a schematic structural diagram of a server provided in an embodiment of the present application;

FIG. 3 is a schematic diagram of a second flow chart of an interface anti-brushing method according to an embodiment of the present application;

fig. 4 is a third flow chart of an interface anti-brushing method according to an embodiment of the present application;

fig. 5 is a fourth flowchart of an interface anti-brushing method according to an embodiment of the present application;

fig. 6 is a fifth flowchart of an interface anti-brushing method according to an embodiment of the present application;

fig. 7 is a sixth flowchart of an interface anti-brushing method according to an embodiment of the present application;

FIG. 8 is a signaling diagram of an interface anti-brushing process according to an embodiment of the present application;

FIG. 9 is a schematic structural diagram of an interface anti-brushing device according to an embodiment of the present application;

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

Detailed Description

The technical solutions in the embodiments of the present application will be described below with reference to the accompanying drawings in the embodiments of the present application.

In order to solve the problems in the related art, the embodiment of the application provides an interface anti-brushing method. Fig. 1 is a schematic flow chart of a first method for preventing interface brushing according to an embodiment of the present application. The method is applied to the server and specifically comprises the following steps.

Step S101, receiving an interface request sent by a user through a client, wherein the interface request comprises a target interface requested by the client.

Step S102, based on the interface request, user information of the user and/or equipment information of the client side are obtained as target information.

Step S103, a shielding list and a shielding candidate list at the current moment are obtained, wherein the shielding list is a subset of the shielding candidate list.

Step S104, when the target information is not included in the mask list, responding to the interface request.

Step S105, when the masked candidate list and the masked list both include the target information, the interface request is masked.

In the embodiment of the present application, the target information in the mask candidate list is updated to the mask candidate list when the number of times of the request of the user or the client to the target interface matches with the first anti-brushing policy, and the target information in the mask list is updated to the mask list when the user behavior data of the user matches with the second anti-brushing policy. The updating manner of the mask candidate list and the mask list can be referred to in the following description, and is not described herein.

In the embodiment of the present application, as shown in fig. 2 for the above-mentioned service end, fig. 2 is a schematic structural diagram of the service end provided in the embodiment of the present application. The service end shown in fig. 2 includes an interface service module 201, a real-time calculation module 202 and a anti-brushing policy configuration module 203. The function of each module included in the server side is described below, and is not specifically described herein.

After receiving an interface request sent by a user through a client through the method shown in fig. 1, responding or shielding the interface request according to whether a shielding list and a shielding candidate list include target information corresponding to the interface request. That is, when the target information is not included in the mask list, responding to the interface request; and when the shielding candidate list and the shielding list both comprise target information, shielding the interface request.

The following describes embodiments of the present application by way of specific examples.

For the step S101, that is, receiving an interface request sent by the user through the client, the interface request includes the target interface requested by the client.

In this step, when the user performs a user behavior of a certain behavior class in the client, the client may be triggered to send an interface request for the user behavior to a certain service interface in the server. At this time, the service interface in the server receives the interface request.

In the embodiment of the present application, the service end includes a plurality of service ports, and each service port can provide a plurality of services for the client. The interface request sent by the user to the server through the client is triggered by the user according to the self requirement. The type of interface request triggered by the user varies according to the user's own needs. For example, the interface request may be a data acquisition request triggered by a user, or the interface request may be a login request triggered by a user, or the like. Here, the number of service ports and the type of the interface request included in the server are not particularly limited.

The interface request includes a target interface requested by the client. The target interface may be represented as a port number, domain name information, or interface address information carried in the interface request. The target interfaces included in the interface request are different depending on the type of interface request triggered by the user. Here, the representation of the target interface is not particularly limited.

For the above step S102, that is, based on the interface request, the user information of the user and/or the device information of the client is acquired as the target information.

In this step, after receiving the interface request, the server may obtain user information of the user according to the interface request, as the target information. The device information of the client may also be acquired as target information. User information of the user and device information of the client can also be obtained as target information.

The user information includes, but is not limited to, a user name, a nickname, and a User Identification (UID), and the device information includes, but is not limited to, a device Identification (ID) and an internet protocol (Internet Protocol, IP) address. Here, the user information and the device information are not particularly limited.

In an alternative embodiment, the server may directly obtain the target information from the interface request. For example, when the target information is the IP address of the client, the server may directly obtain the source IP address of the interface request as the target information.

In another alternative embodiment, the server may also request the target information from the client based on the interface request. For example, when the target information is the UID of the user, the server may request the UID of the user from the client according to the information such as the source IP address, the source port number, and the like in the interface request.

In the embodiment of the present application, the server may acquire the target information in different manners according to the information included in the target information. Here, the method of acquiring the target information is not particularly limited.

For convenience of description, the following description will take the target information as the UID as an example, and is not meant to be limiting.

For the step S103, that is, the mask list and the mask candidate list at the current time are obtained, the mask list is a subset of the mask candidate list.

In this step, the server stores a mask list and a mask candidate list. When the server obtains the target information, that is, after executing the step S102, the server may obtain the mask list and the mask candidate list stored in the server at the current time, that is, the mask list and the mask candidate list at the current time.

In the embodiment of the present application, the above-mentioned mask list is a subset of the mask candidate list. The concrete steps are as follows: the information in the masked list is necessarily in the masked candidate list, but the information in the masked list is not necessarily all the information in the masked candidate list. I.e. the masked list may include information not present in the masked list.

The above-mentioned mask list and mask candidate list may include user information of a plurality of users and device information of a plurality of clients.

In an optional embodiment, after obtaining the shielding candidate list and the shielding list, the server may determine whether the shielding candidate list includes the target information, and determine whether the shielding list includes the target information.

The above-described case may include the following three cases when judging whether the above-described target information is included in the mask list and the mask candidate list.

In the first case, the target information is not included in the mask candidate list.

In the embodiment of the present application, since the mask list is a subset of the mask candidate list, when the target information is not included in the mask candidate list, the target information is not necessarily included in the mask list.

And in the second case, the shielding candidate list comprises the target information, but the shielding list does not comprise the target information.

In case three, the above target information is included in the mask list.

In the embodiment of the present application, since the mask list is a subset of the above-mentioned mask candidate list, when the above-mentioned target information is included in the mask list, the above-mentioned target information is necessarily included in the mask candidate list.

In an alternative embodiment, in order to ensure the validity of the user information and the device information included in the masked candidate list and the masked list, a corresponding validity duration is set for each user information and each device information. When the storage time of a certain user information or a certain device information in the shielding candidate list exceeds the effective time of the user information or the device information, the server can delete the user information or the device information from the shielding candidate list and the shielding list.

In an optional embodiment, since the mask list is a subset of the mask candidate list, whether the target information is included in the mask list and the mask candidate list is determined, whether the target information is included in the mask candidate list may be determined first, and then whether the target information is included in the mask list may be determined. For example, the target information is not included in the mask candidate list, and in this case, the target information is not necessarily included in the mask list. Therefore, the screening candidate list is judged first, so that the judging time can be effectively shortened, and the judging efficiency is improved.

The interface request is responded to in the above step S104, i.e. when the target information is not included in the mask list.

In this step, after judging whether the shielding candidate list and the shielding list include the target information, if the shielding list does not include the target information, that is, if the judging result satisfies the first and second conditions, the server may determine that the behavior of the user sending the interface request through the client is not malicious, and at this time, the server may respond to the received interface request.

In the embodiment of the application, when the server responds to the interface request, the response mode of the interface request is different according to the different types of the interface request.

For example, when the interface request is the data acquisition request, the server may send the data acquired by the client request to the client in response to the interface request.

For another example, when the interface request is the login request, the server may authenticate the login information according to the login information carried in the login request, such as a user account number and an account password, when the server responds to the interface request, and allow the client to access the server after the authentication is passed.

In the embodiment of the present application, the response manner to the interface request is not particularly limited.

The interface request is masked for the above step S105, that is, when the target information is included in both the masked candidate list and the masked list.

In this step, after judging whether the shielding candidate list and the shielding list include the target information, if the shielding list and the shielding candidate list both include the target information, that is, the judging result satisfies the third condition, the server may determine that the behavior of the user sending the interface request through the client is malicious, and at this time, the server may shield the received interface request to realize the anti-brushing of the target interface.

In the embodiment of the application, when the server side shields the interface request, the shielding mode of the interface request is different according to different types of the interface request.

For example, when the interface request is the data acquisition request, the server may not receive the interface request sent by the client for a certain period of time when the server masks the interface request; alternatively, a first prompting message may be sent to the client, where the first prompting message may be used to prompt the user that the request fails and is re-requested after a certain period of time.

For another example, when the interface request is the login request, the server may perform a locking operation on the user account according to the login information carried in the login request when responding to the interface request.

In the embodiment of the present application, the shielding manner of the interface request is not particularly limited.

In the embodiment of the application, when judging whether the target information is included in the shielding candidate list and the shielding list, the judging result only shows one of the first case, the second case and the third case. Therefore, after executing the step S103, the server will execute the step S104 or directly execute the step S105.

In an alternative embodiment, according to the method shown in fig. 1, an embodiment of the present application further provides an interface anti-brushing method. Fig. 3 is a schematic diagram of a second flow chart of an interface anti-brushing method according to an embodiment of the present application. The method specifically comprises the following steps.

Step S301, an interface request sent by a user through a client is received, where the interface request includes a target interface requested by the client.

Step S302, based on the interface request, user information of the user and/or equipment information of the client side are obtained as target information.

Step S303, a shielding list and a shielding candidate list at the current moment are obtained, wherein the shielding list is a subset of the shielding candidate list.

Step S304, when the mask list does not include the target information, responds to the interface request.

The steps S301 to S304 are the same as the steps S101 to S104.

In step S305, if the target information is not included in the mask candidate list, the first frequency of receiving the interface request associated with the target information in the first period before the current time is counted.

The first duration may be set according to a user requirement, and the first duration is not specifically limited herein.

The statistical method for the first frequency is described below, and is not described in detail herein.

In the embodiment of the present application, when the target information is not included in the mask candidate list, the server may simultaneously execute the step S304 and the step S305.

Step S306, when the first frequency is greater than or equal to the second frequency, updating the target information to a shielding candidate list; the second frequency is the frequency corresponding to the target interface and the target information in the first anti-brushing strategy.

In the embodiment of the application, a plurality of first anti-brushing strategies are preconfigured in the server side. The server may determine a second frequency in the first anti-brush policy that includes the target interface and the target information, thereby comparing the first frequency with the second frequency.

When the first frequency is greater than or equal to the second frequency, the server may determine that the number of requests of the user or the client for the target interface matches the first anti-brushing policy. That is, the server may determine that the number of requests for the target interface by the user or client is relatively frequent. At this time, the server may update the target information to the masked candidate list.

In the embodiment of the present application, for each first anti-brushing policy preconfigured in the server, the first anti-brushing policy at least includes interface information, user information/device information, and frequency information (i.e. the second frequency). For ease of understanding, table 1 is used as an example.

TABLE 1

First anti-brush strategy	Interface information	User information/device information	Frequency information
				Strategy 1	Interface 1	UID 1	10 times/min
Policy 2	Interface 2	UID 2	4 times/min
				Policy 2	Interface 1	UID 2	7 times/min

In the first anti-swipe policy shown in table 1, policy 1 indicates that UID 1 triggers an interface request to interface 1 10 times within 1 minute. Policy 2 represents 4 times that UID 2 triggers an interface request to interface 2 within 1 minute. Policy 3 represents 4 times the number of interface requests to interface 1 triggered by UID 2 within 1 minute.

The frequency information in table 1 is expressed as the number of times of transmission of interface requests per unit time (i.e., 1 minute). In addition, the frequency information may be represented in other forms, for example, the number of transmission times of the interface request in 5 minutes, and the like. Here, the expression of the frequency information in the first anti-brushing policy is not particularly limited.

In the embodiment of the present application, the preconfigured first anti-brushing policies may further include other information, such as expiration time of each anti-brushing policy, besides the interface information, the user information/device information, and the frequency information. Here, the information included in the first anti-brush policy is not particularly limited.

In an optional embodiment, when determining, from a plurality of first anti-brushing policies configured in advance, a second frequency in the first anti-brushing policies including a target interface and target information, the server may traverse each first anti-brushing policy, thereby selecting the interface information as the target interface, and the user information or the device information as the first anti-brushing policy of the target information, and determining the frequency information in the first anti-brushing policy as the second frequency.

For ease of understanding, the above-described target interface is taken as interface 1, and the target information is taken as UID 1 as an example, and is described in conjunction with table 1. The server may obtain all the first anti-brushing policies including the interface 1 in table 1, where the user information is UID 1, to obtain the first anti-brushing policies of the target interface and the target information, that is, the policy 1 shown in table 1. The server may determine the frequency information in the policy 1, that is, 10 times/min, as the second frequency.

In the embodiment of the present application, when determining the second frequency in the first anti-brushing policies including the target interface and the target information, the server may not determine the second frequency because the pre-configured first anti-brushing policies may not include the anti-brushing policies including the target interface and the target information. At this time, the server may not perform any processing, that is, may not perform the step of updating the target information to the masked candidate list.

For ease of understanding, the second frequency determined is exemplified by 10 times/min in table 1 above.

The server compares the first frequency with the second frequency (i.e. 10 times/min). When the first frequency is greater than or equal to 10 times/min, for example, the first frequency is 12 times/min, and 12 times/min is >10 times/min, the server may add the target information to the shielding candidate list. When the first frequency is less than 10 times/min, for example, the first frequency is 9 times/min, and 9 times/min <10 times/min, the server may not process the target information, that is, the target information may not be added to the shielding candidate list.

In an optional embodiment, after the second frequency of the first anti-brushing policies including the target information or the target interface is not determined, the server may generate a second prompting message including the target information, so as to prompt the operation and maintenance personnel that the anti-brushing policies corresponding to the target information are not included in the plurality of first anti-brushing policies, so that the operation and maintenance personnel determine whether the corresponding first anti-brushing policies need to be set for the target information.

In an optional embodiment, after updating the target information to the masked candidate list, a corresponding effective duration may be set for the target information in the masked candidate list.

The effective duration setting of the target information in the shielding candidate list may be set according to the actual requirement of the operation and maintenance personnel, the historical access frequency of the user, and the like, where the effective duration setting is not specifically limited.

In the embodiment of the application, the shielding candidate list is updated according to the frequency of the interface request triggered by the user in the first time period or the frequency of the interface request sent by the client in the first time period by the preconfigured first anti-brushing strategy, so that the accuracy of the shielding candidate list is ensured. In addition, the first anti-brushing strategy can be adjusted according to the user requirement or the application scene, so that the first anti-brushing strategy can be applied to different application scenes, and the adaptability of the first anti-brushing strategy in different application scenes is improved.

In step S307, when the masked candidate list and the masked list both include the target information, the interface request is masked.

Step S307 is the same as step S105.

In an alternative embodiment, according to the method shown in fig. 1, an embodiment of the present application further provides an interface anti-brushing method. Fig. 4 is a schematic flow chart of a third method for preventing interface brushing according to an embodiment of the present application. The method specifically comprises the following steps.

Step S401, receiving an interface request sent by a user through a client, wherein the interface request comprises a target interface requested by the client.

Step S402, based on the interface request, user information of the user and/or equipment information of the client side is obtained as target information.

Step S403, a mask list and a mask candidate list at the current time are obtained, where the mask list is a subset of the mask candidate list.

Step S404, when the object information is not included in the mask list, responding to the interface request.

The steps S401 to S404 are the same as the steps S101 to S104.

Step S405, if the shielding candidate list includes the target information, but the shielding list does not include the target information, acquiring the first user behavior data in the second time before the current time.

In the embodiment of the present application, when the shielding candidate list includes the target information, but the shielding list does not include the target information, in order to ensure accuracy of the obtained first user behavior data, the server may obtain, from the client, the behavior data of the user within the second duration as the first user behavior data.

In an optional embodiment, the server may obtain, from the client, user behavior data corresponding to each of the behavior categories executed by the user in the second duration, as the first user behavior data.

In another optional embodiment, in order to reduce the data amount of the obtained first user behavior data, so as to improve the update efficiency of the above-mentioned mask list, the server may obtain, from the client, user behavior data corresponding to a specific behavior class executed by the user in the second duration, as the first user behavior data. Wherein, the description of specific behavior categories can be found below and is not specifically described herein.

The second time period may be the same as the first time period or the same as the first time period. Here, the second time period is not particularly limited.

In the embodiment of the present application, the user behavior data includes behavior categories and behavior values corresponding to each behavior category. Wherein behavior categories include, but are not limited to, click behavior, slide behavior, and stay behavior. And the behavior value corresponding to each behavior category. The behavior values are all different according to the behavior categories.

For example, when the behavior type is the clicking behavior, the behavior value corresponding to the clicking behavior may be expressed as the number of clicks when the user performs the clicking behavior. When the behavior type is the sliding behavior, the behavior value corresponding to the sliding behavior may be expressed as a sliding distance when the user performs the sliding behavior. When the behavior category is the stay behavior, the stay behavior may be expressed as a stay time length corresponding to the stay behavior.

In the embodiment of the present application, the behavior category included in the user behavior data and the behavior numerical value corresponding to each behavior category are not particularly limited.

In the embodiment of the present application, when the target information is included in the masked candidate list but the target information is not included in the masked list, the server may simultaneously execute the step S404 and the step S405.

Step S406, when the first user behavior data is matched with the second user behavior data, updating the target information to a shielding list; the second user behavior data is user behavior data corresponding to the target interface and the target information in the second anti-brushing strategy.

In the embodiment of the present application, the server may be preconfigured with a plurality of second anti-brushing policies in addition to the plurality of first anti-brushing policies. The server may acquire a second anti-brushing policy including the target interface and the target information from a plurality of second anti-brushing policies preconfigured by the server according to the target interface and the target information, and determine user behavior data in the second anti-brushing policy as the second behavior data.

The server may compare the first user behavior data with the second user behavior data, so as to determine whether the first user behavior data matches with the second user behavior data. And when the first user behavior data is matched with the second user behavior data, updating the target information to a shielding list. For the matching of the first behavior data and the second behavior data, reference is made to the following description, which is not described in detail here.

In the embodiment of the application, aiming at each second anti-brushing strategy pre-configured in the server, the second anti-brushing strategy at least comprises interface information and user behavior data. For ease of understanding, table 2 is used as an example.

TABLE 2

In table 2, policy a indicates that the number of clicks for the user corresponding to UID1 to perform a clicking action with respect to interface 1 is 10. Policy B indicates that the dwell time period when the user corresponding to UID 2 performs the dwell action with respect to interface 2 is 10 seconds. Policy C indicates that the dwell time period when the user corresponding to UID1 performs the dwell action with respect to interface 1 is 20 seconds.

For ease of understanding, the above-described target interface is described as the above-described interface 1. The server may traverse each second anti-brushing policy preconfigured, and select all anti-brushing policies including interface information as interface 1 and user information as UID1, i.e. policies a and C.

In the embodiment of the present application, the second anti-brushing policy may further include other information besides the interface information and the user behavior data. For example, feedback addresses and expiration time corresponding to each second anti-brushing policy. Specifically, the results are shown in Table 3.

TABLE 3 Table 3

In table 3, the feedback address corresponding to policy a is test.act.com/test1, the feedback address corresponding to policy 2 is test.act.com/test2, and the feedback address corresponding to policy C is test.act.com/test3.

The feedback address may correspond to a certain storage space in the server. Here, the feedback address is not particularly limited.

In the embodiment of the present application, the information included in the second plurality of pre-configured anti-brushing policies is not specifically limited.

The shielding list can be updated according to the first user behavior data executed by the user in the second time period through the second pre-configured anti-brushing strategy, so that the accuracy of the shielding list is ensured. In addition, the second anti-brushing strategy can be adjusted according to the user requirement or the application scene, so that the second anti-brushing strategy can be applied to different application scenes, and the adaptability of the second anti-brushing strategy in different application scenes is improved.

In step S407, when the masked candidate list and the masked list both include the target information, the interface request is masked.

Step S407 is the same as step S104.

In an alternative embodiment, according to the method shown in fig. 4, an embodiment of the present application further provides an interface anti-brushing method. Fig. 5 is a schematic diagram of a fourth flow chart of an interface anti-brushing method according to an embodiment of the present application. Specifically, the above step S405 is subdivided into the following steps. I.e. step S4051-step S4053.

Step S4051, a second anti-brush policy including the target interface is acquired.

In this step, the server may obtain, from a plurality of second anti-brushing policies configured in advance, the second anti-brushing policy whose interface information is the target interface.

The following description will take Table 3 as an example. Now, assuming that the target interface is the interface 1, the server may acquire the interface information as the second anti-brushing policy of the interface 1, that is, the policy a and the policy C in the table 3.

Step S4052, according to each behavior category included in the third user behavior data in the acquired second anti-brushing strategy, sending a data acquisition request including a feedback address to the client; after receiving the data acquisition request, the client acquires first user behavior data corresponding to the behavior of each behavior category executed by the user in a second time before the current time, and stores the first user behavior data to the feedback address.

In this step, the server may send a data acquisition request including feedback address information to the client according to each behavior category included in the second user behavior data in the second anti-brushing policy acquired in the step S4051. That is, after the server side executes the step S4051 to obtain the second anti-brushing policies, the server side sends a data obtaining request including the behavior category and the feedback address in each obtained second anti-brushing policy to the client side. At this time, the behavior class of each second anti-brushing policy obtained in step S4051 is the specific behavior class.

In the embodiment of the present application, the number of data acquisition requests sent by the server may be one or more according to the difference in the number of the first anti-brushing policies obtained in step S4051.

For easy understanding, the data acquisition request sent by the server is illustrated with the second anti-brushing policy acquired in step S4051 being policy a and policy C in table 3.

In one example, the server may send a data acquisition request to the server according to policies a and C. At this time, the click behavior and test.act.com/test1 in the above-described policy a, and the stay behavior and test.act.com/test3 in the above-described policy C are included in the data acquisition request.

In another example, the server may send two data acquisition requests to the server according to policies a and C. One data acquisition request includes the click behavior and test.act.com/test1 in the above-described policy a. The other data acquisition request includes the stay behavior in policy C and test.act.com/test3 described above.

Here, the transmission of the data acquisition request is not particularly limited.

After receiving the data request sent by the server, the client may obtain user behavior data corresponding to the user executing the behavior of each behavior class (i.e., each specific behavior class) in the second duration, so as to obtain first user behavior data. The client may store the acquired first user behavior data to the corresponding feedback address according to each feedback address included in the data acquisition request.

For ease of understanding, the second anti-brushing policy obtained in step S4051 is still described as an example of the policies a and C in table 3.

After receiving the data acquisition request, the client acquires user behavior data corresponding to the user when clicking behaviors are executed in the second time period, and stores the user behavior data into a storage space with a server address of test.act.com/test1. In addition, the client acquires user behavior data corresponding to the user when the user executes the stay behavior in the second time period, and stores the user behavior data into a storage space with a server address of test.act.com/test3.

Step S4053, the first user behavior data is read from the feedback address.

Through the steps S4051-S4053, the server only obtains the first user behavior data when the user executes the behavior of the specific behavior class in the second duration from the client, so that the number of the first user behavior data obtained by the server is effectively reduced, the duration required by comparing the later period with the second user behavior data is shortened, the time required by updating the shielding list is further shortened, and the updating efficiency of the shielding list is improved. In addition, since each first user behavior data is stored according to the feedback address included in the received data acquisition request, the first user behavior data of different behavior categories can be conveniently stored separately, and the convenience of the server side for reading the first user behavior data of different behavior categories from different feedback addresses is improved.

In an alternative embodiment, according to the method shown in fig. 4, an embodiment of the present application further provides an interface anti-brushing method. Fig. 6 is a schematic diagram of a fifth flow chart of an interface anti-brushing method according to an embodiment of the application. The method comprises the following steps.

In step S601, an interface request sent by a user through a client is received, where the interface request includes a target interface requested by the client.

Step S602, based on the interface request, user information of the user and/or device information of the client are obtained as target information.

Step S603, a mask list and a mask candidate list at the current time are acquired, where the mask list is a subset of the mask candidate list.

In step S604, when the target information is not included in the mask list, the interface request is responded.

Step S605, if the shielding candidate list includes the target information, but the shielding list does not include the target information, the first user behavior data in the second time period before the current time is obtained.

The steps S601 to S605 are the same as the steps S401 to S405.

Step S606, for each behavior category in the second anti-brushing strategy including the target interface, comparing the behavior value corresponding to the behavior category in the first user behavior data with the behavior value corresponding to the behavior category in the second user behavior data to obtain a first comparison result.

In this step, for each behavior category in the second anti-brushing policy including the target interface, the server compares the behavior value corresponding to the behavior category in the first user behavior data determined in the above step S605 with the behavior value corresponding to the behavior category in the second user behavior data, to obtain a comparison result, and records the comparison result as the first comparison result.

For ease of understanding, the second user behavior data is described by taking the second user behavior data included in the policy a in table 3 as an example.

After obtaining the first user behavior data from the storage space with the address of test.act.com/test1, the server may compare the behavior value in the first user behavior data with the behavior value in the second user behavior data (i.e. 10 times in table 3 above) included in the policy a, so as to determine whether the behavior value in the first user behavior data is greater than or equal to 10 times, and obtain a first comparison result.

The first comparison result may indicate that the behavior value included in the first user behavior data is greater than or equal to the behavior value included in the second user behavior data, or may indicate that the behavior value included in the first user behavior data is less than the behavior value included in the second user behavior data.

In step S607, when any of the first comparison results indicates that the behavior value included in the first user behavior data is greater than or equal to the behavior value included in the second user behavior data, the target information is updated to the mask list.

In this step, when any one of the first comparison results indicates that the behavior value included in the first user behavior data is greater than or equal to the behavior value included in the second user behavior data, the server may determine that the first user behavior data matches the second user behavior data. At this time, the server may update the target information to the mask list.

In the embodiment of the application, after updating the target information to the shielding list, the server side can set a corresponding effective duration for the target information.

In an optional embodiment, when the effective duration of the target information in the mask list is set, the effective duration may be the same as the remaining effective duration of the target information in the mask candidate list, where the remaining effective duration may be expressed as: the effective duration in the masked candidate list- (current time-storage time of target information to the masked candidate list).

In another alternative embodiment, when the effective duration of the target information in the mask list is set, the effective duration may be a reset effective duration. At this time, the effective duration of the target information in the shielding candidate list will be synchronized to the reset effective duration.

Through the steps S606-S607, the server may accurately determine whether the first user behavior data matches the second user behavior data, so as to update the mask list when the first user behavior data matches the second user behavior data. This effectively ensures the accuracy of the matching of the first user behavior data and the second user behavior data, thereby ensuring the accuracy of the updating of the mask list.

In step S608, when the masked candidate list and the masked list both include the target information, the interface request is masked.

Step S608 is the same as step S407.

In an alternative embodiment, according to the method shown in fig. 1, an embodiment of the present application further provides an interface anti-brushing method. Fig. 7 is a schematic diagram of a sixth flow chart of an interface anti-brushing method according to an embodiment of the present application. The method comprises the following steps.

Step S701, receiving an interface request sent by a user through a client, where the interface request includes a target interface requested by the client.

Step S702, based on the interface request, obtains user information of the user and/or device information of the client as target information.

The steps S701 to S702 are the same as the steps S101 to S102.

Step S703, updating the number of requests corresponding to the target information stored in the preset dis according to the received interface request.

In this step, after receiving the interface request, the server may record, according to the target information, the number of requests corresponding to the target information by using a preset dis. Wherein Redis is a database.

In the embodiment of the present application, the preset Redis includes a key (key) value and a request number (value). After the received interface request and the target information corresponding to the interface request are determined, the server may add 1 to the value corresponding to the target information, which is the number of requests corresponding to the target request, to the value corresponding to the target information in the preset Redis.

In an optional embodiment, the effective duration of the number of requests corresponding to the target information stored in the preset Redis is a first duration. At this time, the number of requests corresponding to the target information stored in the preset Redis may represent the frequency of interface requests triggered by the user in the first duration, or the frequency of interface requests sent by the client in the first duration, that is, the first frequency.

In an optional embodiment, if the effective duration of the number of requests corresponding to the target information stored in the preset dis is a first duration, when the server side counts the first frequency of the interface requests associated with the target information received in the first duration before the current time, the server side may calculate the first frequency of the interface requests associated with the target information received in the first duration before the current time according to the number of requests corresponding to the target information stored in the preset dis and the first duration of the interface requests. That is, the server directly determines the number of requests corresponding to the target information stored in the dis as the first frequency of interface requests triggered by the user in the first duration, or the first frequency of interface requests sent by the client in the first duration.

In the embodiment of the application, the statistics of the request times corresponding to the target information can be realized by providing the preset Redis, and the accuracy of the determined first frequency is ensured while the time required for determining the first frequency is shortened on the premise of ensuring the validity of each data stored in the preset Redis by the effective time corresponding to each request time recorded in the preset Redis.

Step S704, a shielding list and a shielding candidate list at the current moment are obtained, wherein the shielding list is a subset of the shielding candidate list.

Step S705, when the object information is not included in the mask list, responding to the interface request.

In step S706, when the target information is included in both the masked candidate list and the masked list, the interface request is masked.

The steps S704 to S706 are the same as the steps S103 to S105.

For ease of understanding, the above-described interface anti-brushing method is described with reference to fig. 8 by using the server shown in fig. 2. Fig. 8 is a signaling diagram of an interface anti-brushing procedure according to an embodiment of the present application. The method specifically comprises the following steps.

In step S801, the anti-brushing policy configuration module obtains a first anti-brushing policy and a second anti-brushing policy configured for different interfaces.

The first anti-brushing policy is configured according to the frequency of interface requests triggered by a user or the frequency of interface requests sent by a client. The second anti-brushing strategy is configured according to the behavior value of each behavior type executed by the user.

In step S802, the client sends an interface request to the interface service module.

The interface request includes a target interface requested by the client.

In step S803, the interface service module forwards the interface request to the real-time computing module.

In step S804, when receiving the interface request, the real-time computing module obtains user information of the user and/or device information of the client as target information.

In step S805, the real-time computing module updates the number of requests corresponding to the target information stored in the preset dis according to the received interface request.

In step S806, the real-time computing module respectively determines whether the shielding candidate list and the shielding list include the target information, and obtains a determination result.

If the above determination result indicates that the mask candidate list does not include the target information, steps S807 to S808 and steps S809 to S812 are performed. If the above determination result indicates that the masked candidate list includes the target information, but the masked list does not include the target information, steps S807-S808 and steps S813-S818 are performed. If the above determination result indicates that the mask candidate list includes the target information, steps S807 to S808 are performed.

In executing the above-described step S807 and the above-described step S809, the execution order of the step S807 and the step S809 is not particularly limited. In executing the step S807 and the step S813, the execution order of the step S807 and the step S813 is not particularly limited.

In step S807, the real-time computing module determines whether to mask the interface request according to the determination result, obtains the determination result, and sends the determination result to the interface service module.

The real-time computing module may determine that the server normally responds to the interface request when the determination result indicates that the masked candidate list does not include the target information, or indicates that the masked candidate list includes the target information, but the masked list does not include the target information. And when the judging result indicates that the shielding candidate list comprises the target information, the real-time computing module can determine a server shielding interface request.

In step S808, the interface service module masks or responds to the interface request according to the received determination result.

The above determination may indicate a normal response interface request. The determination result may also indicate a mask interface request

In step S809, the real-time calculation module calculates, according to the number of requests corresponding to the target information stored in the preset Redis and the first duration of the requests, the first frequency of the interface requests associated with the target information received in the first duration before the current time.

In step S810, the real-time computing module reads a first anti-brushing policy including the target information and the target interface in the policy anti-brushing configuration module.

In step S811, the real-time computing module determines whether the first frequency is greater than or equal to the second frequency in the read first anti-brushing policy. If yes, go to step S812. If not, the processing is not performed.

In step S812, the real-time computing module updates the target information to the mask candidate list.

In step S813, the real-time computing module reads the second anti-brushing policy of the target interface in the policy anti-brushing configuration module.

In step S814, the real-time computing module triggers the interface service module to send a data acquisition request including the feedback address to the client according to each behavior category included in the third user behavior data in the second anti-brushing policy.

In step S815, after receiving the data acquisition request, the client acquires first user behavior data corresponding to the user executing the behavior of each behavior category in the second time before the current time, and stores the first user behavior data to the feedback address through the interface service module.

In step S816, the real-time computing module reads the first user behavior data from the feedback address.

In step S817, the real-time computing module compares, for each behavior category in the obtained second anti-brushing policy, a behavior value corresponding to the behavior category in the first user behavior data with a behavior value corresponding to the behavior list in the second user behavior data, so as to obtain a first comparison result.

The second user behavior data is user behavior data in a second anti-brushing strategy comprising target information and a target interface. The third user behavior data is user behavior data in a second anti-brushing policy including a target interface. The third user behavior data includes the second user behavior data.

In step S818, when any one of the first comparison results indicates that the behavior value included in the first user behavior data is greater than or equal to the behavior value included in the second user behavior data, the real-time computing module updates the target information to the mask list.

Based on the same inventive concept, according to the interface anti-brushing method provided by the embodiment of the application, the embodiment of the application also provides an interface anti-brushing device. Fig. 9 is a schematic structural diagram of an interface anti-brushing device according to an embodiment of the present application, as shown in fig. 9. The device is applied to the server and specifically comprises the following modules.

The receiving module 901 is configured to receive an interface request sent by a user through a client, where the interface request includes a target interface requested by the client;

a first obtaining module 902, configured to obtain user information of a user and/or device information of a client as target information based on an interface request;

A second obtaining module 903, configured to obtain a mask list and a mask candidate list at a current time, where the mask list is a subset of the mask candidate list;

a response module 904, configured to respond to the interface request when the mask list does not include the target information;

a shielding module 905, configured to shield the interface request when the shielding candidate list and the shielding list both include target information;

the target information in the shielding list is updated to the shielding list when the number of times of the request of the user or the client to the target interface is matched with the first anti-brushing strategy, and the target information in the shielding list is updated to the shielding list when the user behavior data of the user is matched with the second anti-brushing strategy.

Optionally, the interface anti-brushing device may further include:

the statistics module is used for counting a first frequency of receiving interface requests associated with target information in a first time period before the current moment if the target information is not included in the shielding candidate list;

the first updating module is used for updating the target information to the shielding to-be-selected list when the first frequency is greater than or equal to the second frequency; the second frequency is the frequency corresponding to the target interface and the target information in the first anti-brushing strategy.

Optionally, the interface anti-brushing device may further include:

the third acquisition module is used for acquiring first user behavior data in a second time period before the current moment if the shielding list comprises target information but the shielding list does not comprise target information;

the second updating module is used for updating the target information to the shielding list when the first user behavior data is matched with the second user behavior data; the second user behavior data is user behavior data corresponding to the target interface and the target information in the second anti-brushing strategy.

Optionally, the user behavior data may include a behavior class;

the third obtaining module may include:

an acquisition sub-module for acquiring a second anti-brush policy comprising a target interface;

the sending sub-module is used for sending a data acquisition request comprising a feedback address to the client according to each behavior category included in the acquired third user behavior data in the second anti-brushing strategy; after receiving the data acquisition request, the client acquires first user behavior data corresponding to the behavior of each behavior category executed by the user in a second time before the current moment, and stores the first user behavior data to a feedback address;

Optionally, the user behavior data may include a behavior class and a behavior value corresponding to each behavior class;

the interface anti-brushing device may further include:

the comparison module is used for comparing a behavior value corresponding to the behavior type in the first user behavior data with a behavior value corresponding to the behavior type in the second user behavior data for each behavior type in a second anti-brushing strategy comprising a target interface after acquiring the first user behavior data in a second time before the current time, so as to obtain a first comparison result;

the second updating module may be specifically configured to update the target information to the mask list when any one of the first comparison results indicates that the behavior value included in the first user behavior data is greater than or equal to the behavior value included in the second user behavior data.

Optionally, the interface anti-brushing device may further include:

and the third updating module is used for updating the request times corresponding to the target information stored in the preset Redis according to the received interface request after acquiring the user information of the user and/or the equipment information of the client based on the interface request and taking the user information and/or the equipment information of the client as the target information.

According to the device provided by the embodiment of the application, after receiving the interface request sent by the user through the client, the interface request is responded or shielded according to whether the shielding list and the shielding candidate list comprise the target information corresponding to the interface request. That is, when the target information is not included in the mask list, responding to the interface request; and when the shielding candidate list and the shielding list both comprise target information, shielding the interface request.

Based on the same inventive concept, according to the interface anti-brushing method provided by the above embodiment of the present application, the embodiment of the present application further provides a server, as shown in fig. 10, including a processor 1001, a communication interface 1002, a memory 1003, and a communication bus 1004, where the processor 1001, the communication interface 1002, and the memory 1003 complete communication with each other through the communication bus 1004,

a memory 1003 for storing a computer program;

the processor 1001 is configured to execute a program stored in the memory 1003, and implement the following steps:

based on the interface request, acquiring user information of a user and/or equipment information of a client as target information;

Acquiring a shielding list and a shielding to-be-selected list at the current moment, wherein the shielding list is a subset of the shielding to-be-selected list;

responding to the interface request when the target information is not included in the shielding list;

when the shielding list to be selected and the shielding list both comprise target information, shielding an interface request;

After receiving an interface request sent by a user through a client, the server provided by the embodiment of the application responds or shields the interface request according to whether the shielding list and the shielding candidate list comprise target information corresponding to the interface request. That is, when the target information is not included in the mask list, responding to the interface request; and when the shielding candidate list and the shielding list both comprise target information, shielding the interface request.

The communication bus mentioned by the above terminal may be a peripheral component interconnect standard (Peripheral Component Interconnect, abbreviated as PCI) bus or an extended industry standard architecture (Extended Industry Standard Architecture, abbreviated as EISA) bus, etc. The communication bus may be classified as an address bus, a data bus, a control bus, or the like. For ease of illustration, the figures are shown with only one bold line, but not with only one bus or one type of bus.

The communication interface is used for communication between the terminal and other devices.

The memory may include random access memory (Random Access Memory, RAM) or non-volatile memory (non-volatile memory), such as at least one disk memory. Optionally, the memory may also be at least one memory device located remotely from the aforementioned processor.

The processor may be a general-purpose processor, including a central processing unit (Central Processing Unit, CPU for short), a network processor (Network Processor, NP for short), etc.; but also digital signal processors (Digital Signal Processor, DSP for short), application specific integrated circuits (Application Specific Integrated Circuit, ASIC for short), field-programmable gate arrays (Field-Programmable Gate Array, FPGA for short) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

Based on the same inventive concept, according to the interface anti-brushing method provided by the above embodiment of the present application, the embodiment of the present application further provides a computer readable storage medium, where a computer program is stored, and when the computer program is executed by a processor, the interface anti-brushing method described in any one of the above embodiments is implemented.

Based on the same inventive concept, according to the interface anti-brushing method provided by the above embodiment of the present application, the embodiment of the present application further provides a computer program product containing instructions, which when executed on a computer, cause the computer to perform the interface anti-brushing method described in any one of the above embodiments.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, produces a flow or function in accordance with embodiments of the present application, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in or transmitted from one computer-readable storage medium to another, for example, by wired (e.g., coaxial cable, optical fiber, digital Subscriber Line (DSL)), or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., floppy Disk, hard Disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid State Disk (SSD)), etc.

It is noted that relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

In this specification, each embodiment is described in a related manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for embodiments of the apparatus, the server, the computer-readable storage medium, and the computer program product, the description is relatively simple, as it is substantially similar to the method embodiments, and the relevant points are found in the partial description of the method embodiments.

The foregoing description is only of the preferred embodiments of the present application and is not intended to limit the scope of the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application are included in the protection scope of the present application.

Claims

1. An interface anti-brushing method, which is characterized by being applied to a server, comprising:

2. The method according to claim 1, wherein the method further comprises:

3. The method according to claim 1, wherein the method further comprises:

4. A method according to claim 3, wherein the user behavior data comprises a behavior class;

acquiring a second anti-brushing strategy comprising the target interface;

and reading the first user behavior data from the feedback address.

5. A method according to claim 3, wherein the user behavioural data comprises behavioural categories and behavioural values corresponding to each behavioural category;

6. The method according to claim 1, further comprising, after acquiring user information of the user and/or device information of the client as target information based on the interface request:

and updating the request times corresponding to the target information stored in a preset remote dictionary service Redis according to the received interface request.

7. The method of claim 6, wherein the valid duration of the number of requests corresponding to the target information stored in the preset dis is a first duration.

8. An interface anti-brush device, for application to a server, the device comprising:

9. The server side is characterized by comprising a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory are communicated with each other through the communication bus;

A memory for storing a computer program;

a processor for carrying out the method steps of any one of claims 1-7 when executing a program stored on a memory.

10. A computer-readable storage medium, characterized in that the computer-readable storage medium has stored therein a computer program which, when executed by a processor, implements the method steps of any of claims 1-7.