gogoWebsite

preamble

In this article, we will show you low-code development: by using the user component authentication to avoid non-WeChat users to obtain the red packets, and the use of services and transactions to record the record of the user to claim the red packets; users eligible to obtain the red packets, then through the backend logic to send the amount of money generated in the background to my WeChat.

summarize

iVX is a "zero code" visual programming language, with a convenient online integrated development environment , do not need to download the development environment , open the browser can be anytime, anywhere to edit the project .

Today, we're going to talk specifically about the practice of WeChat Red Envelope apps. The most common problem that will occur when we make red envelope apps is:

1. Brushed
2. Excessive concurrency and incurring excessive costs

Let's first specifically analyze the causes of these two problems, and then through a demo case, to give a relatively reasonable solution.

---

The principle and solution of red packet anti-swipe

First, being brushed. By the wool party malicious brush red packets, there are mainly two ways, the first is to crack the front-end encryption request, set a fixed WeChat openid, send a request for red packets to our server, directly send the red packets to the intended openid. the second is to send the address of the red packets to the special "wool group", and then The second is to send the red packet address to a special "wool group", and then the red packet will be manually claimed by the real wool users. Please note that if we don't set any rules for red packet collection, such as the need to redeem the red packet through a pre-issued coupon code, any valid WeChat user can collect the red packet, then the second type of real user "wool group" is not preventable, we can only do a good job of keeping it secret during the activity and appropriately limiting the concurrency and speed of the red packet collection by the wool party. The speed of the wool party to receive red packets, leaving us the event to respond. (Note that simply disabling forwarding in WeChat does not prevent the wool party from sending out the red packet link, because there are many ways to get the address of an H5, such as directly copying the URL.)

Therefore, for the second type of real user wool group, we strongly recommend that when designing the red packet activity, certain thresholds should be set, for example, the user must first pay attention to the public number, and receive a red packet password in the backstage of the public number, and then, through this password, he can redeem the real red packet. In this way, even real users must first pay attention to the public number. Or, pre-set a list of users who can receive red packets, and verify whether they are in this whitelist when they receive them.

Next, let's focus on analyzing how to prevent the first type of red packet brushing. Compared to the second type of real users, the first type is more harmful, because the person who brushes red envelopes can pre-apply for a batch of zombie numbers, and directly through the background service to batch brush red envelopes into these zombie numbers. This kind of batch brush, may be in an instant thousands of tens of thousands of dollars of red packets brushed away. Comparatively speaking, the second real wool group brush method, it is unlikely to appear instantly in a few seconds to brush all the red packets, because the real users must still complete our front-end display process, to the last step to receive the red packets. Although they are not the "target users" of our clients, they are still human users, not machines.

Preventing the first method of machine brushing is mainly a way to set up a line of defense for our service:

Line of defense 1: Front-end request encryption

​
The front-end of ivx's system, automatically encrypts the requested information, and we can see the specific request information in network, and in the case preview, we can see the plain code of the request, for example:

​

The same request, when published, is encrypted data:

​

Therefore, under normal circumstances, it is not possible to get the real request data and simulate sending a request by looking at the published H5. However, please note that the front-end encryption, since it is done on the client side using js, it is still theoretically possible for an expert to crack it and get the original information of the request. Therefore, we can't rely on front-end encryption and must build more lines of defense in the service backend.

PS: iVX platform is developing an upgraded version of front-end encryption method, by then, the request encryption part will use web assembly instead of pure js, and the difficulty of cracking front-end encryption will be increased exponentially. But even so, we still can't trust the client-side encryption completely.

Line of Defense 2: Setting Service Invocation Privileges

​
Any service that does not require authentication is dangerous. Usually, we need users to be logged in to an account before they have permission to invoke a service. For example, if we look at the list of works in the ivx workbench, it is impossible to allow a user who is not logged in, to look at the works of any other user. The same is true when we make our own services, we must ask for user permissions at the service level.

In our Red Packet scenario, we have set up three services that must be invoked after the user has logged in as a "normal user", otherwise, it will return no permission:

​

Also, the user is initializing and needs to initiate a microsoft login on the front end:

​

The process of logging in is actually a token that will be returned by the ivx backend and stored in a cookie in the user's browser on the mobile side. When the user invokes any service on the client side, it will automatically send this token to the backend service (this process is done automatically, we don't need to do it manually), so if you haven't logged in to the user component to get a legitimate token, you don't have the authority to invoke the service. In addition, due to the initiation of WeChat login, the need to cooperate in the WeChat client and background with the invocation of a series of authentication processes, there is no legitimate WeChat account and initiated in the WeChat client, basically it is impossible to log in successfully, therefore, in this step, we have effectively set up a second line of defense, so that the machine brushed the request for the service can not be passed through the authentication successfully.

