Enable blocks instead of single IP-addresses in UI

Created on 11 May 2018, over 6 years ago
Updated 21 January 2023, almost 2 years ago

The ban module enables you to store single IP-addresses, from which any access of the website will be prevented.
In some cases spammers uses IP-ranges from where they spam contact forms. So it would be nice to have a comfortable opportunity to block IP-ranges or if the usage of wildcards would be supported.

Feature request
Status

Needs work

Version

10.1

Component
Ban 

Last updated about 3 hours ago

No maintainer
Created by

🇩🇪Germany R.Hendel

Live updates comments and jobs are added and updated live.
  • Needs reroll

    The patch will have to be re-rolled with new suggestions/changes described in the comments in the issue.

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.

  • 🇮🇳India _utsavsharma

    Rerolled patch for 10.1.x.

  • 🇮🇳India _utsavsharma

    Fixed CCF for #51.

  • Status changed to Needs review almost 2 years ago
  • 🇮🇳India ankithashetty Karnataka, India

    Fixed the phpunit test errors in #51, thanks!

  • Status changed to Needs work almost 2 years ago
  • 🇺🇸United States smustgrave

    function ban_update_8700() {
    This needs to be updated for D10.

  • 🇮🇳India ankithashetty Karnataka, India

    Thanks for the review @smustgrave!🙌🏼

    Updated the patch as requested.
    Thanks!

  • Status changed to RTBC almost 2 years ago
  • 🇺🇸United States smustgrave

    Thanks for the quick turnaround

    On Drupal 10.1. with a standard install
    Tested the update hook does pass.
    Uploading a screenshot of what the UI now looks like (added IS template while I was at it)
    Running the tests without the fix I get

    Drupal\Core\Database\DatabaseExceptionWrapper : SQLSTATE[HY000]: General error: 1 no such column: bip.ip_range_end: SELECT "bip"."iid" AS "iid"
    FROM
    "test70272775"."ban_ip" "bip"
    WHERE ("bip"."ip" = :db_condition_placeholder_0) AND ("bip"."ip_range_end" = :db_condition_placeholder_1); Array
    (
        [:db_condition_placeholder_0] => 16909316
        [:db_condition_placeholder_1] => 16909319
    )
    

    Changes look good

  • Status changed to Needs work almost 2 years ago
  • 🇬🇧United Kingdom longwave UK

    As well as the below comments I also wonder that if instead of arbitrary start and end IPs, we should support CIDR ranges, e.g. 192.168.0.0/16 to ban all of 192.168.0.0 to 192.168.255.255. That would be easier to store and parse.

    1. +++ b/core/modules/ban/src/BanIpManager.php
      @@ -29,41 +29,138 @@ public function __construct(Connection $connection) {
      +      $group_ip = $query->andConditionGroup()
      +        ->condition('bip.ip', $ip_long, '<=')
      +        ->condition('bip.ip_range_end', $ip_long, '>=');
      

      Wondering if this works as intended in all cases, given that the ip and ip_range_end columns are defined as strings, but here we seem to be doing a numeric comparison.

    2. +++ b/core/modules/ban/src/BanIpManagerInterface.php
      @@ -12,11 +12,13 @@ interface BanIpManagerInterface {
      +   * @param array $options
      +   *   Options array.
      

      What are the possible options? We need to document this.

    3. +++ b/core/modules/ban/src/BanIpManagerInterface.php
      @@ -31,16 +33,20 @@ public function findAll();
      +   *   The end of the IP address to ban (optional).
      

      ban -> unban

      Also, what happens with overlapping ranges?

    4. +++ b/core/modules/ban/src/Form/BanAdmin.php
      @@ -108,14 +116,55 @@ public function buildForm(array $form, FormStateInterface $form_state, $default_
      +          if (!$ip_long) {
      +            $form_state->setErrorByName('ip', $this->t('Only IPv4 is available for IP range.'));
      +          }
      +          if (!$ip_range_end_long) {
      +            $form_state->setErrorByName('ip_range_end', $this->t('Only IPv4 is available for IP range.'));
      +          }
      

      None of the UI changes in this patch (such as these lines above) have test coverage.

  • Status changed to Postponed about 4 hours ago
  • 🇳🇿New Zealand quietone

    The Ban Module was approved for removal in 📌 [Policy] Deprecate Ban module in Drupal 10 and move it to contrib for Drupal 11 Active .

    This remains Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.

    The deprecation work is in 🌱 Deprecate Ban module Active and the removal work in 📌 [12.x] [Meta] Tasks to remove Ban module Postponed .

    Ban will be moved to a contributed project after the Drupal 12.x branch is open.

Production build 0.71.5 2024