Drupal 6 port needs work

I guess that might be why it is still in development ;-).
I'll fix it.

bump?

I'm currently testing this on my site, I'll confirm shortly if it works.

I've been using this since I bumped in May. admin/reports/status reports "http:BL is enabled and has blocked 0 comments." which I find impossible. Something isn't right.

I agree that this isn't working at all. I've had numerous dictionary attackers and comment spammers creating accounts on my site, even though I've applied this patch and enabled http:bl on all requests.

To be fair, I suppose this patch could be fine and there could be something else in the dev version that's not working, but I don't know enough about it to say...

Since we have multiple reports here, lets make this official.

I'm starting the abandoned projects countdown. If the maintainer doesn't respond, I'll just start committing things myself, so start working on those patches. If this module is really so broken, it's hard to believe the maintainer wouldn't be doing something about it.

Thanks deekayen - I didn't notice until you posted that there haven't been any commits in over a year! I'll try to look through the code and figure out what's going on, but I know absolutely nothing about this project so it might take a while... if someone else is more familiar with it feel free to take the lead...

I'd be learning as well. I obviously haven't done much to fix it since I posted in May. I'm just volunteering to commit a fix if someone makes one.

I'm quite surprised by the sudden spike of activity in this project. I haven't really abandoned it, but simply haven't had enough time to debug the issues in the 6.x-dev branch (and to only apply a this simple patch I need to figure out how CVS works again, which I always find quite troublesome).

@deekayen: I appreciate your concerns, but please don't run too fast. I'd be really helpful to know where the bugs are and if you could help me fix them, but that doesn't mean you have to take over the project. Also note that if you've set the check level to "On all requests", the comment-block-counter will never increase because bots won't even be able to reach the comment form.

I don't currently have a website busy enough to test this module really well. From looking at the code paths it should work fine (with this patch applied!), unless I'm missing something of course.

Here's another problem, hook_boot is literally implemented as hook_boot() :) It should be httpbl_boot(). I'll see if that makes a difference. Remember if you try this that you need to update your system table cache, for instance by visiting the module list page.

Well, that didn't seem to help... I'll keep investigating...

Oh. I really wish that someone had mentioned this sooner - #325200: Another fix is basically a duplicate of this, and the "patch" there mostly takes care of this issue. I will roll an actual patch file when I get a chance and mark one of these as a dupe.

Okay here is a patch that gets the D6 port working.

Thanks!
If someone can verify this patch (i.e. verify that the module actually works with this patch) I'll commit it and release a new dev version.

+ subscribing.

FYI (since I don't know how to temporarily assume an evil IP address for testing) the easiest way to test this is probably to replace ip_address() with a known malicious IP.

I've got the patched module running on a production site with light traffic (about 700 unique visits a month). So far, so good. It doesn't seem to be causing any problems. Earlier this past week I manually banned 3 IPs that were making repeated visits and having a field day spamming some forms. I un-banned them less than an hour before adding this comment and not long afterwards my Status Report already shows:

http:BL is enabled and has blocked 4 visits (0 blacklisted and 4 greylisted).

That looks like something is working as expected, does it not?

Question: Is there somewhere I can view the watchdog log? I've got it set for verbose logging, but have been unable to figure out how/where I might see some details on the 4 blocked visits mentioned above.

The watchdog log is at /admin/logs/watchdog.

Fix is committed to CVS, a new snapshot should appear within a day. If I receive some more positive replies I'll release this as a 6.x-1.0.

An update on my previous comment (#18), regarding using patch httpbl-322221-14...

I looked into the database tables for the 4 greylisted IPs and manually reviewed them at Project Honeypot and they are indeed 4 undesirables. So the greylisting appears to be performing as expected.

These were all new IPs, also. That is, these have nothing to do with the IPs I had manually banned earlier last week.

Hostname, status, expire
216.104.15.134 2 1252227711
91.121.91.61 2 1252222742
193.171.32.6 2 1252222746
212.102.0.104 2 1252222748

Regarding my question about the watchdog log, pardon me, I didn't realize that "watchdog" was a legacy name for Drupal 6's dblogging.

I did look into the watchdog table,however, and found no entries at all from httpbl, so logging does not appear to be happening at all.

Looking at lines 211 & 212 of httpbl.module, it appears that logging would only happen if the httpbl_log variable were FALSE. Isn't that supposed to be TRUE?

The code is fine; a
if (variable_get('httpbl_log', FALSE)) { ... }
block will be evaluated when the variable httpbl_log is TRUE. The second argument (FALSE) only serves as a default value. I'm not sure why log entries aren't appearing for you. Please open a new issue if the problem persists.