antikoan.net

Captcha appears to be useless, at least for Drupal. Antikoan.net has just been DOS'd for three hours (again, bringing down email as well as the website and site control panel). So apparently when you have 1300 (that's one thousand three hundred) "users" trying to post comments in a short timespan, it doesn't matter that they're not getting to actually submit the comments.

(I thought at first it was just another DNS failure -- I've had about six DNS failures since I moved to my current hosting provider. But then Peggy told me she'd seen 1300 "visitors" listed in the "Who's Online" block before the site went down.)

It also seems to be the case that capcha insertion doesn't prevent SQL writes in Drupal. That makes it pretty much useless for foiling DOS-attacks (in Drupal, at least).

Finally, at least four anonymous comment spams got through last night. So either the spambots have captcha-defeating code (odd that they'd have built that into a Drupal-attacking spambot...), or Captcha breaks stuff, as Peggy and Lynne have been reporting to me.

I have a few other things I can try, but they require some development. I could be able to implement it as a module, but it would be easier as a hack. Simpler, too. More another time...

Addendum: The site has been down twice more today, both times preceded by thousands of attempts to comment-spam. It seems that just hitting and submitting the "reply" page a few thousand times in a short time frame is sufficient to crash my site. I've turned caching back on, and there's a remote chance that might help, but if it's the reply validation that's killing the server then it won't help much. I'll just have to wait for the MoFos to get tired of attacking me.

I've finally gotten around to implementing the Drupal Captcha module. Since I've already patched my comments module to include spam filtering (which is still in place, BTW), it was a slight nuisance to integrate the required comment.module patch. But it was a very slight nuisance, and it's done, now.

Hopefully, putting a captcha between the "add comment" click and posting a live comment will stop spambots from being able to post anonymous comments in the first place.

My friend Lynne pointed something out to me a few days ago: Looking through the "recent posts" lists, she was able to deduce that this site had been getting comment spammed at a rate of about once every five seconds for a period of around an hour. All were flagged as spam; none of them made it through to human eyes. I was mildly impressed, for two reasons: First, that my site had handled the load; second, that someone had written a bot to attack that aggressively.

The day before yesterday, I stopped being impressed, and became furious.

I had pointed out to Lynne that the only real restrictions on how fast a comment-spamming 'bot could attack were the capacity of the web application and the speed of HTTP. Since HTTP is stateless, there can be any number of concurrent attacks in play; ergo, the server will most likely collapse first. that's what happened the day before yesterday, as the rate of attack shot up to more than once per second. The site buckled in about 20 minutes; it failed just as I was looking for the setting to turn off anonymous comments.

That's the roundabout way of explaining why anonymous comments are now switched off. The attack bots simply have no way to see the "post comments" link, for the moment -- they can't login, they can't comment.

I hate this solution. I'll be adding a captcha module and patching the comments module to use it, Real Soon Now ("in my copious spare time", as we used to say at Ziff-Davis Education). I have ideas about how to make the comment button harder for bots to see, but they require patching core on Drupal, which I'm loathe to do.

As Peggy points out, I guess I'll need to monitor enrollments more carefully. And as Lynne could tell you with regard to other sites, I'm not very good about that, anywhere....

The onslaught of comment-spam has stopped, for now; it could pick up again tomorrow. It continued without abating for about five and a half hours, with what looks to be an average of about one message every three and a half minutes. And after the first fifteen or so -- which is to say, after I'd had a chance to mark a single one as spam -- not one single message made it in front of a site user other than myself, and all without any further intervention on my part.

One more ironic fact about this: The site being advertised by all of this comment spam is actually not accessible at the URL given in the comments. The server doesn't respond. That means either: their spamming was so effective that the servers have failed under the load; or they comment spammed the wrong folks, and earned a Denial of Service attack in return. One can only hope...

I wasn't getting any spam right after I deleted that last bunch. But this afternoon, it started flooding back in again. Well, trickling, I guess, though one every four minutes (like clockwork) is still a flood to a flesh and blood human with other things to do.

But I got my spam filter installed yesterday, and was eager to try it out. And about a half hour ago, Peggy sent me a note to let me know that the Online Casino boys were back.

So I hopped over to the comments management page, and discovered that there were about ten "Online Casino" comments; and that's when I discovered that the spam filter didn't have bulk management controls. I understood, then, why I needed to use the comments module patch that the spam module author had so thoughtfully included.

So, ten minutes more spent digging around looking for a patch utility that would work under Win2K, then upload, and I suddenly had the capability to select and mark messages as spam in large numbers. Which I promptly did.

Shortly, I started receiving email from the spam filter: Now that the Bayesian engine had samples to analyze, it was happily flagging each of the Online Casino messages as they came in. Every four minutes. Like clockwork. If history is any judge, there will be four hundred of them before the bot is done with me.

And not one of them will do the spammer a damn bit of good.
It makes me feel warm and tingly: I've managed to consume their resources, returning a "success" code to their bot, while at the same time effectively subverting their purpose.

... enough about Drupal to write a spam-bot for it. I just deleted about four hundred spam-comments, directly through the database -- all advertisements for an online casino. All hammered in within a very short period of time. I have no idea whether it will affect site function that I did it through MySQL, but what the hell: The alternative was to sit here and click away for hours...

And I wasn't the only one or even nearly the first to get hammered like this, either. Someone must have stumbled onto a directory of Drupal sites. Which highlights the problems of distributed login networks like IXPS and the Drupal distributed login system. But I digress....

So I've installed Drupal's spam module. It adds a Bayesian filter, configured to weight URLs more heavily than plain text. It also checks to see if the poster is coming from a known email relay and scans URLs to see if they've appeared in a previous spam message.

All very gameable checks, but I won't complain that the heuristics aren't any good because I can't think of better ones. But I can think of a sure-fire way to stop comment spam dead in its tracks: A captcha. Captchas are those graphical codes that you have to enter on Yahoo and PayPal and some other secure sites; the letters and numbers are often warped or mangled to make them machine-unreadable. Inserting a captcha into the comment-posting interaction would make Bayesian spam filtering redundant. At least, for now.

And I'm not the first person to think of it. Apparently, though, there are some technical issues with the comments API that make it difficult to insert captchas using the existing comments module. For now, at least, I'll be able to take pleasure in tagging the new comments as spam.

The site will be a bit disorganized -- for a few days, probably -- while I'm working out the kinks in the Drupal 4.5 upgrade. We'll be missing the nifty display of taxonomy terms until I can rework my old themes for compatibility with the new environment. Until then, please enjoy the simplicity of the generic "Chameleon" theme...

Update: Quotes are back, and I slid in a logo -- maybe I'll keep this theme for a while. Grey was getting a bit heavy, anyway...

Update 2004-12-12: I discovered that Fantastico's version upgrade feature deleted most of the content of my website, including all my old blog posts and a bunch of other stuff I had on the site. (Like my '99 April Fools gag, which is a little too funny and takes a few too many liberties with certain trademarks and copyrights for me to post a link in the clear -- suffice to say that experiments with adding "/af99/index.htm" might yield a few moments of nostalgic amusement...) All of that is back, now; not sure how I'll deal with that in the future. It's a damn good thing I took a backup before I upgraded....

