With the respect due all persons on our planet, how about a LINK to where we can see this functioning? How about letting us know what VERSION you hacked to create this? Is there any reason you didn't use hacks.php instead of hacking core files? Have you tested it in multiple browsers and in all possible combinations of users and potential commenters? In your maillist.php file you say there is no need to change anything beyond line 8 yet line 123 says "Thanks for registering with The Travellers Portal." Wouldn't I want to change that, and shouldn't it automagically grab something from the database and link it back to the url the person signed up for? At the very least one would expect generic text instead of something that (near as I can figure) references a specific site out there in the wild wild web.

Please. Your method might be very strong but without amplifying information it isn't a credible solution. No one likes spam, but I'd rather see spam than try a hack that clearly hasn't been thought out too well and might not be compatible with my installation. Not that I get ANY comment spam. It's just that I'd feel bad if someone hosed their installation by following advice that sounds good but isn't right for them.

Thanks for the comments Edb, I'll try to address them with clarity.

how about a LINK to where we can see this functioning?

The site I have done this on is still in Beta and not all running as I would like but will be soon, I'll post a link then. I think it is important to get the protection in place very early rather than try to fix it later.

Version is 0.9.0.12

Is there any reason you didn't use hacks.php instead of hacking core files?

You're probably right and I should have used hacks.php. If you would like to move the code across I would be quite happy to see your work and use it. I hacked the core files because I really didn't know any better. I made the changes where I thought they needed to be made.

Have you tested it in multiple browsers and in all possible combinations of users and potential commenters?

I have tested it in several versions of IE, Mozilla and Opera. I don't have access to Safari. As with any software there will always be some odd combination where there is a potential for failure. I think that this is pretty secure because the code which generates the protection is accessed by the displayed page but not embedded in it. I would suggest that this stipulation is a little unreasonable, if all programmers did this nothing would ever be released, not even stuff from Microsoft. Why are there upgrades?

In your maillist.php file you say there is no need to change anything beyond line 8 yet line 123 says "Thanks for registering with The Travellers Portal." Wouldn't I want to change that, and shouldn't it automagically grab something from the database and link it back to the url the person signed up for? At the very least one would expect generic text instead of something that (near as I can figure) references a specific site out there in the wild wild web.

Very true, I did mean to cut that out. However, unless you call that particular partial directly you will never get to that section because the $email variable will always contain an email address as tested and confirmed by the earlier code in register.php.

Please. Your method might be very strong but without amplifying information it isn't a credible solution. No one likes spam, but I'd rather see spam than try a hack that clearly hasn't been thought out too well and might not be compatible with my installation. Not that I get ANY comment spam. It's just that I'd feel bad if someone hosed their installation by following advice that sounds good but isn't right for them.

And I agree. As with any code snippets posted anywhere all users should test first on a backup site/file. Standard rules and caveats apply.

I don't accept that this hasn't been thought out too well. I have spent many hours/days working on getting this right and I think I have.

There will always be people with differing opinions which is fine by me. There are many people who have better coding skills than mine but I think this is a credible solution that can be turned on or off and tested as suits the individual.

Please accept this as an attempt to help those who are relative newbies to protecting their sites in a secure manner. Anyone who wishes to improve this code is welcome to do so, all suggestions which make it work better will be implemented on my site as well.

Thanks for your comments Edb, I hope that my response has helped you and others.

Cool. So to cut to the chase: hacks.php is a file that CAN exist in the conf folder but doesn't by default. That way upgrading will never write over your hacks file. Sometimes hacks really need to address the core, and I've done lots that way, but I think technically everything can be done by tweaking then renaming a core funtion in hacks.php. b2evolution will read and honor it if it exists is the thing. I just re-did my most favorite hack and - again - told people to tweak a core file. I probably shouldn't have done that but sometimes I'm too damned lazy to do the bestest thing. Such is life eh?

No offense okay? It's just that when someone comes along and says "here is a shiny new answer to spam" those of us who have seen this ship wreck against reality roll our eyes and hope it's not as bad as most...

