22

I'd like to implement a voting system on my site, without having to force them to create an account. They would ultimately be voting up/down a piece of content which has a unique ID.

  • I know that I could store entries in a table with IP/ID, but what if there are more than one user coming from the same IP?
  • Is there a way to uniquely identify visitors without it being tied to their external ip?
  • If created a GUID, store it in a cookie on that machine, could it be retrieved later on that same computer with the same IP? A different IP?

Any thoughts on these questions, or any insight to a better approach would be greatly appreciated.

Nate
  • 28,586
  • 21
  • 107
  • 177
barfoon
  • 25,436
  • 24
  • 88
  • 136
  • What's to then stop someone from voting up/down a post 50 or 100 times? – matpie Jun 10 '09 at 22:05
  • 4
    I believe that is what the OP intended the question to be: how can I prevent the same person from up/down voting multiple times. – Nate Jun 10 '09 at 22:07
  • Yes - the idea behind question is to prevent abuse, but design a system that does not require registration – barfoon Jun 10 '09 at 22:10

9 Answers9

23

Yes, you could use a cookie and set the expiration very far into the future; however, there is nothing stopping anyone from clearing their cache and voting again.

Your best bet, is to use the cookie and don't allow votes from the same IP within 15 minutes of each other... without registration thats the best you can do.

Nate
  • 28,586
  • 21
  • 107
  • 177
  • I think I will implement something like this - or a maximum amount of votes on unique peices of content per day. Thanks for your input, – barfoon Jun 11 '09 at 13:29
  • 3
    there are many users coming from the same IP (AOL for example) and most people still use IE so storing browser related info will not help. There's also a number of people that don't allow cookies to be saved (not a large amount). It sounds like the voting isn't so rigid, so I would suggest creating a random value that you store in the cookie and DB to uniquely (to the extent you can) identify someone – meade Jun 11 '09 at 20:49
  • That is simply not true; each AOL customer will have their own IP address, until they disconenct and are assigned a new IP address. It is unlikely that a user will get an AOL IP address, vote on this website, disconnect and have another user connect to AOL get that same IP address and try to vote on this site. -- as I said in my post without registration, that is the best you can do. Its not fool-proof but it will prevent extreme abuse. – Nate Jun 11 '09 at 21:32
  • 5
    The only time that many users will have the same IP address is when there is NAT involved. This is likely at a place of business, a coffee shop, or even if someone has many computers in their house. And in these situations its unlikely that two people will be on this website trying to up/down vote the same piece of content. – Nate Jun 11 '09 at 21:33
9

You could identify users based on more than just their IP. For example you could include the IP + the entire request header information (such as Browser, Version Numbers, Capabilities) and hash that. That will more or less uniquely identify your user (not 100% though, unfortunately.)

Alex
  • 71,233
  • 79
  • 245
  • 337
  • 3
    If someone were probing a way to game the system they'd probably try changing their browser string pretty quickly. – Hardwareguy Jun 22 '09 at 15:41
  • 1
    The problem with hashing everything together is you're losing data. It's reasonable to say that all of that data is probably unique, but you actually give the malicious user an advantage since as Hardwareguy points out, they can change just one item and appear to be a completely different user. Instead, I think it's better to track a few different theoretically unique items, and if /any/ of them showed up already, deny. – dimo414 Jun 29 '09 at 08:02
  • Most spoofing I've seen was only on one header: User-Agent. Most browsers send other headers as well - Accept, Accept-Language, etc. If you see several requests from the same IP with one header changing and others remaining the same (or all changing at once, possibly to strange values like `Accept-Language: x-piglatin`), you probably have a spoofer. – Piskvor left the building Jun 09 '10 at 09:14
4

It is impossible in principle for you, using a cookie, to distinguish between a visitor who has never visited and a visitor who has visited but deleted the cookie. Consequently, any cookie-based solution will be vulnerable to trivial vote fraud.

Consider embracing this reality in the spirit of J Henry Lowengard, who, when he setup the top 100 site on WFMU back in the mid-1990s, provided a button on the "your vote has been counted" page labeled "Go Back and Vote Some More!"

In fact, go there now and vote for (or against) StackOverflow!

Thomas L Holaday
  • 13,068
  • 5
  • 38
  • 50
4

You could allow them to login using OpenId, this would allow them to use an existing account to vote and they wouldnt have to create a new account.

Google and Yahoo and others have services to allow you to authenticate users.

If you dont authenticate users in some way, the voting system would me open to abuse.

Joe S
  • 41
  • 2
  • 5
    It will be open to abuse, period. The number of OpenId accounts one can have is not limited. It's actually fairly simple to become an OpenId provider yourself an generate an infinite number of OpenId accounts with very little effort. – Michael Borgwardt Jun 10 '09 at 22:19
  • 1
    You dont have to allow accounts from all OpenID providers. – Null Head Jul 24 '13 at 06:13
3

The IP + user agent is a lot more unique than IP; not sure whether it's adequate for your purposes. If you send them a cookie, it will get returned by that computer (if they're using the same browser) as long as the cookie stays around, regardless of IP, but note that the user can get rid of the cookie whenever they want.

If you're concerned at all about using this system to prevent vote fraud, I do not believe you are not going to be able to get around making them have an account.

chaos
  • 115,791
  • 31
  • 292
  • 308
2

I'm thinking the same problem right now. my possible approaches will be as follows:

  • (A) you can accept votes from those people who were in your site (using SESSIONS) for at least 15 minutes (it can be approximate time for a user to read an article in a blog/site). when they vote, the timer will reset for the next vote. so this way, there is no use deleting the cookies anymore for users.

  • (B) you can accept votes from unregistered people and taking their email address and sending them a verification link to their vote. when they click the verification link in their email box, then you can actually count the vote. it's like voting per email address.

  • (C) combination of (A) and (B). this way you can be sure you will be sending verification links only every 15 minutes to a single user which will not be a lot :)

Jon Clements
  • 124,071
  • 31
  • 219
  • 256
bijan
  • 21
  • 1
1

You could try Evercookie or similar solutions.

Jan Schejbal
  • 3,820
  • 16
  • 38
1

I know this is old, but just came here and had an idea..

What about something like https://panopticlick.eff.org ? Yet another thing one could throw in ..

(If this ever goes offline: This is a cumulative fingerprint made of the usual stuff plus + Browser Plugin Details + Time Zone + Screen Size and Color Depth + System Fonts + supercookies )

tbart
  • 91
  • 1
  • 5
0

Another option would be to use the session. It would allow you to store the session id in conjunction with the IP. That would allow you to get multiple IP but from different sessions. The only flaw to that would be the possible switching of browsers. Adding a cookie to make it a trio could help weed out flooding.

I have done this in the past with just IP address, which seem to work on small scale.

kwelch
  • 2,172
  • 20
  • 22