JSSpamBlock and ImageScaler were both originally one-day projects that turned out to be a bit more popular than I expected. Recently I have neglected to update them at all, but with reports of ImageScaler not working on WordPress 2.3, I decided to put a day aside and make some changes I had been meaning to make for a while.
A new version of ImageScaler was released last week (thanks to David Karlsson for doing most if not all of the work). I still got comments that it didn’t work with WordPress 2.3, so I installed WordPress 2.3 myself to see what the problem is. I didn’t have any issues, but I made some changes to ImageScaler that might make it more likely to work. If you still have problems with WordPress 2.3, let me know. I also made another major change - images hosted on other servers were previously ignored by ImageScaler and left as-is. Now they are mirrored on the server and can be re-sized properly. Also, images are now always resized so that the aspect ratio is preserved. You can download ImageScaler 1.1 from WordPress.
The new version of JSSpamBlock doesn’t need a database. It uses sessions instead. I also cleaned up the code a bit and tested it with WordPress 2.3. You can download JSSpamBlock 2.0 from WordPress.
I just noticed a trackback from Brandon Cheketts about a PHP script he has released that lets you incorperate functionality similar to JSSpamBlock in any website, called bcSpamBlock. He also released a WordPress plugin based on JSSpamBlock that uses the script.
Although both plugins take advantage of the same limitation of spam bots - that they ignore JavaScript, the way they verify the codes is different. While JSSpamBlock uses a database, bcSpamBlock uses one-way encryption to verify the codes. Although this is a clever way to do it, I chose not to do it in JSSpamBlock for a reason: Storing the code in a database ensures that, even if a spammer were to write a bot targeting sites with JSSpamBlock, each comment posted would require the bot to parse another page from the server. Each code sent to the browser can only be used once. The problem with not using a database is that you have no way to verify that the codes sent from the browser are being used for the first time, and not the 10th.
Georg Kaindl made similar comments about the database being unnecessary, and I wrote a more lengthy response explaining why it was. He then came up with a clever solution - including the post’s ID in the hash. It still isn’t quite as secure as JSSpamBlock (I hate to use the word “secure” to describe what I admit is “security-by-inconvenience”, but I can’t think of another word that fits), but for all practical purposes it should be just as good. The only difference is that spammers could post multiple comments to any given post while only parsing the page once, while JSSpamBlock would require the page to be parsed once for each comment. The other advantage is that I do not have to rely on the JSSpamBlock user to come up with a unique salt in order for the protection to be secure. bcSpamBlock gets around this in a clever way, by using unchanging environment variables to generate the salt.
Another way to look at it is that generating a random code for each page view does not actually increase security (over using the same code for each page view) unless you use a database. So for a plugin that doesn’t use a database, this only gives the illusion of security. You might as well use the code “4422″ for everything, and it would be just as secure. This might sound bad, but any bot that is currently blocked by JSSpamBlock would be blocked by this as well. The only reason JSSpamBlock does more is to make it harder to write a bot that specifically targets JSSpamBlock. It may sound egotistical to suggest that a spammer would ever bother to write a bot specifically targeting the plugin, but for the extra cost (milliseconds of CPU time), I think it is worth making the plugin future-proof.
This blog has been a bit slow since I started school, partly because of the extra work but also partly because the “just for fun” projects I have been working on have gotten larger. At the same time, I hate to neglect my existing projects to start other ones. Given that, I was very lucky to have David Karlsson, who had released a modified version of Image Scaler, agree to incorperate the original functionality back in so that I could make it an official release. The biggest improvement is that you can now set a maximum width and height, which are used to resize all the images. So if your theme breaks with images over 600 pixels in width, Image Scaler is a graceful way to stop this from happening.
You can download Image Scaler 1.0 from WordPress, where it is hosted.
RSS Feed