Allow to protect forms without text fields with text analysis without resorting to CAPTCHA (e.g., user registration form)

+1

+1

I would like to add some thoughts here as we've seen some pretty heavy SPAM user accounts on opensource.com. At our peak, we were getting several per minute, thankfully, that's subsided. Now were down to a certain few [spam accounts] a day and others that are questionable [because they look suspicious and never complete the registration process].

In our findings, we believe that a lot of this is caused for blackhat SEO purposes, the spam accounts are just trying to get a link on the site.

I think one solution to this would be to have a common database of emails detected as spam. For example, if we block a user on our site (ideally, there would be an option for block user as spam), feedback is sent to mollom to collect these addresses. There is a threshold each site could set, say we set our variable at 10. If 10 other sites have marked the email as spam, their unable to complete the registration form on our site. Collectively, all Drupal sites using mollom could help build up this database, but have the flexibility to 1) use it for user registration (and probably commenting) and 2) control the threshold variable.

I'd love to hear other peoples thoughts about this idea and if it would work.

I imagine that a lot of the higher traffic sites would still get hit, but maybe this solution helps everyone, especially the longtail of sites with less registration traffic.

Regards,
Jason

+1 for this.

Let's see how far we get. I expect a couple of failures in tests which verify that this isn't possible currently.

Removed the assertions from tests.

Adding tests required me to include fixes for #1034442: no records of user registration form text analysis in mollom db table

The new tests will throw test failures, since the Mollom backend needs to be adjusted first.

+++ b/mollom.install
@@ -172,6 +172,7 @@ function mollom_schema() {
+        // @todo Change to NULL.

Moved these todos into #1818458: Remove {mollom} schema default values for reason and languages

For now, I'll comment out the failing tests, since this patch can technically land before the Mollom API officially supports this.

That said, we need to make sure (as in: test) that the suggested protection mode for the user registration/profile form defaults to CAPTCHA. Done so in attached patch.

Further testing also revealed that reporting user accounts is broken currently. Had to invent a new 'report path' concept for reporting entities through a report link in an e-mail notification. Added tests and docs for that.

For the sake of patch reviews, here's #12 ignoring white-space changes.

Committed and pushed #12 to 7.x-2.x.

Attached patch removes the commented out test assertions, which will pass as soon as Mollom's REST Testing API has been updated.

Now including additional tests for the hosted Mollom moderation system integration.

#14: mollom.user-analysis-type-test.14.patch queued for re-testing.

Re-rolled #16 against HEAD, and removed the Mollom server override for the tests.

Looks like the testing server responses are not fixed yet.

All tests are passing locally for me as of today.

Final adjustments.

Thanks for reporting, reviewing, and testing! Committed to 7.x-2.x.

A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.

We might want to consider to backport this to 6.x-2.x, but not planning to do that for now.

First pass. Only includes #12.

I expect (tons of) test failures, but let's see.

Hrm... this is quite the challenge to backport to D6 :)

Backported the hook_entity_CRUD() functions from D7 to D6 as private functions, and invoking them from the individual API integration hooks now. Seems to work fine in manual testing. Let's see how this affects tests.

Oh wow, I just spotted this fancy gimmick in D6's user_register_submit():

  if (!$admin && array_intersect(array_keys($form_state['values']), array('uid', 'roles', 'init', 'session', 'status'))) {
    watchdog('security', 'Detected malicious attempt to alter protected user fields.', array(), WATCHDOG_WARNING);
    $form_state['redirect'] = 'user/register';
    return;
  }

user_save() does not invoke a hook prior to inserting the new user record.

These two issues combined unfortunately mean that this facility cannot be backported. :-/

However, I will still backport the architectural changes, since those are helpful for the Mollom moderation system integration, because those are already done now, and in general, keeping the code in sync between D7 and D6 simplifies future backports.

Committed and pushed to 6.x-2.x.

Now the follow-up patch from #25.

Committed and pushed to 6.x-2.x.