1. IP restrictions
This is the most commonly used, most widespread, and indispensable ticket-swiping restriction. And since the topics do not have user modules, this method has almost become the only feasible method. This method limits the number of tickets that visitors can use within a period of time by obtaining their IP addresses. Of course, visitors who normally visit the page to vote will definitely be restricted by this method. However, various voting activities and special topics, as well as generous prizes, make some people try every means to swipe their votes.
ADSL users can change their IP address by disconnecting and redialing.
For users who use proxy access, we cannot obtain their real IP addresses.
There are also vote brushing tools that we don’t know about.
The above are all problems that we have no way to overcome, and for Internet cafe/intranet users, such a setting will also seem unfair.
2. Cookies Verification
This is also a method commonly used on the Internet. However, all information and content from the client are unreliable. People who are familiar with the principles of cookies can easily bypass restrictions.
Cookies can be disabled.
For users who use proxy access, we cannot obtain their real IP addresses.
Cookies can be cleared and modified at will.
3. Session verification
The session will assign a unique sessionID to all visitors. This seems to have some effect on preventing ticket fraud. Unfortunately, session has fatal shortcomings.
Close the browser and the session will be destroyed.
If the client disables cookies, the session will also become invalid.
4. Verification code
Register, log in, reply, post... Verification codes are used in a wide range of applications. Unfortunately, as for the specific effect, over time, it was found that this method only made it more difficult for ordinary tourists to vote, and the frequent access to verification codes for swiping votes also greatly increased the burden on the server.
There is a kind of verification code that is feasible. The graphical verification code launched by Google is designed to allow users to flip the picture to the correct direction to complete the verification. There must be very few software or computer operations that can bypass such a verification code very well. However, the disadvantage is that it is very difficult to implement.
5. MAC address restrictions
As a web program, it is difficult to obtain the real Mac address (I experimented with php/js and did not successfully obtain the Mac address). When we read the client's Mac address, we also read information stored in the registry, which can also be modified.
6. User modules
This should be considered a very useful method. Each visitor must register an account to vote. Voting can be restricted by limiting the account ID, and the initial registered user can be restricted from participating in voting for a period of time. Moreover, if there is a large influx of registered users, it can also increase the traffic of the website. However, for websites in small areas, this will make netizens find it very troublesome and may give up voting, thereby possibly losing users of the website.
7. Behavior records
Actually, we cannot restrict many ticket fraud behaviors. But sometimes, we can record it very well. And when abnormal voting is detected, the number of votes will be automatically raised, or the illusion of successful voting will be returned, which can also effectively limit vote manipulation.
The disadvantage is that recording too much data will put a lot of pressure on the server. Moreover, if there are not enough recording points to record the behavior and it is not complex enough, it may also be penetrated by professional users who use ticket fraud.
8. Answer questions
The first time we used this method to limit ticket fraud, we were pleased to see good results. Unfortunately, if there is not a large enough question bank, the content and answers of the questions will soon be collected. On the contrary, users who normally vote will find voting disgusting, troublesome, and disgusted. Gradually we were abandoned.
9. Random voting address
This method allows each user who visits the page to get a random and unique KEY. Through this KEY, a voting address is generated. This address can only be accessed once and will be invalid after use.
Unfortunately, for the content of the specified KEY, I currently use the MD5 code generated by sessionid ip random number, and sessionid and ip are mentioned in the above content and can be destroyed and tampered with. This method is nothing more than a desperate struggle when IP restrictions and session restrictions are invalid.
10. Fill in the information
When voting, visitors are asked to fill in information such as ID card, name, mobile phone number, etc. that can indicate a person's identity for uniqueness verification. However, if you know the format of your ID card, you can fill in your name and mobile phone number as you like, and there is no way to limit it. On the contrary, it makes people who vote normally feel troublesome.
11. Voting Code/Ranking System
Before voting, users need to obtain a unique voting code/volume from other pages/emails, which will be invalidated once used. However, how to verify the uniqueness of a 'person'? If there is a user with enough mailboxes, can he get unlimited voting codes?
Yes! Therefore, this is only a temporary solution rather than a permanent solution. However, at least this method will make ticket swiping people feel troublesome. But at the same time, it will also make people who vote normally feel inconvenient. However, it can be considered useful if it can make the vote-swiping party not so happy.
12. RMB voting
Tiger, this is the best. Whether it’s sending text messages, making phone calls, or using Alipay, each vote is one yuan. If you are willing enough, of course, you can vote and swipe as you please, and we are happy not to. Through the combination of payment interfaces, cheating is quite difficult.
However, fairness needs to be considered. After all, not all supporters have money and are willing to spend money. Good works may not get votes because they are 'poor'. This is in our fair and democratic society. , is not recommended!
Okay, that’s pretty much the above methods. To quote a netizen’s original text: “To completely put an end to ticket fraud, we basically have to rely on people.”
To attract good ideas:
Flash voting, but I don’t know the principle very well. I will put it into testing when I have time.
plugin. Web plug-ins may require users to download and install them, which may be troublesome for ordinary users, and the feasibility remains to be studied.
Some interesting settings include, for example, multiple votes in a short period of time, which may lead to a decrease in the number of votes; negative votes can be given to works, but there is a certain chance that they will be invalid or reflected to other works; similar to 'stealing vegetables' on the farm, we can vote, etc. . Maybe it can add a little more playability, but fairness cannot be guaranteed.
Summary: Personally, I feel that the most effective method at present is RMB voting, which can effectively limit vote fraud.