TFBW's Forum

That's a valid approach. It's mostly laziness on my part that I've left things the way they are. The fact of the matter is that most people have Javascript turned on, and the kind of people who turn it off have a tendency to turn off cookies as well, so it's not clear that the extra effort would pay off very much.

One possible approach is to set the cookie on the 403 "access denied" page, with a message to the effect that the user should try pressing their browser's "back" button and submit again. Browsers aren't guaranteed to maintain form data when you press "back" like this, so it's not exactly ideal.

Just wanted to say thanks for the description you made about using Javascript to fight forum spam. I took your idea and modified it a little and thought I'd share it. The major difference is that my method only works if registrations are required. This was already setup on my forum so I could take advantage of the email verification stuff. I think my approach might work really well because the javascript that sets the cookie isn't run just by loading the page, you have to click on the registration link. Additionally registered users don't have to keep Javascript on.


Around line 238 in templates/subSilver/overall_header.tpl modify the existing line to add the javascript.

<!-- BEGIN switch_user_logged_out -->
&nbsp;<a href="{U_REGISTER}" class="mainmenu" onClick="document.cookie = 'auth=abc123;PATH=/'"><img src="templates/subSilver/images/icon_mini_register.gif" width="12" height="13" border="0" alt="{L_REGISTER}" hspace="3" />{L_REGISTER}</a>&nbsp;
<!-- END switch_user_logged_out -->


Around line 79 includes/usercp_register.php add the following new lines.

if ($mode == 'register' && !isset($_COOKIE["auth"]))
{
message_die(GENERAL_MESSAGE, 'Javascript required to register');
}



Edit: everyone that does this should change the cookie name from "auth" to something unique so there is no one standard cookie name for spammers to submit.

So, if I understand that correctly, your forum only allows posts by registered users, and you are requiring active Javascript only at the point of registration. That seems reasonable, if the "registered users only" aspect isn't an issue. Personally I hate having to sign up when I encounter a forum as a result of a search and want to post a comment on it -- that's why I allow guest posting here.

Depends on the purpose of the forum, if it's mostly used as a comment/feedback system I'd agree about hating to sign up. The forum I admin is more a community discussion/newsgroup replacement type system where most users visit over and over again. For that type of forum registration is not such a big deal (helps keep the coversations straight) and it lets us use capchas (phpbbs could be better) and email verfication. Email verification all by itself (before I started banning the spammer domains) was stopping about half the spammers. So far adding this artifical Javascript requirement seems to be stopping the rest of the spammers.

Great idea using both javascript and a cookie. Real Genious!

I will probably use this as soon as I can figure out how to let the google bot past (indexing good, spam bad).

Use the cookie only to prevent POST operations. Any sensibly-programmed web service will use POST for submitting comments and other "make an alteration" operations, and GET for reading the site. The Googlebot and other spiders have no business whatsoever issuing POST commands.

(since you left guest posting on, I thought I'd take advantage of it

I've been working on a narrow focus spider for a municipality and found that submitting POSTs was essential to getting at half the pages they wanted to index. Sites like indeed.com are using it heavily (I know because I've written spiders to mine some of the same sites they are mining and there is no other way to get at the data they've got) and I heard that google has a large project to do more data gathering that requires the spider to interpret javascript and perform forms submission. Just thought I'd point that out since your comment sounded very absolutist.

Thanks for posting your little adventure and the useful IPs to ban. I cleaned up a forum recently and am now guarding it and was looking for advice on how to do so. As Mad-Eye Moody says: Constant Vigilance!!

My comment was that any sensibly-programmed site would not require POST operations for simple reading. I concede that there are a large number of websites which are not sensibly programmed. This is easily demonstrated in a slightly different way: any site that requires a particular make of browser (usually Internet Explorer) is designed contrary to the general principles of the web.

Writing a web-spider which included the ability to perform POST operations would pose a difficulty in that you'd have to be careful not to perform any such operations which make unwanted changes to the site content. Such abuse would get your user-agent or IP address banned pretty rapidly! The only safe way I can think of enabling POST operations in a spider would be to do it on a special case basis.

Would it work to simply set the form target (action attribute) via javascript? That way a bot wouldn't know where to post to, while regular browser viewers would be able to post.

I'm not sure whether that would have the desired effect. I'm pretty sure that a lot of the automated forum spamware knows the correct URL for submitting posts simply because phpBB is widely used. This would apply to pretty much any widely used forum software: if you know the base URL of the forum, you probably know the URL for posting.

On the other hand, if you changed the URL for posting, you'd probably disable a lot of automated attempts even without using Javascript. I'd investigate that, but I've killed the spam problem in this forum so effectively with existing measures that I have no motivation to try it out. If someone else wants to give it a try, though, let us know how it goes.

Right. I was actually thinking about it as a general technique - for known forum software it would probably be ineffective.