Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Spin-off from #1020072: Rethink/simplify UI to protect/configure a form
To aid in fighting user registration spam and other edge-case scenarios, we have two new configurable parameters:
rate_limit
(seconds): A configurable time interval (in seconds) that needs to elapse since the last form submission attempt that has been checked by Mollom across all sites in the Mollom network, before the same author can submit the form.For example, it is unlikely that someone registers more than one user account on different sites within, say, an hour. Thus, you could configure a one hour treshold here, to prevent a spambot from registering on your site, in case that bot attempted to register user accounts on other sites in the Mollom network within the past hour.
strictness
(high, medium [default], low): Allows to tune the strictness of the different checks that Mollom is performing (eg. the reputation of the author, the URLs, ...) For trusted users we could e.g. use the low value.
Comment | File | Size | Author |
---|---|---|---|
#12 | mollom.strictness.12.patch | 4.29 KB | sun |
#9 | mollom.strictness.9.patch | 4.4 KB | sun |
#8 | mollom.strictness.8.patch | 3.27 KB | sun |
#4 | mollom.ratelimit.4.patch | 5.4 KB | sun |
#4 | mollom-ratelimit-4.png | 29.89 KB | sun |
Comments
Comment #2
sunI'm told that testbot doesn't like --no-prefix anymore; trying again.
Comment #3
sunUI review:
Comment #4
sunNew patch, new screenshot:
(Note, I've tweaked the other text analysis form labels, too -- it visually helps to "visually group" them by repeating at least the term "Text" [the elements are still shown for text analysis only])
Comment #5
Dries CreditAttribution: Dries commentedWould be great if the variable names where more consistent with the UI strings?
Maybe call this 'Maximum submission interval' and just add a description?
If we call this 'Submission interval' in the UI, we might want to rename the variable too?
That feels like a bit of a hack?
We're still missing tests.
Comment #6
sunThe current internal names directly map 1:1 to Mollom API parameters, which I think is a good idea, because it means less (or actually no) translation of stored Drupal values into Mollom API values.
Actually I spent a little time with Wiktionary to double-check and finally find the most concise term with "period". The latest patch basically moves the old label into the description, and uses a precise label.
Yeah, could probably use a code comment. The idea/intention was to explicitly differ between "Use Mollom's rate_limit default whatever that is", and an explicit "0", which may or may not have some meaning in the future (we don't know yet), so as to be able to safely update it in the future. Therefore, the database column for the rate_limit option allows to store NULL, and the conversion from non-selected option to NULL is what we see in this snippet.
Hm - as mentioned elsewhere already, these two parameters cannot really be tested with the current capabilities of Mollom's testing mode, since they solely affect the behavior of the Mollom backend -- which is something the Drupal module is not able to (and probably should not attempt to) test.
The only part that we can test basically is that we're sending the parameters (or not), I think.
Comment #7
Dries CreditAttribution: Dries commentedUnderstood. Let's talk about it with the rest of the Mollom team -- it might make sense to change the Mollom API parameters? Just a thought.
Comment #8
sunThe strictness parameter values have been changed to strict/normal/relaxed in the Mollom API.
However, we are not going to add the rate_limit option to the current XML-RPC-based Drupal module. The reason for that is that we are unable to tell the user why his correctly entered CAPTCHA solution is not correct. That's unacceptable, and therefore, rate_limit needs to wait for the REST API implementation. (Further details may be found in Mollom's internal issue tracker.)
Attached patch adds the strictness option only.
Comment #9
sunAdded assertion to the Data test case to verify that strictness parameter is sent.
Comment #10
Dries CreditAttribution: Dries commentedThe patch in #9 looks good to me! :)
Comment #11
Dries CreditAttribution: Dries commentedReviewed again and still looks good.
Committed to 'master' (7.x) and '7.x-rest'. Will need to be backported to Drupal 6.
Comment #12
sunBackported to D6.
Discovered a small glitch in the D7 module update; will fix that afterwards.
Comment #13
sunApparently, I'm not sure what happened in #11, but neither the master nor 7.x-rest branch contained this change. Perhaps you committed, but didn't push?
Anyway, in this case even beneficial, as this allowed me to fix the small glitch in the module update.
Committed to master (+ merged into 7.x-rest), and also committed to 6.x-1.x now.