http://qs321.pair.com?node_id=208227

carthag has asked for the wisdom of the Perl Monks concerning the following question:

I run a little script on my server where people can moderate a link (basically up & downvotes). This is run in a CGI::Application I wrote myself, but I'm having a bit of troubles finding a better way to prevent the users from voting multiple times (I don't need top security or anything, I just don't want easy ballotstuffing).

So far, my code looks like this:

sub link_moderate
{
    my $self = shift;
    
    my $q = $self->query();
    my $output = "";
    my $tmpl = $self->load_tmpl('.tmpl');
    
    my $uri = $q->param('uri')||"";
    my $direction = $q->param('direction')||"";
    
    #FIX!! (check for existence of URL)
    
    my $statementHandle = $Database->prepare("SELECT COUNT(*) FROM mod
+eration WHERE userkey LIKE '".$q->remote_addr."-$uri';");
    my $returnValue = $statementHandle->execute;
    
    my @results = $statementHandle->fetchrow_array;
    
    if ($results[0] >= 1)
    {
        $tmpl->param('message' => "Ahem, you've alredy voted at this. 
+Stop doing it, you won't get any further.");
    }
    else
    {
        if ($direction eq "up")
        {
            my $returnValueStatus = $Database->do("UPDATE saved_search
+ SET moderation=moderation+1 WHERE uri LIKE '$uri';");
            $returnValueStatus = $Database->do("INSERT INTO moderation
+ VALUES('".$q->remote_addr."-$uri');");
            
            if ($returnValueStatus == 1)
            {
                $tmpl->param('message' => "The moderation value for th
+e url has been updated.");
            }
            else
            {
                $tmpl->param('message' => "The URL could not be found 
+in the database.");
            }
        }
        elsif ($direction eq "down")
        {
            my $returnValueStatus = $Database->do("UPDATE saved_search
+ SET moderation=moderation-1 WHERE uri LIKE '$uri';");
            $returnValueStatus = $Database->do("INSERT INTO moderation
+ VALUES('".$q->remote_addr."-$uri');");
        
            if ($returnValueStatus == 1)
            {
                $tmpl->param('message' => "The moderation value for th
+e url has been updated.");
            }
            else
            {
                $tmpl->param('message' => "The URL could not be found 
+in the database.");
            }
            
            $Database->do("DELETE FROM saved_search WHERE moderation <
+= -15;");
        }
        else
        {
            $tmpl->param('message' => "Eh, what direction would '$dire
+ction' be?");
        }
    }
    
    $tmpl->param('version' => $VERSION);
    $tmpl->param('number_of_links' => &get_number_of_links);
    $tmpl->param('list_urls' => &getlast(10));
    
    $output = clean_html($tmpl->output);
    
    $self->header_props(-Content_length=>length($output));
    return $output;
}

[download]

As you can see, there goes an awful lot of data into the moderation table, and it's generally not very pretty.

Any thoughts on this?

Edit kudra, 2002-10-27 Added a readmore tag

Replies are listed 'Best First'.
Re: Preventing multiple votes by same user effeciently
by BrowserUk (Patriarch) on Oct 26, 2002 at 13:41 UTC

    You appear to be trying to use the REMOTE_ADDR from the browser to determine whether someone has voted or not. There are (at least) two problems with this.

    First, a single (external) IP is often shared by many users. In companies or student dorms and the like, using NAT to allow multiple internally networked machines to access the internet via a single connection or corporate firewall etc. This means that only the first user to vote from within such an IP sharing group would be permitted to vote.

    The second is that many home users still use dial-up connections and get allocated a different IP (via DHCP) each time they connect. I am one such user. In order for me to vote many times under your current scheme, I simply have to dis- and re-connect and click the vote button again. There is very little you can do to stop this using the IP alone.

    Almost any scheme will require you to use a userid/password and/or a cookie to validate the voter. The former is non-trivial to implement though a search on merlyn's web-site will turn up several hits for schemes of varying complexity. The latter will fall down if your users are the paranoid types (like me) that habitually run with cookies disabled except on sites I have some modicum of trust in.

    Cor! Like yer ring! ... HALO dammit! ... 'Ave it yer way! Hal-lo, Mister la-de-da. ... Like yer ring!
[reply]

      I've also heard that WebTV users may also be on different IP addresses per each request. That means that a single session may actually be on many different IP addresses. This is just hearsay but it's something to consider.

      __SIG__
use B;
printf "You are here %08x\n", unpack "L!", unpack "P4", pack
  "L!", B::svref_2object(sub{})->OUTSIDE;

      [download]
[reply]
[d/l]
      Also, remember that there is nothing to say that AOL members will even have the same IP during a browser session. IP rotation with AOL members is an issue to remember.
      from the frivolous to the serious
[reply]

        I'm surprised by this. I've never used AOL but I know my sister has an account and regularly uses both AIM and more significantly MSN Messenger. If her IP is constantly changing, I'm wondering how these comms protocols manage?

        Cor! Like yer ring! ... HALO dammit! ... 'Ave it yer way! Hal-lo, Mister la-de-da. ... Like yer ring!
[reply]
[d/l]

      Thanks, I forgot to take into account networks. And since I actually have a lot of users coming from school networks, I can't use my current approach.

      usernames & passwords aren't a viable option, mostly because it would add an unnecessary layer of complexity and generally be overkill for the problem.

      I never really liked cookies, they're too easy to circumvent (and should be), which comes from having tried using them before when writing a crap Hotornot clone.

      I guess these are the only solutions, though, so I'll see which one will be the best.

[reply]
Re: Preventing multiple votes by same user effeciently
by samtregar (Abbot) on Oct 26, 2002 at 19:40 UTC
    The problem here is basically that identifying a unique individual over the web is not easy. Your best bet is to use an email-based authentication scheme, since most users only have one or two email addresses and don't share them with anyone else. Here's a rough sketch of a scheme I've seen used to good effect:

    1. Ask the user for their email address, which will be their username.
    2. Generate an MD5 hash of their email address and a secret key.
    3. Email this MD5 to the user with instructions to return to the website and enter the code into a text box along with their email address.
    4. Now, when you recieve an email address and code pair you re-MD5 the email address with the secret key. If they match then the user must have recieved the email.
    5. Check the already-voted table. If not found, allow them to vote.
    6. Record their email address in the already-voted table.

    Of course, this system is not perfectly secure. A suitably motivated person with control of a domain name could write a script to automate the process of generating valid email address and key pairs. However, it is definitely safe against your average jerk with an LWP script. And it's really not very hard to code. I'd estimate it at around 20-30 lines of code, using all the best that CPAN has to offer.

    If you're into security through obscurity, one thing you can do to make script writing much harder is to randomize your form. Just mix up the names of the form parameters and the values that represent to answers. If a script writer has to actually parse the form HTML to figure out what results to send back to the server, they might not bother. Or, they might become inspired and spend all night writing an elaborate hack to show off to their friends. You never know!

    -sam

[reply]
Re: Preventing multiple votes by same user effeciently
by George_Sherston (Vicar) on Oct 26, 2002 at 17:23 UTC
    If you just want a system that will stop most ballot-stuffers most of the time, you could put a hidden field in the form that has some encrypted goop in it which your script checks to see whether to accept the vote or not. Then when users call the script the first time, send encrypted goop that means "yes", but when the form is submitted, send it back with encrypted goop = "no". It won't stop anyone who just reloads the form by re-entering the URL, but if you don't make it obvious that their second and subsequent votes are being ignored, then most of them will never realise that they have to do this to rig the vote. Not secure, but for a non-critical situation it's simple and fixes most of the problem.

    § George Sherston
[reply]

Back to Seekers of Perl Wisdom