Oh hey and upgrade to either dawn or sparkle. 0.9.1 and 0.9.2 respectively. WAY better at a handful of stuff, with the single biggest being saving tons of labor for your server when the antispam system catches a spammer. Briefly: the old way was to wait until a page load to detect then not log. The new way is to detect and reject on initialization. Cool eh?

Fair 'nough, so if I copy the function I want to change to the hacks.php file and modify that one b2evolution will replace the function in the core file with the one in the hacks.php?

I might be a little confused about this but I would have expected the code to throw an exception if it has two functions with the same name. Surely it would at least cause erratic and unpredictable operation?

If you change the name of the function in the hacks.php file then you would have to change the call to the function in every location you wanted it or if you didn't change the function name, you would have to rename or comment out the original function. Is that how it works? Wouldn't an upgrade cause the self same problems you get with hacking the core files in the first place?

Seems to me that most spam solutions are implemented backwards. They almost all try to block the bad guys which is pointless because the bad guys can easily change email, ip, host and have another go.

Much better solution implemented by www.bluebottle.com (no relation ot financial link) and possibly others is to only allow white hat users. They challenge every email sent to them, only those who respond can get through. You can manually authorise email addresses and email addresses you send to are automaticall authorised. Works brilliantly, no spam there either.

That is the approach I have taken with this hack, always use a challenge/response to prevent auto logging.

I have to confess that I have only been online helping people with spam filtering and PC protection since 1989 and I am a self taught programmer so I don't have all the answers (who does?) but some things seem obvious.

I am using the version above becaus that is what the host had loaded in their installable software file. I'll give the most recent a try, 0.9.2 sparkle, nice names for the versions makes a difference from just numbers.

Cheers.

You will need to give the new func a new name and call it by it's new name wherever you need it. For example if b2evolution has a function "whatever()" you should call yours "whatever_myantispamhack()" or something like that. In theory your hack will not need to replace every instance of any given function call, though that depends on how deeply your hack affects core files. One of the WORST places to hack is the blogger profile because there are two distinct ways to access that information, but I digress...

Whitelists have been done, but then again it'll cut your commenting audience. With b2evolution as-is, registering does NOT automagically give any permissions and there is no comment moderation based on registration. Thus the blog owner has to decide what permissions each registered user will get. I've gotten a grand total of one spammer registering for a blog I admin'd, so I guess it's not a widespread problem. Comment spam, on the other hand, is rampant. As is trackback and (of course) referer spam.

I always use an auto-installer to build me a new database, but - since I'm sort of hip to this software - know not to trust it to install the latest release. I think only the really big names in open source get updated rapidly by the auto-installers, but I could be wrong. Anyway my method is to let Fantastico build me a database then I delete all the files and drop all the tables then do a fresh install of whatever version I'm playing with. I carry that method over to any other software I want to play with since I just don't trust the auto-installers to give me the latest-and-greatest.

Sorry for going way off topic, but that's the way it is with me at this time of night ;) And yeah it's cool that the software has names eh? Sparkle is like shiny and groovy and new. Phoenix is an over-cooked bird that'll probably fly off your dinner table as you sit down to enjoy it... :roll: Anyway I think the second paragraph addresses your initial issue though. There is simply no way anyone who registers will post without the blog owner authorizing that person to post. Oh and 1.8 seems to have a "you must click the link we send you in email" type of thing to validate registration. Kinda sucked to upgrade a test installation and have it question me!

OK, I'll give that a try. At least it would be a lot easier to do a search & replace for the function name in all the relevant files than re-install all the code snippets.

The concept behind my site is that outsiders will be able to build their own blogs, add comments set up groups etc. I don't want to have to do all that in my "spare" time.

The other way is to have the whitelist growing and have overriding delete capability. So my next hack is to give registered users the capability to upgrade their registration themselves, will probably require another email confirmation but I haven't decided on that yet.

I can't see any problem with whitelisting for users, solves a lot of other problems and is becoming more and more widespread in use. No different to this forum really.

I'll let you know when the site is live if you like so you can tell me what I should do better.

Cheers.