Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Looking in http://api.drupal.org/api/drupal/modules%21user%21user.module/function/u... we can see that there a 2 kind of validations on user:
- Pure UID: Drupal validate only against user. This is the most strict.
- UID+IP: Drupal checks by this pair. This is used as it is safe enough but more practical because avoids locking out public users.
Drupal defaults to the second one. The purpose of this module is to unlock flood variables and let admins configure them.
Add also user_failed_login_identifier_uid_only
to form.
Comment | File | Size | Author |
---|---|---|---|
#4 | flood_control-uid_identifier_variable-4.patch | 1.25 KB | heddn |
Comments
Comment #1
abautu CreditAttribution: abautu commentedAttaching a patch for this feature.
Comment #2
claudiu.cristeartbc
Comment #2.0
claudiu.cristeaTypo
Comment #3
crystaldawn CreditAttribution: crystaldawn commentedI think this is probably out of scope for this particular project, but it might make sense as a feature request for cbp (which uses this module here as a dependency for the flood settings themselves).
Comment #4
heddnRTBC from me. It makes sense to expose the ability to configure the flood logging identifier in flood_control. However, attaching a re-roll to make things go easier. The current patch didn't want to apply cleanly.
Comment #5
joelpittetRTBC++ thanks for fixing the patch. The trick looks like #1 forgot
--relative
flag when creating the patch inside their drupal site.Comment #6
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedMaybe it would be good to explain this in a way that explains both the pros and cons. For example, from the code comments in Drupal core about this, if you read both code comments you can get a sense of the relative pros/cons:
Comment #7
batigolixI close this because it is a request for the 7.x version.