I administer a site that has open user registration, but requires email verification, has a number of required user profile fields in the user registration form, and is protected by mollom text analysis (retain).

Like others (see #632288: Fighting human-generated (not automated) spam attacks, I'm seeing a lot of user registrations that appear to be generated by real humans, yet the information they post in their required profile fields in the user registration form is clearly spam. However, NO records are created in the mollom table for these (or any) user registration forms showing they have undergone mollom text analysis or been identified as ham or spam.

I've worked with Mollom directly, but we have traced this issue back to the drupal mollom module as it appears it may not be successfully analyzing profile fields in the user registration form.

Drupal 6.20 | MySQL database 5.0.51a | PHP 5.1.6 | Web server Apache/2.2.3 (CentOS)

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

sun’s picture

Status: Active » Needs work
FileSize
844 bytes

Actually, I already created a test for this (though for HEAD/D7) and wasn't able to reproduce it.

Might be possible that D6 behaves differently.

sun’s picture

Version: 6.x-1.15 » 6.x-1.x-dev
Status: Needs work » Needs review
FileSize
870 bytes

Backported for D6. Let's see what the testbot says.

Status: Needs review » Needs work

The last submitted patch, mollom-DRUPAL-6--1.profile-register-test.2.patch, failed testing.

cgrant3d’s picture

I seem to be running into something similar. Lots of human spam in user profile fields but I'm not seeing evidence in the logs of users ever being challenged by mollom.

D6.20, Mollom 1.15

Chris

happysnowmantech’s picture

Subscribe - same problem here

sun’s picture

Status: Needs work » Needs review
FileSize
1.79 KB

Alright - attached patch should fix this issue.

sun’s picture

sun’s picture

Status: Needs review » Reviewed & tested by the community
Dries’s picture

The reported problem is that not all fake user registrations are blocked. The patch doesn't fix that problem -- thus, I'm not actually sure that we need this patch.

Storing the Mollom session ID for newly created users is useful to report feedback to Mollom -- in the case of users, there is no way to give feedback to Mollom. Unless I misunderstood the purpose of this patch, it looks like it might just introduce unnecessary performance overhead.

We log user registrations in the watchdog; you should be able to tell whether Mollom analyses user registration requests.

I'm tempted to mark this issue "won't fix".

sun’s picture

@Dries: From the OP:

However, NO records are created in the mollom table

The primary topic of this issue is that we do not store Mollom data in {mollom} for users.

This issue was originally derived from a Zendesk support ticket. Over there, it was unclear whether (and how) Mollom checked user registrations (at all), and @xolotl wasn't able to find any records for newly registered users in the {mollom} data table.

To report user registration spam, the module integrates with the delete confirmation form of user accounts (at least in D7). We definitely want and need to fix this bug, since you are not able to send feedback for user profiles to Mollom otherwise.

There's no performance impact involved, since the code in this hook_user() implementation only runs when we have corresponding data from a form submission in the global $mollom variable. In other cases, no operation is performed.

Of course, this patch will have to be forwarded-ported.

Dries’s picture

In D6, you can't report user accounts as spam. That functionality was only added to D7.

Because you can't report users accounts as spam in D6, I'm not sure this patch makes sense for D6.

Because of D7's entity API, this bug might not exist in D7. As a next step, we should verify that -- I haven't verified it. It sounds like you suggest it might be a problem -- yet the patch is against D6

Ideally, we'd not have to implement hook_user() in D7. It is much better to leverage the more generic entity API so that it automatically works in all cases, including for user objects.

Thoughts?

sun’s picture

Version: 6.x-1.x-dev » 7.x-1.x-dev
Priority: Normal » Minor
Status: Reviewed & tested by the community » Needs work
neclimdul’s picture

I think I found this patch while investigating a spammy user registration to see what mollom had done. Since there wasn't any history of the form submission in the mollom table in d6 I wasn't really able to tell my boss anything. I must admit, I haven't had reason to use it since applying the patch in #6 so I don't know how useful it actually would have been though.

sun’s picture

Version: 7.x-1.x-dev » 7.x-2.x-dev
Status: Needs work » Fixed

Sorry for the late reply.

This is definitely fixed in the latest 7.x-2.x version by now.

Status: Fixed » Closed (fixed)

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