I was excited when I read that "Mollom can now protect all your webforms". I was disappointed when I found out that it actually should have been "Mollom can for each of your webforms be configured to protect it".

I have a website where new webforms are created automatically (e.g. subscription forms for events), and it's a real bummer that I have to manually configure protection for every single webform.

Is there any way, or are there any plans to make it possible, to just tell Mollom to "protect all webforms", or "protect new webforms by default", or "protect new webforms by default: yes/no", or anything like that?

Comments

danwonac’s picture

On a typical small site we configure mollom and the site admins don't have to deal with it. However, with a webform-enabled content type each new content requires mollom protection to be added. This means that either the admins need access to the mollom module and have to configure protection for each form or we need to configure it each time new content is added.

Given that each webform-enabled content type has default webform fields, would a possible solution be to protect such content forms using mollom configured on the default webform?

I imagine this would require checking for mollom configured for that content's webform. If it is not protected with mollom, check whether the default webform for that content type is protected.

Perhaps this should be in the webform issues queue?

P3t3r’s picture

Non-admins are also allowed to create new instances of webform-enabled content types. This is a default option in the Webform API, I don't see why you presume that this is something only admins can do. And I obviously cannot require my users to configure Mollom for their created content...

Yes, using the default webform fields seems a big leap ahead, since content types cannot be created on-the-fly by regular users, unlike instances of webform-enabled content types.

If you can convince the Webform people to work on this, feel free, but I guess they will just point anyone asking this to their public API and tell them 'do it yourself'. After all, Mollom claims compatibility with Webform, not vice versa. Either way, if you want to keep the claim that "Mollom can now protect all your webforms", I think you should really fix this issue, since now it is misleading.

mrP’s picture

Title: Protect ALL webforms? » Protect ALL forms
Version: 7.x-2.2 » 7.x-2.x-dev

I've got to +1 this issue. Every new site I build, this is a common 'must-do task'. Sure it could be a simple feature, but I see no reason why mollom shouldn't be able to protect all forms, by default.

I'm sure this has been brought up before -- so sorry for duplication in advance. Its worth revisiting.

sun’s picture

Title: Protect ALL forms » Protect all webforms

Yes, this has been asked for in the past already.

The fundamental problem is that you should NOT check/send user input containing sensitive data to Mollom. For example, credit card numbers, passwords, etc.pp.

That said, the Mollom service is bound to very strict Belgian/European laws. The submitted data is used for statistical analysis only.

However, even though the data is stored for a very limited time-frame only, that already imposes a problem for things like credit card numbers.

Furthermore, for the vast majority of (free/unpaid) sites/users, the communication between your site and the Mollom servers is not secured via SSL (only available for paid subscriptions).

Thus, if there was a "wildcard" protection for all current and future webforms, then there'd be a very high chance for unintentionally exposing/leaking sensitive user input in various ways to Mollom, or alternatively, to malicious hackers.

I hope this helps to explain why that is not possible currently. Don't get me wrong though; I certainly and absolutely agree that the requirement to manually set up the Mollom protection (and fields to be checked) is cumbersome and anything but good UX.

From a Mollom module perspective, we're missing a native API and framework provided by Drupal core, which would allow the module to automatically identify 1) which fields are accepting free text input from users, and 2) which out of those do not contain sensitive data.

My current hope is that D8's entirely new core API for Typed Data will potentially resolve this problem. It should allow the module to automatically identify all text fields. However, AFAIK, it doesn't contain any means for declaring "sensitive" input either (yet).

In short, automating this boils down to having a proper and complete declaration of available data, so the Mollom module can reliably and securely choose and check the data that is safe to check under all circumstances.

mrP’s picture

Status: Active » Postponed

I really appreciate such a detailed response to the issues at hand in achieving this feature request. Thank you sun.

We'll have to see what the future holds with D8 then.