In addition, to set permissions for a service, it is a prerequisite that there must be a physical service. Therefore, in the Red Packet application, please strictly use the backend service to send red packets instead of directly calling the Red Packet component in the front-end and relying on the system-generated automated service.

Line of Defense 3: Avoid exposing core parameters as much as possible

Although the second layer of defense above is basically enough to prevent the machine from brushing. But we still try to set up another third line of defense just in case. For example, a wool party, can crack the front-end service encryption, and use automated N mobile devices, automatically brush red envelopes. Each cell phone device, all logged into a real WeChat account, or all have a valid cell phone number that can automatically recognize the verification code and register.

​

For example, a collection of equipment like the one above. Although it would be costly to hire such a specialized "equipment farm", if the benefits are sufficient, someone will do it. In this case, we need to further protect our services. One of the simplest principles of service protection is to try to put all the logic in the background, not to use the front-end parameters. For example, our red packet service, there are two important parameters, the amount of the red packet, and the target openid to send the red packet, if these two parameters, we let the front-end in the call to the service to send, then once the service is cracked, the wool party can call the "device farm", with any number to log in, and then specify the amount (which can be the amount of money we allow), and then specify the amount of money (which can be the amount of money we allow), and then specify the amount of money, and then specify the amount of money, and then specify the amount of money. Then specify the amount of money (can be the maximum amount we allow), as well as the target user, and soon you can brush all the red packets to the specified account.

But if, we receive red packet service, do not expose any parameters, whether the user can receive red packets, how much to receive, are in the background logic to determine, then even if the wool party to open the brush, but also can not specify the account number and the amount of money, greatly reduces the profit of brushing red packets, and improve the difficulty:

​

Line of Defense 4: Using AI to Validate Behavior

We can also additionally use AI verification to determine whether a certain behavior is a human operation or a robot operation. At present, Ali Cloud, Tencent Cloud have similar verification methods, it is recommended for sensitive applications, add a similar verification, which not only prevents robots from invoking the service to brush red envelopes, but also allows the wool party "deterred", give up brushing the service, to reduce our costs.

---

​

Reduced consumption of highly concurrent services

Next, let's address the second problem, that is, if we minimize the server pressure when grabbing red envelopes, in order to improve the efficiency of service response and reduce the service cost. In the red packet application, one of the biggest consumptions, that is, using the database to determine a user can only receive a red packet once, or need to meet certain conditions before they can meet the red packet.

First, we can limit the number of claims per person in the Red Packet component, usually, only one per person:

​

If our application is to receive red packets directly, then in addition to limiting the frequency of red packet collection service calls (through the high concurrency limit, the default is 100, you can manually contact customer service to adjust down), there is no other place to optimize. But the usual activity rules, we may limit the probability of the user to receive the red packet, for example, each person can only apply to receive once, there is a certain probability that you can receive the red packet, there is also a certain probability that you do not win the lottery. But no matter whether you win or not, you can't apply for the lucky draw again.

Therefore, we will make another application log table on top of the Red Packet component, and this application log table will have a submission limit that directly uses the separate unique index of the submitting user:

​

In this way, it is possible to restrict each user to submit only one record like in this table. If, however, we want to further restrict each user to only one pickup per day, we can also add an additional date field and a data-unique union index.

​

Above, we have implemented the method of limiting users to submit only one application in total, or one application per day, per day, by means of independent unique indexes. This method is much more efficient compared to the restriction in the database's submission restriction panel:

​

The per-person commit limit filled out in the commit limit panel above is achieved internally by iVX through database transactions, which consume more database service time relative to normal services because they lock records.

Therefore, if our restriction is that each person can only submit one application per person in total or per person per day, then it is highly recommended to use a data unique index, or a data unique union index. At the same time, try to avoid using methods such as data output/statistics to count the number of user applications, and then return whether the user can apply for red envelopes again based on the statistics. This method, in addition to additional consumption, may also cause data inconsistency at high concurrency, giving the wool party an opportunity to take advantage of.

In addition to optimizing the method of limiting the number of times a user can apply for a raffle as much as possible, red packet applications are prone to the misconception that some users, depending on the amount of the red packet, will each create a red packet component, or a database of application records. Note that the red packet component, itself, comes with a database record. And creating multiple databases in one case will consume extra resources and is not well managed. Therefore, we can use the backend logic to dynamically generate the red packet amounts without creating a red packet component for each red packet amount.

---

Simple Example of Red Packet Implementation

Based on the above principles, let's make a simple red envelope example.

First of all, we introduce the rules of the game in this red envelope example, you can understand the implementation method, according to their actual needs, to adjust the rules:

1. Each user can only apply to receive the red packet once, and when applying, by the way, provide information such as name and cell phone;
2. After each user applies, there is a certain probability that he or she will win and a certain probability that he or she will not win. If the prize is not won, there is no further opportunity to apply again;
3. If a user wins a prize, the backend will rule a certain amount, assign a red packet amount, and then send the red packet like the user. In our example, this rule is relatively simple, it will randomly pick one of 4 amounts: 1, 2, 5, 10

