The current Fallback strategy section leaves me feeling a little vulnerable. I have to choose between either blocking new content to my site or allowing all content to go by unprotected. I would like to be able to select an option that would instead show a CAPTCHA to every visitor to the site.

I believe that the current CAPTCHAs come from the Mollom.com server itself, so in this case of a network outage, the CAPTCHA would have to come from a module installed on my site. Fortunately there are some good options for that within the contrib repository already.

So, I guess this is a request for the Mollom module to have an API which allows others modules to add themselves in as options for blocking content in the case that the Mollom servers are unavailable.

Comments

greggles’s picture

Title: Use preventive CAPTCHA for all users » Provide API for other modules to block content in case Mollom's servers are unavailable

Heh. After entering the title and starting the post I changed my mind on what the best way was to implement this was... updating title.

greggles’s picture

See http://groups.drupal.org/node/11106 as the motivation for this.

Walt Esquivel’s picture

Resolving the spam issue on g.d.o has been somewhat elusive for quite some time now. Moshe and company have made various noble attempts and have been very open with the community in trying to find a good solution. There are numerous threads documenting the various issues encountered with different spam modules, not to mention the frustration. :)

I'm not smart enough to recall all the different spam modules previously used on g.d.o, and I don't know to what degree Mollom may be better than the other spam modules, but I do know that I'm frustrated at not being able to post content as a group manager and I do know that not being able to post content due to Mollom being unavailable is an issue for the membership of at least one of my groups, the Contributed Module Status group (it just happens to be the largest group on g.d.o with almost 1,790 members as of today, so the need to find a solution is important to me).

I started http://groups.drupal.org/node/11106 to identify a problem with the spam module on g.d.o and I've already made a few thoughts known there. If I "have to choose between either blocking new content to my site or allowing all content to go by unprotected", I'm pretty sure I would choose the latter until such time as the site was fixed because there's one thing I hate more than spam, and that's not being able to post content. :) I feel like I'm being punished on the change that there might be some spammer waiting around for Mollom to become "unavailable". The truth is that when spam gets posted at g.d.o and I come across it, I simply delete it, and I would do the same on my web site. Not allowing folks to post because Mollom is down is not, IMO, the better solution. It would be interesting to know how many honest users were turned away vs. how many spammners were thwarted during the time that Mollom was down, and, although we probably can't get that data, it's probably safe to say that more honest users, such as me, were turned away than spammers were thwarted. So who is being punished here, the honest members or the spammers? I'd say the honest members.

The bottom line is that I agree with greggles in having some type of alternative for when Mollom goes down. What I don't get about Mollom is that one minute it rejects my attempted post to a wiki-like page on g.d.o, and the very next minute it allows me to post a comment. I go back to try and post to the wiki-like page a minute later and it turns me down again. It seems like Mollom isn't consistent in how it treats content. Maybe it's an issue that deals more with the specific type of content being posted? Maybe we need a poll to see if specific types of content are being rejected?

I'll leave this issue to the smart folks. :) Thanks for listening.

Senpai’s picture

@geggles:

... a request for the Mollom module to have an API which allows others modules to add themselves in as options for blocking content in the case that the Mollom servers are unavailable.

It would seem to me that forcing Mollom to parse for other modules that might be available to handle user validation if the Mollom servers aren't responding is extra overhead. What we could do instead is look for the failure of Mollom's nodeapi hook, and pass off to another module of our choosing? A boolean failover would seem to be faster than an API that allows other modules to hook into Mollom, which is itself a contrib module.

Now that nodeapi is being re-written to remove the $op, something that allows for a captcha-type system to intervene before hook_node_insert triggers would be just the thing. We all know that spam-prevention is a necessity these days, and if nodeapi could provide the boolean failover in a cascading, module-weighted fashion, that'd be cool.

Mollom is active
Mollom triggers on form submit
Mollom returns a FALSE (servers are down)
Any other module that hooks into node_insert can now do their thing, but only in the order of module weight, and only if another module hasn't already had a TRUE.

What do you think? Too far-fetched?

greggles’s picture

@senpai - I don't have a strong feeling about how it should be done. Whether it's an API or some boolean that is added somewhere or...doesn't matter. Note that node_insert is just one scenario where you might want to present a captcha, though, so under your system the modules would have to coordinate on basically any form. If mollom had an API then it would be a single integration point.

Dave Reid’s picture

Marked #343551: Fallback option: Captcha module as a duplicate of this issue.

cimo’s picture

Hi
I missed this thread and wrote that duplicated issue.. I think this is an important missing feature, in my case my site went down to a DDS, the hosting company moved my site to a special ddo server to contain the attack, that stopped my site from being able to make outwards http requests, so no Mollom server available, no spam protection ... rather an evil chain ...
thanks
Simone

TravisCarden’s picture

Version: 6.x-1.x-dev » 7.x-2.x-dev

This is a good idea. Bumping it up to 7.x where it may get more attention.