Contrib.social

Missing critical way to alter flood protection before it denies

Open on Drupal.org →
Created on 21 January 2011, almost 14 years ago
Updated 29 August 2023, about 1 year ago

Example: Employees all login from a same set of IPs, and you don't want to shut down everyone if 25 people enter their wrong password 2 times in an hour, but still limit any non-external IP addresses.

The flood_is_allowed() function has no way of allowing anything else to change that result, limit, or window. It doesn't use drupal_alter() nor db_select() (which would allow us to alter the query directly).

🐛 Bug report
Status

Closed: outdated

Version

9.5

Component
Base  →

Last updated about 14 hours ago

Created by

🇺🇸United States dave reid Nebraska USA

Live updates comments and jobs are added and updated live.
  • Needs backport to D7

    After being applied to the 8.x branch, it should be considered for backport to the 7.x branch. Note: This tag should generally remain even after the backport has been written, approved, and committed.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment over 1 year ago →
    🇸🇪Sweden dajjen Drupalcon Prague

    Is this still an issue?
    The old flood_is_allowed have been replaced by the flood interface (Drupal\Core\Flood\FloodInterface) that you can apply to a class and implement you own isAllowed method.

  • Status changed to Closed: outdated about 1 year ago
  • Comment about 1 year ago →
    🇬🇧United Kingdom catch

    Yeah I think this is outdated. The user behaviour is defined by configuration, the flood service can be swapped out, and user module has it's own UserFloodControl class/service that can also be swapped out now.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024