Finally, we turned on Red Packet CAPTCHA. In order to prevent machine swiping, we limited each user's attempts to enter the CAPTCHA to only three times, and if they exceeded that number, they couldn't try again.

Next, let's talk about the highlights of the production:

---

database design

The backend components with database, we have added a total of three, they are the red envelope component (with its own database), the user component (with its own database), claim records (a private database component):

Among them, the user table, which records each participating WeChat user, initiates the WeChat login during the initialization of the front-end of the case. The role of the user table is to restrict service permissions, which we have described in detail in Section II. The claim record, which records the information submitted by the user during the application, as well as three additional logical fields:

​

Among them, the amount represents the amount received by this user, -1 means that it has been drawn but not yet claimed, or failed to be claimed due to some reasons (e.g., insufficient balance in the WeChat account); whether it is drawn represents whether this user has drawn the red packet or not, 1 means that it is drawn, and 0 means that it is not drawn. Remaining CAPTCHA, records the remaining number of times the current user can try the CAPTCHA, if it is reduced to 0, he cannot apply for a new red packet CAPTCHA.

Finally, this application record database, for the "submit user" field, set up a separate data unique index, in the submission of each openid can only be limited to submit once.

---

Service Design

There are three services we have designed in this Red Packet app:

1. Request for collection service: that is, the first step of the lottery service, we will use the random number method in the background to determine whether the user has won the lottery, if he/she has won the lottery, we will return success and the corresponding picture verification code ID and picture, and submit a record of "whether he/she has won the lottery" = 1 in the application record table; on the contrary, we will return failure. At the same time, since we limit each user to one submission, even if the user applies twice, the second time will still return a failure;

---

2. Claiming Red Packet Service: The Claiming Red Packet Service, further consists of two parts, the first part, is to randomly generate a red packet amount. For this generation method, we use an amount comparison table:

Take the predetermined amount, fill it in a one-dimensional array in the backend, and then randomly draw a value through the backend to determine the amount of this red packet to be sent.

​

Above, we get a random bonus amount in the backend service and pass it to the bonus transaction.

In the Red Packet transaction, we actually go ahead and call the Red Packet interface. The reason for using a transaction is that we want to keep a strict record in our claim record table of the real amount that each user who receives a red packet ends up receiving. So, let's start by updating the claim table:

​

Note that this update, in addition to being a data update operation, also serves as a forensic protection. That is, we must require that in the database, there has been the current user's application record, and the field "whether the lottery" is 1, otherwise, if the number of updates <1, that is, there is no record in the database that meets the conditions of the red packet, it is illegal to receive the red packet, we directly return the error.

If the first step of the update validation is successful, then we call the Red Packet component to send the red packet:

​

However, please note that since the red packet interface may not always be called successfully, for example, due to network problems, or the public number is out of money, there may be a situation where the user has already updated the record of the amount received, but actually did not receive the red packet. Therefore, we do a transaction rollback in the event that sending the red packet fails, canceling out the first step of the update operation, so that the current user's collection amount, back to -1.

---

3. Retransmit CAPTCHA Service: Finally, we have to consider the situation that users may fill in the wrong CAPTCHA when they receive the red packets. Therefore, we set up the user can re-send the verification code. The logic of CAPTCHA is like this, firstly, in the first step of the "request to collect" service, if the user wins the lottery, we will submit a piece of data in the claim form, in which we set the number of remaining CAPTCHA times to be 2: (Since we will automatically send a CAPTCHA once the application is successful, if we set up three attempts, the number of remaining requests will be 2 by default. the number of remaining requests will be 2 by default)

​

In the Retransmit CAPTCHA service, we subtract 1 from this remaining CAPTCHA and return a CAPTCHA:

​

If the update fails, it means that there is no record in the database that meets the condition, which means that the number of CAPTCHA has exceeded 3 times, so it will directly return to report an error. Note that the logic of decreasing the remaining validation code by one is the same as the logic of lottery/reservation. Instead of querying for eligible records and then decreasing them by one, we combine the query condition and update operation into one to ensure data consistency and reduce service consumption. At the same time, we note that we did not add an index for the "remaining authentication code" field, because the first two filtering conditions, enough to locate the exact data in the database, the last "remaining authentication code >1" condition, do not need to be used to locate the data, but only used to verify the validity of the data. Therefore, there is no need to waste additional indexing resources for it.

Finally, once the services are all done, do we auto-refresh the validation on the front-end:

​

As above, when clicking on the red packet, if the reason for failure is "Wrong Image Captcha", it will directly call the resend Captcha service.

Demo Tips

The whole use down , I found that iVX really do fast learning, fast development, fast running, fast maintenance, really friendly to novices, as the developer's point of view, always hands & gt; understanding, so that we can boldly try Oh.

---