foreword
This article will show you low-code development: prevent non-WeChat users from obtaining red envelopes by using user component authentication, and use services and transactions to record the records of users claiming red envelopes; users who qualify for red envelopes will send the amount generated in the background through background logic to my WeChat.
Article directory
overview
iVX is a "zero-code" visual programming language. It has a convenient online integrated development environment. It does not need to download the development environment, and you can edit projects anytime and anywhere by opening a browser.
Today, let's discuss the application of WeChat red envelopes. When we are making red envelope applications, the most common problems that arise are:
1. Being swiped
2. The concurrency is too high, resulting in too high fees
Let's first specifically analyze the causes of these two problems, and then use a demo case to give a relatively reasonable solution.
The principle and solution of red envelope anti-brushing
First, get brushed. There are two main ways to be maliciously swiped red envelopes by the wool party. The first is to crack the front-end encryption request, set a fixed WeChat openid, send a request to our server to receive the red envelope, and directly send the red envelope to the predetermined openid. The second is to send the red envelope address to a special "wool group", and then the real wool party users will manually receive the red envelope. Please note that if we do not set any rules for receiving red envelopes, such as redeeming through a pre-issued coupon code, any valid WeChat user can receive red envelopes, then the second type of "wool group" of real users cannot For prevention, we can only do a good job of confidentiality during the event, and properly limit the concurrency, limit the speed at which the wool party can receive red envelopes, and leave us with events to deal with. (Note that just disabling forwarding in WeChat does not prevent the Wool Party from sending red envelope links, because there are many ways to obtain an H5 address, such as directly copying the URL address.)
Therefore, for the wool group of the second type of real users, we strongly recommend setting certain thresholds when designing red envelope activities. For example, users must first pay attention to the official account, receive a red envelope password in the background of the official account, and then pass this password , can be exchanged for real red envelopes. In this way, even real users must first pay attention to the official account. Or, pre-set a list of users who can receive red envelopes, and verify whether they are in this white list when claiming.
Next, let's focus on analyzing how to prevent the first type of red envelope swiping. Compared with the second type of real users, the first type is more harmful, because people who use red envelopes can pre-apply for a batch of zombie accounts, and directly use the background service to send red envelopes to these zombie accounts in batches. This kind of batch swiping may sweep away tens of thousands of red envelopes in an instant. Relatively speaking, the second real wool group brushing method is unlikely to have all the red envelopes swiped in a few seconds in an instant, because real users still have to go through our front-end display process in full until the last step In order to receive the red envelope. Although they are not our client's "target users", they are still human users, not machines.
The method to prevent the first type of machine brushing is mainly to set up a defense line for our services:
Line of defense 1: front-end request encryption
The front end of the ivx
The same request, when issued, is the encrypted data:
Therefore, under normal circumstances, by viewing the published H5, it is impossible to obtain the real request data and simulate sending the request. But please note that since the front-end encryption is performed on the client side using js, theoretically speaking, it is still possible for an expert to crack it and obtain the original information requested. Therefore, we cannot rely on front-end encryption, and we must build more lines of defense in the background of the service.
PS: The iVX platform is developing an upgraded version of the front-end encryption method. At that time, the request encryption part will use web assembly instead of pure js, and the difficulty of cracking the front-end encryption will increase exponentially. But even so, we still cannot fully trust client-side encryption.
Line of defense 2: Set service call permissions
Any
service that does not require authentication is dangerous. Usually, we need the user to log in to an account first, and then have permission to call the service. For example, when we view the work list in the ivx workbench, it is impossible to allow users who are not logged in to view the works of any other user. The same is true when we make our own services, and we must ask for user permissions at the service level.
In our red envelope scenario, we set up three services, which can only be called after the user logs in as a "normal user", otherwise, it will return no permission:
At the same time, the user is initializing and needs to initiate a WeChat login on the front end:
The process of logging in is actually that the background of ivx will return a token, which will be stored in the cookie of the browser on the user's mobile phone. When the user calls any service on the client side, the token will be automatically sent to the background service (this process is done automatically, we do not need to manually operate), so if you have not logged in to the user component and obtained a legal token, you will not have permission The service is called. In addition, since the WeChat login is initiated, a series of authentication procedures need to be invoked on the WeChat client and the background. Without a legal WeChat account, it is basically impossible to log in successfully if initiated on the WeChat client. Therefore, at this step, We have effectively set up a second line of defense, so that the service request of the machine brush cannot pass the verification smoothly.
In addition, to set permissions for a service, the premise is that there must be an entity service. Therefore, in the red envelope application, please strictly use the background service to send the red envelope, instead of calling the red envelope component directly on the front end and relying on the automatic service generated by the system.
Defense line 3: try to avoid exposing core parameters
Although the above second layer of defense can basically prevent the machine from brushing. But we still try to set up a third line of defense, just in case. For example, the Wool Party can crack the front-end service encryption and use automated N mobile devices to automatically swipe red envelopes. Each mobile device has to log in a real WeChat account, or has a valid mobile phone number, which can automatically identify the verification code and register.
For example, a collection of devices similar to the above. Although the cost of hiring such a professional "equipment farm" will be relatively high, as long as the benefits are sufficient, someone will still do it. In this case, we need to further protect our services. One of the simplest principles of protecting services is to put all logic in the background as much as possible, and do not use front-end parameters. For example, in our red envelope service, there are two important parameters, the amount of the red envelope, and the target openid for sending the red envelope. If these two parameters are sent by the front end when calling the service, then once the service is cracked, the wool party can call the "device farm", log in with any number, and specify the amount (it can be the maximum amount we allow) Amount), as well as the target users, will soon be able to swipe all the red envelopes to the designated account.
But if we don’t expose any parameters for receiving red envelopes, whether users can receive red envelopes and how much they can receive are all judged in the background logic. Even if the wool party opens the account, it is impossible to specify the account number and amount, which greatly reduces the amount of red envelopes. Benefits, increased difficulty:
Line of Defense 4: Use AI to Verify Behavior
We can also additionally use AI verification to determine whether an action is performed by a human or a robot. At present, Alibaba Cloud and Tencent Cloud have similar verification methods. It is recommended to add similar verification methods for sensitive applications. This will not only prevent robots from calling services to swipe red envelopes, but also prevent wool parties from "flying away" and giving up swipe services to reduce our cost.
Reduce consumption of high concurrent services
Next, let's solve the second problem, that is, how to reduce the server pressure when grabbing red envelopes as much as possible, so as to improve service response efficiency and reduce service costs. In the red envelope application, the biggest consumption is to use the database to judge that a user can only receive a red envelope once, or must meet certain conditions before receiving a red envelope.
First of all, in the red envelope component, we can limit the number of times each person can receive. Usually, each person can only receive once:
If our application is to receive red envelopes directly, there is no other place to optimize except for limiting the call frequency of the red envelope collection service (through the high concurrency limit, the default is 100, you can manually contact customer service to adjust it down). But in the usual event rules, we may limit the probability of users receiving red envelopes. For example, each person can only apply to receive once. There is a certain probability that they can receive red envelopes, and there is a certain probability that they will not win a prize. However, no matter whether you win the lottery or not, you cannot apply for the lottery again.
Therefore, we will make an application record form based on the red envelope component. The submission limit of this application record form directly uses the independent unique index of the submitting user:
In this way, each user can be restricted to submit only one record in this table. If we want to further limit that each user can only claim once a day, we can also add an additional date field and add a data-unique joint index.
Above, we realized the method of restricting users to submit only one application in total, or only one application per day through the independent unique index. This method is more efficient than the limit in the submit limit panel of the database:
In the above submission limit panel, the submission limit per person filled in is realized through database transactions inside iVX. Compared with ordinary services, transactions will consume more database service time because they will lock records.
Therefore, if our restriction is that each person can only submit one application in total or per person per day, then it is strongly recommended to use a data unique index, or a data unique joint index. At the same time, try to avoid using methods such as data output/statistics to count the number of applications of users, and then return whether the user can apply for red envelopes again according to the statistical results. This method, in addition to additional consumption, may also cause data inconsistency during high concurrency, giving the wool party an opportunity.
In addition to optimizing the method of limiting the number of times users apply for lottery draws, there is also a misunderstanding in the red envelope application, that is, some users will create a red envelope component or an application record database for each according to different red envelope amounts. Note that the red envelope component itself comes with a database record. However, creating multiple databases in one case consumes additional resources and is difficult to manage. Therefore, we can use the background logic to dynamically generate the red envelope amount without creating a red envelope component for each red envelope amount.
A simple example of red envelope implementation
According to the above principles, let's make a simple red envelope example.
Let me first introduce the rules of the game in this red envelope example. After understanding the implementation method, you can adjust the rules according to your actual needs:
- Each user can only apply for a red envelope once, and when applying, provide name, mobile phone and other information by the way;
- After each user applies, there is a certain probability that he will win the prize, and there is a certain probability that he will not win the prize. If you do not win the prize, you will no longer have the opportunity to apply again;
- If the user wins the lottery, the background will follow certain rules, allocate a red envelope amount, and then send a red envelope to the user. In our example, this rule is relatively simple, and one of 4 amounts will be randomly selected: 1, 2, 5, 10
Finally, we enabled the red envelope verification code. In order to prevent machine swiping, we have limited each user to try to enter the verification code three times. If this number is exceeded, no more attempts will be allowed.
Next, let's talk about the key points of production:
Database Design
We have added three components with a database in the background, namely the red envelope component (with its own database), the user component (with its own database), and the claim record (a private database component):
Among them, the user table records each WeChat user participating in the activity, and initiates WeChat login when the front end of the case is initialized. The role of the user table is to limit service permissions, which we have introduced in detail in the second section. Claim record, which records the information submitted by the user when applying, and three additional logical fields:
Among them, the amount represents the amount received by the user, and -1 means that it has been drawn but has not been claimed, or the claim has failed due to some reasons (such as insufficient balance in the WeChat account); whether it is drawn or not, represents whether the user has won the draw Red envelope, 1 means winning, 0 means not winning. The remaining verification codes record the number of times the current user can try the verification codes. If it is reduced to 0, he can no longer apply for a new red envelope verification code.
Finally, this application record database sets up an independent data unique index for the "submitting user" field, which restricts each openid to submit only once when submitting.
service design
In this red envelope application, we designed three services:
- Request to receive service: the first step of lottery drawing service, we will use random numbers in the background to determine whether the user has won a prize. If he wins, we will return success and the corresponding picture verification code ID and picture, and in the application record form, Submit a record with "whether selected" = 1; otherwise, return failure. At the same time, since we limit each user to submit once, even if this user applies twice, the second time will still return failure;
- Red envelope receiving service: The red envelope receiving service further includes two parts. The first part is to randomly generate a red envelope amount. In this generation method, we use an amount comparison table:
Fill in the predetermined amount in a one-dimensional array in the background, and then randomly select a value in the background to determine the sending amount of the red envelope this time.
Above, we randomly obtain a red envelope amount in the background service, and then pass it to the red envelope transaction.
In the red envelope transaction, we actually call the red envelope interface. The reason for using transactions is that we want to strictly record the real amount that each user who received the red envelope finally received in our claim record form. Therefore, we first update the claim form:
Note that this update, in addition to being a data update operation, also acts as an authentication protection. That is to say, we must require that the current user's application record already exists in the database, and the field "whether selected" is 1, otherwise, if the number of updated items is <1, it means that there is no qualified record in the database, and this person receives a red envelope , is illegal, we directly return an error.
If the first update verification is successful, then we call the red packet component to send the red packet:
But please note that because the red envelope interface may not be successfully called, for example, due to network problems, or the official account is out of money, there may be cases where the user has updated the record of the amount received, but has not actually received the red envelope. Therefore, in the case of failure to send the red envelope, we rolled back the transaction, canceled the update operation of the first step, and restored the current user's claim amount to -1.
- Verification code resend service: Finally, we have to consider that users may fill in the wrong verification code when receiving the red envelope. Therefore, we set up that the user can resend the verification code. The logic of the verification code is as follows. First, in the first step of the "request for collection" service, if the user wins the lottery, we will submit a piece of data in the application form, in which the number of remaining verification codes is set to 2 : (Because we will automatically send a verification code once after the application is successful, so if you set three attempts, the remaining number of requests is 2 by default)
In the resend verification code service, we will subtract 1 from the remaining verification code, and then return a verification code:
If the update fails, it means that there is no eligible record in the database, and the number of verification codes has exceeded 3, and an error will be returned directly. Note that the logic of subtracting one from the remaining verification codes here is the same as the logic of the lottery/reservation. We don’t need to query the records that meet the conditions first, and then subtract one, but combine the query conditions and update operations into one. To ensure data consistency and reduce service consumption. At the same time, we noticed that we did not add an index for the "remaining verification code" field, because the first two filtering conditions are sufficient to locate the precise data in the database, and the last condition of "remaining verification code > 1" is not required It is used to locate the data, but only to verify the validity of the data. Therefore, there is no need to waste additional indexing resources for it.
Finally, after the service is completed, should we automatically refresh the verification on the front end:
As above, click to receive the red envelope, if the failure reason is "the picture verification code error", then directly call the service of resending the verification code.
Demo experience
After using it throughout, I found that iVX really achieves fast learning, fast development, fast operation, and fast maintenance. It is really friendly to novices. As a developer, it is always hands-on > understanding, so everyone can try it boldly. oh.
