BurningbirdThe discussion continues on comment spamming and a couple of people have taken my initial quick fix and expanded on it nicely.
Jennifer from Scripty Goddess has taken to solution into the MT tmpl files, adding the hidden field to processing.tmpl.
Brad Choate came up with a fairly complex solution that, while not keeping a determined spammer out, would force the person to work for their spam.
Joni Electric has a good re-cap of effort to date.
(Found through trackback, by the way.)
Recovered from the Wayback Machine.
Christine staged a Blog Debate, during which Ciscley commented about guys being reluctant to move to Moveable Type because it’s popular. She wrote:
I think (I *know* in my personal blogging circle and I’m generalizing from there) that most of the people that are uncomfortable with the popularity of MT are guys. It’s like it’s a dirty blog word to every guy I know. They use phpWeblog (though I still have to design their layouts for them cause the interface only goes so far). They use geeklog. They’ve thought about pMachine. They’re willing to try anything and everything but MT.
Is it because so many women use and love MT? Is it because MT, if you don’t actually use it and know what a huge part of it Ben does, appears to be the creation of a woman? Is it taking something away from the all male tech industry to consider that a product inspired by or significantly designed by a woman is the best option out there?
Jonathon picked up on it, writing:
There are so many things to like about Movable Type—reliability, elegant interface, customizability, MySQL support, vibrant user community—but what could be more intriguing than Ciscley’s hypothesis of gendered MT use? Has Mena’s contribution influenced the software to the extent that it attracts a disproportionately high proportion of female users?
Christine picked up on both Ciscley’s and Jonathon’s comments, so it will be interesting to see if there is any form of debate on this.
A gender bias with Movable Type just isn’t something I’ve seen. I would imagine that there is a strong gender bias with the other weblogging tools that Ciscley has mentioned, but not with MT.
Any initial reluctance to adopt MT is based on the installation, which can be a hassle for non-techies. However, this seems to effect both men and women equally, and is really dependent on how comfortable the person is with Perl and CGI. Once installed and used, though, MT users can be fanatical in support, regardless of gender. I know — I’m a fanatical MT user.
(“Hello, my name is Burningbird, and I’m addicted to Moveable Type.”)
Why do I like MT? Because it’s a lovely, lovely piece of software. Powerful enough for all my needs, hooks that allow one to tweak if we wish, and now it has the MySql backend, which for a data person such as myself, is pure heaven, with little chocolate sprinkles on top.
Hmmm. Come to think of it, if Movable Type is an example of software resulting from a paired man/woman collaboration team, then I think it’s time for the software industry to look at its development practices.
(Notice how I didn’t once use “—ism”? I’m getting better. And Christine, I have Trackback enabled. Do I get a cookie? Sorry for the double ping, but MT went crazy — it pinged you three times, blo.gs, weblogs.com, and my mother. It also scritched my kitty underneath her neck, and washed the dishes in passing.)
Recovered from the Wayback Machine.
Both Sam Ruby and Phil Ringnalda had good advice — don’t spend a lot of time on developing a solution to fixing the comment spam problem. Whatever I can do within the form, it’s a relatively simple matter for a spammer to read any form value and duplicate it in his spam blast.
I appreciate both their help in gently pointing out that I was spinning my wheels (but I have to get practice for ice driving).
So, here’s a quick fix — it will keep out the lightweights at least. It’s a start as other efforts are underway.
This approach will require you modifying the following MT templates:
Individual data entry
Comment Listing Template
Comment Preview Template
Comment Error Page
You’ll be adding the following field, on the line before the </form> tag:
<input type=”hidden” name=”snoop” value=”goaway” />
You can change both the name and the value field, as long as you’re consistent with the name throughout the templates and the code.
Next, open your mt-comments.cgi (or mt-comments.pl) file and add the following code just after the “use strict;” line:
use CGI qw(:standard);
if ($ENV{‘REQUEST_METHOD’} eq “POST”) {
my $data = param(‘snoop’);
die unless ($data);
}
Most everyone should have the CGI.pm perl module installed. Make sure to change ‘snoop’ to whatever your little secret field is (let’s all use different fields, make the spammer’s job a little tiny bit harder.
That’s it.
What happens is that when you post a comment, the code checks for a form field of “snoop”. If it doesn’t find it, it dies. Nothing fancy at all. This will show in your error log or web log file as a premature end to the script. It doesn’t prevent others from using the application, and doesn’t crash anything.
Again, this isn’t fancy, but it’s a start. Holler if you have questions. If you’re uncomfortable modifying mt-comments, let me know and I’ll help you. If you have a better solution, or see problems with mine, please let me know.
Again — thanks to Phil and Sam for advice, help, suggestions.
Update:
Mark has put together a nice re-cap on the whole comment spamming thing. What I just created is a ‘club’. I’m going in for an interview tomorrow and when they ask me what was the last application I worked on, I’ll answer “A club”. .
Recovered from the Wayback Machine.
In regards to the comment spam problem mentioned earlier, one idea kicked around was checking the http_referer to make sure that the comment post came from the same server as the form.
We talked about the possibility of empty http_referers — not all browsers send a referrer and proxy servers can strip out the referrer. The solution would be to allow empty referrers in addition to referrers from the server. Unfortunately, though, allowing for empty http_referers will also allow in the comment spammer.
The reason why allowing empty referers opens the door to the spammer is the comment spamming code would invoke my comment code directly, not through a link from an HTML page. In this case http_referer would be empty.
I could become more restrictive, remove the permission for empty referrer, but if I do, I won’t be letting some of you through (as you’ve been kind enough to let me know via email tonight).
Sam Ruby had some good ideas such as putting hidden form fields into the comment forms and testing for these and this will be a next step. This means adding form fields to all templates related to comments, and then adding code to mt-comments.cgi. Doable, and many appreciations to Mr. Ruby for excellent ideas. (If you don’t know Sam, he works on some weird sounding things such as “Comanche” and “SOUP” — stuff like that).
A really nifty and difficult to crack approach (IMO) would be to take the person’s login name and the comment id for each comment and use these to create an encrypted value. Stuff this into an HTML form field. When the form is processed, test to see if the encrypted value checks out. If the person’s login name isn’t exposed, which is should NEVER be, it becomes a ‘key’ for the encryption, easily accessible to the MT program and the MT user, NOT to the spammer. And the different comment identifiers would make sure that the encrypted values changed with each comment.
Only problem with this solution is it would require cracking into the MT internal code.
Question: what do you think of this as a solution, and is it worth the time to do it?
(However, by now, Phil or someone else of like cailber will have found and coded a solution and have it half way distributed throughout the world. I should just leave these little challenges to others — what do I know?)
Recovered from the Wayback Machine.
Seems to be a technology day today.
Phil caught a comment spammer who was trying to dump spam comments in all of his posts. This process would work within any weblog that sequentially numbers weblog posts (ie Movable Type).
I’m going to try and tweak my mt-comments.cgi to stop POSTs from pages outside of my root URL. This is my way of warning you all that the comments, web pages, weblog may be a tad more behaviorally challenged than normal.
Update: I added checks on referers and this will prevent posts from locations other than my own weblog server. Unfortunately, as Phil pointed out, http referers are fairly easy to fake. I also wrote a test script that did so, and my checks failed to catch a ‘fake’ referer.
Still, it’s a start…
If you attempt to post a comment and fail, please send me an email and I’ll check to see what the problem is. Unless, of course, you’re the spammer. In which case: Eat dirt and die scuzzbucket!
Ahem. Thank you.