When an authenticated user violates the required submission time, an entry is made in the honeypot_users table. Each entry that is created for a given user increases that user's required submission time exponentially. Entries in honeypot_users that are older than honeypot_expire are cleared only when honeypot_cron() runs. Until that happens, authenticated users are stuck with required submission times that can easily grow to ridiculous proportions.

There is a similar mechanism for increasing the submission time of anonymous users using entries in the flood table. These entries, however, are ignored if they are older than honeypot_expire.

Here is the count that is performed for authenticated users:

$number = db_query("SELECT COUNT(*) FROM {honeypot_user} WHERE uid = :uid", array(':uid' => $user->uid))->fetchField();

Here is the count that is performed for anonymous users:

$number = db_query("SELECT COUNT(*) FROM {flood} WHERE event = :event AND identifier = :hostname AND timestamp > :time", array(
  ':event' => 'honeypot',
  ':hostname' => ip_address(),
  ':time' => time() - variable_get('honeypot_expire', 300),
))->fetchField();

Can we make the count for authenticated users behave like the count for anonymous users with respect to honeypot_expire?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

geerlingguy’s picture

Version: 7.x-1.17 » 7.x-1.x-dev
Category: Feature request » Bug report

Can we make the count for authenticated users behave like the count for anonymous users with respect to honeypot_expire?

Yes; this was an oversight on my part, and is more of a bug than a feature request. I'll try to write a patch for this soon, but might take me a little while since I'm in my post-DrupalCon/need-to-focus-on-other-stuff slump right now :)

It'd also be nice to add a test which tests the expire time by setting a sleep() and then running cron, or at least emulating a cron run, both for authenticated and anonymous users, so we can make sure we verify and never break the expiration behavior.

markdatter’s picture

Issue summary: View changes
geerlingguy’s picture

Issue summary: View changes
geerlingguy’s picture

Status: Active » Needs review
FileSize
1.25 KB

Completely untested, but this seems like what's needed here.

geerlingguy’s picture

Adding appropriate tags... someday I won't have to maintain three separate versions of this module :P

JuliaKoelsch’s picture

Status: Needs review » Reviewed & tested by the community

I tested the patch, and the behavior is consistent for both anonymous and authenticated users. Thanks!

geerlingguy’s picture

Issue tags: -Needs tests

Thanks so much! I'll commit to Drupal 7 then reassign to D8 after that's done.

geerlingguy’s picture

Version: 7.x-1.x-dev » 8.x-1.x-dev
Status: Reviewed & tested by the community » Patch (to be ported)

Fixed in 7.x-1.x. Moving to 8.x-1.x next.

  • geerlingguy committed 0e7e6bd on 7.x-1.x
    Issue #2491723 by geerlingguy, Spry_Julia: Check honeypot_expire when...
geerlingguy’s picture

Status: Patch (to be ported) » Needs review
FileSize
1.3 KB

Patch for Drupal 8 attached.

  • geerlingguy committed acc7a76 on 8.x-1.x
    Issue #2491723 by geerlingguy, Spry_Julia: Check honeypot_expire when...
geerlingguy’s picture

Version: 8.x-1.x-dev » 6.x-1.x-dev
Issue tags: -needs forward port to Drupal 8

Next up is 6.x-1.x.

  • geerlingguy committed 154e717 on 6.x-1.x
    Issue #2491723 by geerlingguy, Spry_Julia: Check honeypot_expire when...
geerlingguy’s picture

Status: Needs review » Fixed
Issue tags: -Needs backport to D6

All done! Completed as part of #DCSTL (DrupalCamp St. Louis 2015).

Status: Fixed » Closed (fixed)

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