... will be happening sometime this weekend. Site will be down briefly. Posting will be shut off. Not to panicking.

Update: 4.4.2 went with no apparent hitches. Looking at a couple of promising modules for addition to the site; will probabily upload a bunch of module code so I can experiment at leisure. Documentation is (as usual) sparse, so I'll have to install these to see what they actually do.

Looking at:

• blogadmin menu module, to streamline access to blogging tools. May not be very useful; may confuse the interaction design.
• Comments RSS, which should make it possible to track threads through a news aggregator.
• Context Links: Theoretically allows addition of context-links. Not sure what the implementation is -- whether it extracts links from node, or allows user to add new links.
• Email This Page. Pretty straightforward. My only concern is that it might make the UI more confusing.

... and will be looking at a few HTML correction modules, menu modules, upload modules, but probably not today.

Yesterday, I spent several hours reworking stylesheets for the site's theme. I uploaded them; I reviewed them on the live site. I brought the "chameleon" theme into line with the presentation of the old, broken xtemplate theme that I turned off a week or so ago, bringing back the border around the central content area, "softening" the format of the blocks and block headers, improving the paragraph leading, etc.

Now they're back to the same as they were before.

What the hell happened? No one else has FTP or admin access to this site. And they wouldn't know what to do if they did. Did I have a midday hallucination that I'd checked this?

Addendum: Screw it. Until I can figure it out, I'm going back to the default Chameleon theme.

Addendum 10:29: Another bizarre caching effect. Mozilla was caching the stylesheet through restarts and theme changes, which is something that should not have happened -- nothing else was being cached that way. (I hate it when that happens.) Clearing cache solved that problem. So I've set back to the new stylesheets.

Except that now I have another problem: For some reason, the default font size in IE 6 on my NT4 system here at the office is "smallest"; the stylesheet's don't use keyword-based sizing, so I have no idea why that is. Suppose I ought to go boot up the Mac in the next cube to look it over, but there are lots of people around...

So, why is it that if a site can load perfectly well across three different browsers with three different codebases, and fails on a fourth, the site is said to be broken; but if a site loads fine in that fourth browser, but fails on the first three, it's said to be fine?

Other problems:

• Padding on News Aggregator listings needs to be adjusted. Probably really a problem with the padding on h2.title.
• Need to adjust padding for some sub-elements of #main. Since I'm not using a full-width copyright element anymore, I should probably just re-apply the padding to #main
• Node titles don't stand out well. Need to experiment with different treatment.
• Add emphasis reversal nesting -- e.g., <em></em> inside of a <blockquote></blockquote> container will be "normal" style, etc.

