Add the possibility to white list specific IPs

Interesting feature. I wonder if Drupal core allows something like this. Did you check that?

I just got in very similar situation where making drupal authorization backend was the fastest option and faced the same problem. In answer to your question, yes that's possible. Thanks to using service decoration that is mentioned here dynamic services and decoration → . Patch for this functionality included for 2.3.x.

+      '#default_value' => $flood_ctrl_settings['ip_white_list'],

This gives an undefined index notice on existing site.

+      '#title' => $this->t('Username login IP whitelist'),

Is the whitelist only for User login? Or also for the other action like request password, etc

+      '#type' => 'textfield',

Would a textarea not be more user friendly?

+      '#description' => $this->t('Username login unrestricted IP addresses (comma separated)')

Could be more readable like "A comma-separated list of IP addresses that will have unrestricted access"

Next to the comments above, which should be fixed, I've also noticed the unblock form doesn't give accurate information now. The method \Drupal\flood_control\FloodUnblockManager::isBlocked will need to be updated to make sure the blocked status is determined correctly in the unblock form.

Also in the services.yml file '@.inner' doesn't work.

I'll try to update the patch

Updated patch with comments from above tackled and some bugfixes.

Updated file, previous one had an error in it's generation

Your patch seems to be creating files that already exist.

So if I try to apply the patch I receive these errors:

error: config/install/flood_control.ip.yml: already exists in working directory
error: config/schema/flood_control.schema.yml: already exists in working directory

Thanks for the feedback, but :)

• To which version are you applying the patch? Because the flood_control.ip is a completely new file, it simply doesn't exist in the codebase yet, unless you've already applied a previous patch. We use this patch now on a site with composer-patches on the latest stable version, and that applies without a hitch.
• Valid comment about variables, but I can only spend more time on it if we need a re-roll of the patch. I also think this specific abbreviation (which I took over from the patch from comment 5, I started from there) should not give issues in readability since ctrl is the most common abbreviation for control that exists. If it already happens elsewhere in code, wouldn't it be good to have a separate issue to fix that in general then? :)

Ouch, that was due to local changes that weren't committed to git. Apologies for that. So there is no need for re-rolling the patch.

Updated patch with small fixes and improvements:

1. Changed field type of IP Whitelist field from text to textareaa
2. Changed type in config schema from text to string (text is wrong because this type is translatable)
3. Added possibility to specify range of IP addresses
4. Added validation for IP addresses and ranges
5. Added update for create new config file
6. Changed name of config file from flood_control.ip to flood_control.settings, because I think this config in future can contain settings related not only to IP whitelist
7. Code style fixes

Updated patch with small fixes.

This is looking nice. There are some points that could be improved though

1.

+    $form['login']['ip_white_list'] = [
+      '#type' => 'textarea',
+      '#title' => $this->t('IP whitelist'),

Given that this settings is not part of the user.flood config, I think it is cleaner to put this ip_white_list element in its own Fieldset, just like the contact field elements in this form.
So resulting in something like $form['flood_control']['ip_white_list']

2. I think the validateForm method could need a bit more inline documentation, especially when doing the filtering and lowercasing, because these lines are a bit hard to read.

3. Also the isIpWhitelisted method is a bit hard to read. For example the if-elseif construction could be simplified and some inline documentation should be added to explain what is happening.

4. My phpcs encounters a couple more errors to fix:

FILE: /var/www/html/web/modules/contrib/flood_control/src/Form/FloodControlSettingsForm.php
-------------------------------------------------------------------------------------------------------------------------------------------
FOUND 4 ERRORS AFFECTING 4 LINES
-------------------------------------------------------------------------------------------------------------------------------------------
 183 | ERROR | [x] list(...) is forbidden, use [...] instead.
 186 | ERROR | [ ] The array declaration extends to column 183 (the limit is 80). The array content should be split up over multiple lines
 190 | ERROR | [ ] The array declaration extends to column 183 (the limit is 80). The array content should be split up over multiple lines
 222 | ERROR | [x] Expected one space after the comma, 0 found

I've added some fixes to 3192291-whitelist-ip-17.patch with hook_update and code formatting + changed the service decorator.
I think the 'flood' service (not user.flood_control) should be decorated here, because some core controllers and services (for example, basic_auth.authentication.basic_auth) use 'flood' exactly and decorating user.flood_control for them will not affect.
Problem is here https://www.drupal.org/project/drupal/issues/3368317 🐛 Use flood control instead of flood Needs work .

I rerolled this patch because it did not apply anymore

There are still some issues with this:

1. phpcs:

FILE: /var/www/html/web/modules/contrib/flood_control/src/FloodWhiteList.php
----------------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
----------------------------------------------------------------------------
 27 | ERROR | Parameter $request_stack is not described in comment
----------------------------------------------------------------------------

2. the isIpWhitelisted method could do with some inline documentation to explain what is happening (see also #18)

Hereby the requested changed from Batigolix.

This has been merged. Thanks everybody for the contributions!

Hi, any chance we can get this released to an official version soon? I'm in need of this feature, would be best to get it in a release rather than applying the patch.

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

@batigolix: Same requirement here as @longmtran. Could you perhaps tag a new release containing this?

That would be awesome :)

I've just created a new release. It was time to, I agree ;-)

Great! :) Thank you @fabianderijk