In this function the code for adding a blacklisted IP to {access}, thereby banning it, is inoperable by virtue of being commented out. Is this an oversight or is there a reason for this?
As the module works now, overall, any IP blacklisted after a DNS lookup at Honeypot will be added to {access} and be banned, but if a greylisted IP attempts and fails the whitelisting challenge, it will be blacklisted only in {httpbl} but, because the code is commented out, not be banned altogether.
I meant to bring this up a few days ago, but I've been using the module on four sites with this code being operable, so I forgot about it being "officially" commented out until I reviewed the latest snapshot. It seems to work great, by the way.
Also, immediately above the commented-out code is a ToDo note in comments about checking for duplicates, but it seems that would not be necessary since a banned site would not be capable of gaining access for future blacklisting consideration until after the first ban has expired.
Comments
Comment #1
praseodym commentedI don't remember why this is commented; I must have had a reason for it but I can't remember any more. Looks like it'd be fine to uncomment the code. It's not a very big problem though, since requests will be blocked by hook_boot anyway.
Comment #2
bryrock commentedTrue enough; not a "big problem," but for the sake of consistency, ban any and all blacklisted IPs. From a user support standpoint, if ever the question is asked, "Are blacklisted sites also banned?" then the answer is an emphatic "yes" that requires no further explanation, instead of "well, sometimes."
Comment #3
bryrock commentedI put this code back in two years ago and it's worked great. So I'll consider this reviewed and tested and get it out soon.
Comment #4
bryrock commentedNow available in an alternate dev fork that should be published soon.
Comment #5
bryrock commentedFixed in 6.x-2.x-dev and ported to 7.x.