On the plus side, the cron jobs are happening like they're supposed to...

... I have actually fixed it. Albeit not in the way I'd wanted to.

When I first developed the xtemplate based template for this site, I tested it on Mozilla 1.6 for all of the pages I commonly displayed, and everything seemed to work fine. Unfortunately, the test plan on my local site didn't include comments with links in them, so I didn't spot the fact that there was some kind of layer-related problem that frequently made links un-clickable in some comment-display modes.

I finally became aware of how bad this problem was a few days ago, and spent several hours yesterday (Saturday) trying to fix the problem. I assumed to start with that the problem was somehow due to my own stylesheet -- I couldn't imagine the problem actually residing in software. But, lo and behold, after exhausting all stylesheet options, I went through the rendered page code with a fine tooth comb and discovered an un-closed <div></div> container (note: the previous example would render correctly in an Atom feed, but won't in my RSS feed).

Long story short, I found a workaround, but in the process of testing I discovered that my xtemplate theme had always apparently had some really nasty display characteristics in Internet Explorer. So you're now looking at my early PHPTemplate version of the AK theme.

Heh, I needed to do a revision, anyway.

So, my apoologies to anyone who might have been reading and cursing my stupidity as I railed on UI concerns. I let my contempt for Explorer get in the way of a good test plan.

Down In Back

Most dynamic pages at this site are served by Drupal 4.x. I evaluated and played with configuring a bunch of open-source CMS systems and picked Drupal because it was the one that seemed to have the cleanest code and the smartest developers.

Drupal is a bit difficult to configure for usability, though; it's got some nifty usability and information design features like baked-in taxonomy navigation and branch-level syndication feeds, but the documentation on new modules sometimes leaves a bit to be desired. Not recommended for people who aren't comfortable adding table columns to their MySQL dBs.

I've basically recreated most of the functionality that I had on my old Radio-driven blog, which has been ported and redirected over here from Antikoan.com. When I've got the time, between working and actually trying to have a personal life and develop a web consulting business on the side to tide me over when I decide I can't handle my job anymore [...INHALE...], I plan to implement a few new features. See below.

Up In Front

As always, this site is coded with frank disregard for validation or standards. I code what works to get the results I want, and I don't apologize for that. When it stops working, I'll stop coding it that way.

I also don't pay any attention to those much-too-detail-oriented types who draw distinctions between different types of dash. I don't have time for that crap. The content is what's important; typographic niceties like the difference between an em and an en dash are irrelevant to English grammar and style.

Yes, this site uses tables for layout. No, I don't like that. Yes, I'd like to do away with them. But I'd also like people to be able to read this site without having to spend many many hours tweaking a cross-browser three-column layout that could be made to work with a CMS. Not that I don't love tweaking Drupal themes, but I do try to have a life. Even if that just means reading a book now and then.

Up And Coming

Short term:

• A major user interaction overhaul.
• Theme redesign. (Lost the old theme during the 4.4 to 4.5.1 update.)
• Restore node-level syndication feeds and notifications. (Lost during the 4.4 to 4.5.1 update.)
• Addition of "sidebar" capability, image link tool, related links feature.

Longer term:

• Thinking about shifting my personal calendar here from Yahoo.
• Similarly, thinking of implementing a bookmark storage and personal news summary page -- but then, you might not ever see those things....
• Planning to add some kind of facility for single-story export to another Drupal site.

I wasn't going to approve users for comment until I'd thought through the design some more. Who was I kidding? I'll never get around to that... I'll just have to reserve the "right" to completely jettison the user list if things (i.e., the application) aren't working the way I want. For now, it's only fair that if I say something about somebody, they should get to respond. Especially since I haven't patched Drupal's trackback module to make it actually work.

The Quotes module was interesting. The author "despises" mods that require that the user manually create tables or run SQL scripts, but neglects to mention that you have to take the crucial step of giving yourself access to the Quotes module administration page if you want to install it as anything other than the root administrator.

Looks like it has a workable import function, though; I'll see if I can get that to work on my Xoops/Xaraya quotes tables a little later....

FOLLOWUP: The import feature is pretty screwy. It definitely needs hard-return after the last EOL, and when the instructions say tab-delimited, they mean it -- no escapes, no quoting. Not really worth it right now to figure out precisely what the bugs are, but it has 'em.

Finally got around to setting up .htaccess so it would support clean URLs. (Annoying that I can't test it on my Windows systems....)

I had to comment out two lines in the stock .htaccess file that resulted in a 403 whenever I tried to load index.php. All other parts of it worked. As they were the commands I thought least likely to be offensive, I had almost the entire file commented out before I got to them....