prevent spam registrations from same ip

hi, i have a script that allows users to register an acct...
http://www.onpunbb.com/install.php

but what i want is to tweak it to make it something like how vbulletin or similar forum software does with preventing users from spam posting. so that it prevents them from registering until x amount of minutes has passed since their last registration to prevent duplicate / spam accounts.

whats the best way to implement this? if someone has an example of a function for this pls help, thanks.

 

Could always hit em with a session

session_start();
$canreg = isset($_SESSION['regcheck'])?$_SESSION['regcheck']:true;

if(!$canreg)
{
// if the session value returns a false, take measures here to prevent registration
}

PHP:

Ideally what you want to do is set the session just after they register with (don't do session_start() twice in the same page in case the check above and the action below are a part of the same page):

session_start();
$_SESSION['regcheck'] = false;

PHP:

So when they come back to the registration page, and attempt to register again, the session will say no. (Sessions on most servers time out at around 15 minutes).

 

that is a great idea. moreover, you can simply .htaccess block the said IP

 

I would say only after you've verified so many attempts, but you'd also have to have a .htaccess file that was writable by the php to automate that process, and thats not exactly a safe thing to do.

 

Kblessing's method is easy to implement to prevent one spammer to sign up twice as long as he/she doesn't delete cookies.

I would suggest checking IP as well. Storing IP whenever new user signs up, if it has been used by other, simply say NO.

If my brain's till good, you can get visitor's IP by $_SERVER['REMOTE_ADDR'].

But, just to mention, 2 separate computers can be assigned the same IP (of course not the same time). Because some internet providers, outside US, assign dynamic IPs to their customers.

 

$_SESSION[] are not cookies, they're stored on the server, not on the browser. $_COOKIE is stored on the browser, but like you said someone could clear their cookies, thus why i didn't recommend a client-side approach.

Sessions typically expire on the server after about 15 minutes (most webservers are setup in that way by default), the likelyhood of two computers being assigned the same IP within a 15 minute window, visiting the same site, is slim at best.

 

Well you can always make it so that it records the ips of the people in the databese and when registring an account the person ip is checked if its not there then only it allows to register

 

Proxies ,among other things could get past a simple IP-only restriction.

 

All ways could be by passed i guess.. Cookies , Sessions anything there is no hard security as of now

 

So my basic understand about $_SESSION would be messy now .

Yep, $_SESSION and $_COOKIES are different, but http is state-less connection, and the only thing helps server recognize one client is cookies (Am I right at this point?). Which turns out that session also replies on cookies stored at client's browsers to work.

I get this idea from my log-in script (using session of course), whenever I clear my cookies, I get logged out. Which means server still stores session, however it does not match with client's side now. So I become a new visitor.
So back to raham's case, after a spammer sign up, he clears up cookies, thus, he become new visitor again, and would be able to make another account. That's why I suggest storing IP as a backup plan.

Could I be wrong at some point?

 

thats possible at the same time as well...in many institutions like libararies and others..many a time different PCs share the same internet connection..so if you are using ip restriction ...keep in mind that this can also lead you to loose a few clients..as in the case above..

 

You'd be right if all webservers and web clients were using HTTP 1.0, as of 1.1 browsers and supporting webservers can use KEEP-ALIVE. If they couldn't a lot of our login setups such as the very forum we're on now, wouldn't keep us logged in. (it behaves with a mix of sessions and cookies, often the cookie can save the session hash).

 

If you did do an IP approach, I would suggest that at the time it does the check against the database of IPs, to clear out any records older than say 15 to 30 minutes, or longer if desired. That way a week later someone gets assigned that IP (since most residents don't use static IPs), you don't want them not being able to login due to being triggered as someone who registered a week ago. Most spammers move on if they can't get back in within a few minutes.

 

How could I forget about university thing?

Very experienced thought. Discussion with you is one of the reasons I usually visit dp.