Sometimes it is useful to log blocked attemtps to use forms. Can this be seen in server logs? As far as I know, it cannot, but if it can, how? If not, can it be logged on the Drupal installation. maybe using Trigger?

The reason it is sometimes useful is illustrated here http://drupal.org/node/1248138#comment-4865186.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

geerlingguy’s picture

Status: Active » Postponed

I could probably set an option to log failed attempts (at least, the IP address of the referrer, and the form or path on which the failure happened. Leaving this as postponed until I get a little time to work on it more.

I'd definitely leave this off by default, as writing to the db is expensive (well, more expensive than not writing ;-), and as-is, Honeypot is practically instantaneous in all regards.

Barrett’s picture

I've put together a 6.x patch for this (attached). When I have a minute, I'll see about porting it to the d7 version.

geerlingguy’s picture

Status: Postponed » Needs review

Patch looks good after a quick readthrough. I'll test and commit as soon as I have time. It would be best if we can keep code formatting/cleanup out of these patches, and tackle that in a separate issue (makes reviewing that much quicker ;-).

If someone else can also review the patch (apply it, test it, see if it works), that would be helpful.

Barrett’s picture

That'll teach me to assume code format problems are mine, I guess ;^)

Here's a patch against 7x. It does not include the formatting points.

John_B’s picture

I have applied the 7 patch. No error message. Too soon to have seen any logged rejections. I was unable to trigger one by sending messages in quick succession.

PS if anyone happens to know... can a patch be applied with drush? I had to do it the hard way. 'drush make patch' should to but the make extension is D6 only.

Barrett’s picture

John_B, it doesn't appear patching can be done with drush.

For testing, I did a couple things. For the honeypot field, I commented out the css line so that the honeypot field appeared and I tested with the css included and used the TamperData add-on for Firefox to force data into the field.

For the time testing, the only solution I found was to set the limit ridiculously high (45 seconds) so that I could blow the time easily.

geerlingguy’s picture

I'm attaching the patch I applied to 7.x - I mostly kept things as they were in #4, but changed the variable to, simply, 'honeypot_log', and didn't save the user's IP address in the log message (since that's stored in the watchdog record already).

geerlingguy’s picture

Version: 7.x-1.4 » 6.x-1.x-dev
Status: Needs review » Patch (to be ported)

Pushed to Drupal 7 branch: http://drupalcode.org/project/honeypot.git/commit/66fa670

I'm working on a D6 port right now. Should be done soon...

geerlingguy’s picture

Version: 6.x-1.x-dev » 7.x-1.x-dev
Status: Patch (to be ported) » Fixed

6.x: http://drupalcode.org/project/honeypot.git/commit/118be41

I'm going to release a new version of the module now :)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

geerlingguy’s picture

Title: Can blocked requests be seen in server logs? » Log blocked form submissions

Updating title.