Error!
The page referrer is not jazz2online. Cannot vote for reviews directly - must vote by clicking on site links.

When do you get this message? When voting for reviews through either the latest reviews page or the download info page I do not get that message.

That message should occur only if the http referrer does not contain 'jazz2online' to avoid people collecting helpful votes by tricking people into clicking links. Is it possible you were clicking the link from a different site, or have reporting referrers to sites off in your browser settings?

I had never really considered people that don't broadcast a HTTP_REFERER (sic from http standard) header to the site. If anyone has an alternative that also supports preventing abuse while not needing this header, let me know.

A verification code. Include and store a randomly generated code in the URLs for the helpful links when someone views the download page, and only accept the rating if the code matches.

I didn't understand anything What do I need to do to be able to rate reviews?

Nothing. It should work properly right now. That's why there are 2 questions for you:

1. When are you getting this error? On which page are you? Do you get it for all reviews? Etc.
2. Have you changed any browser security settings / installed any plugins?

Aside from answering these questions so we can find out what the bug is, you can't do anything right now.

Link:
Do you mean storing the code in the database? Because the code would need to be unique and usable only in one instance. Such an idea would work but would be a rather large undertaking.

It made me think of the following though: generate an md5 hash or something from the username + ip and check for that...

There are some misguided firewalls (*cough*norton*cough*) which eat the referer in the name of privacy. You could try allowing requests with no referer as well as requests with the correct referer, as people who follow links from off-site will usually send referer headers.

Originally Posted by Torkell

There are some misguided firewalls (*cough*norton*cough*) which eat the referer in the name of privacy. You could try allowing requests with no referer as well as requests with the correct referer, as people who follow links from off-site will usually send referer headers.

Thanks for the bit about firewalls.

About allowing empty referrer headers - one of the things with allowing those is that we've had problems with people getting tricked on irc/instant messaging, which won't broadcast referrers.

Thinking about it, md5'ing the ip (plus some magic number) would work quite well. Include that in a hidden field (or in the generated URL), and simply check that it's correct when the user submits the page. That prevents anyone being tricked into going straight to the submitReview.php or helpful.php page. Something along the lines of

$hash = hex(md5($_SERVER['REMOTE_ADDR'] . "super-sekrit-tek"));
$url = $url . "&check=" . $hash

...

$hash = hex(md5($_SERVER['REMOTE_ADDR'] . "super-sekrit-tek"));
if ($_GET['check'] != $hash)
{
    print ("Lame vote hacker detected");
    exit();
}

should work. It doesn't matter what you append to the ip as long as your code knows to check for it - the point of that is to stop someone else writing a script to generate the links (which they could if it was an md5 of just the ip address). Hardcoding a string works fine.

It should make it impossible for someone to trick someone else into voting for a review, but it won't stop anyone who decides to simulate a bot clicking on the link lots of times (that's what IP bans are for


Oh, while I was looking I think I spotted an error in your HTML: on downloads/info.php, I couldn't see a closing FORM tag for the review form.

Oh, when you start about the HTML errors of J2O one thread is not enough I'm afraid

/me attempts to validate http://www.jazz2online.com/J2Ov2/dow...p?levelID=4549

Eeep!

(oddly enough, it didn't complain about the lack of /FORM. Yay for HTML's auto-closing of tags.)

To be honest, I think that the amount of pages on J2O that close the form tag are barely into the two digits.

Torkell, much thanks for your tips and even the prepared code . It's pretty much what I meant, and it looks good. I can't find any mention of a "hex" function in the php documentation, though. Looking at your code I'm not sure what it does, either. Is it needed when the md5 is already seeded with a secret word to avoid the possibility somebody may choose to encode things themselves? Urls should also support md5'd text properly, though it may be good to cut the string off at 8 or 16 chars or so to make urls shorter.

/me actually bothers to look at the php docs

It looks like md5() outputs a hex string, so manually converting it to hex isn't needed (I thought md5() output the raw binary). (for reference, I guessed at the name hex(), but it turns out the function is actually called bin2hex())

Truncating the hash to 8 chars shouldn't be a problem, just make sure you do the same when you compare the hash later.

I have that much experience =p
I would probably make a centralized function that can be used in different spots.