The configured Mollom API keys are invalid.

subscribing. same issue, been trying to debug for several weeks, no luck.
my site was working w/ mollom for a few (4) days. then it just stopped...

these are various attempts at fixes i've tried, from searching the web and talking to mollom:
i've set the server clock to synch w/ time.nist.gov
i've whitelisted all servers, per mollom's support suggestions
i've manually deleted, and then manually re-installed.
i've deleted my account, then re-registered with new keys.

still not working...

i'm running out of debug solutions.

hope someone can help. my site is getting killed with spam... and i've tried all other services. this *was* the only one that worked.

i just heard this from my service provider. Any additional comments? Does this require SSH?

Please be aware that we do not provide white listing for all IP protocols and services on your server. Specifically we do not allow outside SSH access. However, if these hosts needs external access to a specific service, such as MySQL, we would be happy to accommodate this request. Please be aware that your server already has allow rules for ports 21,25,80,443,110,143,995, and 993 so specifically white listing hosts for services on these ports is not necessary.

Please respond with a list of ports, or services, which you need these hosts white listed for and we would be happy to review your request further.

1.5 months later and still no response from the Mollom team? This is getting silly. Better look for spamfilters that can actually be used... :/

Have you tried registering again to generate new keys?

FWIW, I downloaded Mollom and installed for the first time last week and everything works as described.

Same problem here, tried removing the module and reinstalling but no success. Also tried removing site in Mollom's site manager to regenerate keys but still nothing.

Mostly this error caused by too high offset of server's time.

The server time was the problem for me, solved it yesterday by installing ntp on our servers to prevent this from happening again. See http://www.cyberciti.biz/faq/howto-install-ntp-to-synchronize-server-clock/ for details.

Updated my VPS TimeZone (Ntp + cPanel/PHP to Europe/London)
Recreate subscription for serveer
.....but still complaining about invalid API Keys.

#8 post did the trick here.....thanks

Same issue - I have another Drupal site on the same server where the Mollom keys are working so it has nothing to do with my server setup.

Hi all,

The latest development snapshot 7.x-2.x-dev contains some additional error handling for this case, and automatically tries to provide more concise error messages, in case a particular cause can be detected.

Could you try whether the latest development snapshot makes any difference? You can download it here: http://drupal.org/node/1226128

Thanks,
sun

I'm using the Drupal 6 version, but going by comments above and elsewhere, it appears that what I'm about to talk about applies to both the D6 and D7 versions of this module.

I believe there is a much-overlooked aspect to this issue that will not be fixed by the additional error handling mentioned in #12. Allow me to explain.

After the service works fine for months I notice more spam creeping through than before. Have the bots cracked Mollom, I wonder? Or maybe it's just one of the ebbs and flows of the spam bot tides?

Then I go to my site and see my formerly verified Mollom API keys are now inexplicably invalid, something not true of any other service I use that requires API keys. How after all these months of working fine did my API keys cease working, without me receiving any notification of this... aside from the spike in spam that is?

And the new spam is not a deluge because I use a couple of other methods of blocking spam and I see that they have been really busy of late. So it certainly seems like maybe Mollom silently stopped working... merely because my server time was 5 minutes different to NTP? And yet I'm given no notification? Service terminated for a minor violation of the temporal prime directive?

Even when handling spam comments and webform posts and clicking on the "Report to Mollom" options, I was never told that Mollom was no longer working right or that API keys had suddenly become an issue. It's only because I periodically check the Drupal status report that I even found out that Mollom had just stopped working.

Going to Mollom.com I see from my stats that Mollom appears to have silently stopped recording any spam blocking stats 12 days ago on January 27th. Then I look at all the bot-created user accounts and sure enough I see a large spike in them after Jan 27th... and the spike in spam posting bots cracking Mollom also happens after Jan 27. It certainly appears that there is circumstantial evidence that Mollom silently stopped working merely because my server's time was not using NTP. At best Mollom stopped reporting stats at that time, but it appears to be worse than that, at a minimum some sore of diminished effectiveness.

So it seems to me that Mollom should not simply stop working as expected at all, as that seems like a large failure to me. At a minimum this Module should surely at least let me know in some way? A notification by email would be preferable, but I'd be happy to at least be notified when I'm doing any kind of "report to Mollom" activity, be it on a spammy comment or a webform submission or what have you. Silently failing for something as vague and out of my control as server time seems an odd criteria at best, but now I find myself wondering what other odd criteria do I have to worry about and whether Mollom will again fail silently due to some new issue?

Therefore, I would request that while you're improving messages and error reporting that you find some way of letting us know that a service that we have no reason to think will ever just stop working... has just stopped working.

P.S. I really appreciate this module and Mollom as until this time it was a big improvement over ReCAPTCHA, plus Mollom makes the service free to nonprofits like mine, so my thanks to all of you.

@grantkruger:

Thanks for your feedback. You're making some bold claims there, which I'll have to verify. Technically, every web service API that is based on OAuth - which means Twitter, Facebook, Google, etc.pp. - has the same server time constraint, since that is a fundamental (security) part of the OAuth protocol.

In case you were right, that would mean that all of those other RESTful web service APIs are either not validating the OAuth signature timestamp, or they're allowing for much larger server time offsets (but which, in turn, would only defer the problem to later; i.e., instead of breaking communication after an offset of 5 minutes, it would happen with an offset of 15 or more minutes).

Since the OAuth protocol clearly defines the server time/request timestamp validation as a requirement in its standard specification, I doubt that other services/implementations are blatantly ignoring it. However, I will certainly admit that I/we did not test this particular aspect against other web service APIs during the design process of Mollom's REST API; i.e., we did not try whether other popular web services are accepting and processing requests despite a too large local server time offset.

In general though, synchronizing time with world clocks is not something that anyone should have to worry about. To provide an additional data point: So far, this issue only occurred for users that are installing and maintaining their own root servers, which, unfortunately, inherently means that the server was not properly set up. We've never seen this issue being reported by users whose sites are running on managed servers, virtual servers, or shared hosting. Typically, these environments are properly prepared by server administrators already.

It feels a bit strange to me to debate about something as essential as time — Time can only be correct (synchronized) or it's not. If it's not: Problems. There are probably a dozen of ways to interpret this as well as technical and non-technical situations to which it applies, but the effective result is always the same: The entire world order would break down if time wasn't synchronized.

From the Mollom module perspective, this is definitely not something the module/application-layer wants to worry about. Time is expected to a be given fact and to work correctly. Personally, I'm surprised that people are complaining about Mollom, when, in reality, they're actually experiencing larger time offsets all across the board of their sites; i.e., in their log messages, in scheduled cron jobs, in scheduled actions, in e-mail headers, etc.pp.

Anyway, back to the point:

1) We've improved the error reporting for D7 already, and we'll backport that in this issue.

2) I'll try to verify how other web service APIs are reacting to a too large server time/timestamp offset, and if applicable, discuss the results with Mollom's backend engineering team.

Thanks for your feedback,
sun

@sun

Thanks for a very informative and detailed reply. This is not an area of expertise for myself and nor is the sysadmin stuff. It does appear to have been a simple oversight on the part of our SysAdmin who is really very good, and he too sees it as a given and was quite surprised to see that we were, um, out of time. He fixed it in moments.

I still feel that there should be some notification that a service that was working has stopped working, maybe because I'm old school and my code always includes defensive checks and reports on most exceptions with some detail, but also because I think any time a service fails silently that is not a good thing. And it does appear that Mollom did fail silently. I say appear because 3 days is not much of a data sample (time since the temporal prime directive was adhered to), but in that time there have been no bot registrations and no spam posts, i.e. an apparent marked improvement. At the same time Mollom statistics resumed and immediately reported spam being blocked and ham being allowed.

And I know you have a point about time being essential, but I go to Drupal user groups all the time and there are a ton of guys setting up their own servers and maybe forgetting a thing or two. That and the significant number of people on this and other threads with the same issue at least highlights that this is not rare and worth some consideration, and clearly you agree at least in part because you made some changed to the D7m module's reporting.

In answer to your other points, I'm not quite sure what services should fail at the same time and which ones would not, but as an example, Google Analytics still worked fine and I have stats for the same days as Mollom stopped working on my site. I offer that only in the hope that it is helpful.

I'm not sure if I can find the time as two projects are going full blast right now, but assuming I can find the time, is spiffing up the reporting something I could look into and offer a patch for, or is it something you're opposed to? My Drupal-Way know-how is limited and about 3 years out of date (a great testament to how stable my D6 site has been), but I can't imagine this would be too difficult (famous last words!). I'm thinking specifically about the "report to Mollom" occasions.

The latest releases of both D7 and D6 contain better error reporting for too large server time offsets now.

The server time always has to be synchronized with world clocks. If it is only synchronized once (instead of permanently through an ntp daemon), then it will diverge from UTC. Please ensure to synchronize your server time.

I still stand by #14:

This is not something you, the Mollom module, or anyone else should have to care about. If something very basic like server time is not synchronized, then what else was not set up correctly on your server? (I do not even want to know.)

So if you experience API key validation errors due to a too large server time offset, then the best and only recommendation I can give is to switch to a different and proper server provider.

In case you are your own provider/server administrator, then yes, this comment will sound offending to you. However, there's a minimal, lower end of DIY and there are also tons of freely available tutorials on the net that describe how to properly set up web server basics. This does not pertain to Drupal at all, but basic/trivial server administration only. So, I'm sorry if this sounds offending, but if you experience this error and your server administrator is not able to resolve it in a persistent way, then your server administrator should reconsider whether the task shouldn't be performed by someone else.

As a Mollom and/or general Drupal user, this is a problem that you should not have to deal with under any circumstances.

Thanks for your feedback!
sun

I agree with your comments on the server and the minimum standards one might expect. Nevertheless, I too stand by my belief that any remotely critical software should not ever fail silently. I also don't mean to offend when I say that I believe defensive code is a necessity, particularly when despite your assertion that we should not have to deal with such issues, the sheer number of people who still do illustrates that defensive code was needed.

Since the error was not mine but my sysadmin's I'm not remotely offended by your comments, but it also does seem to me that it's not really productive to deflect attention from a contingency-free silent failure onto us developers. Nevertheless, thank you so very much for your time and for the fixes. I greatly value this module and the Mollom service. The silent obfuscated failure means that I now fear other silent failures and keep a much closer eye on this module than any other module I use, but despite this, this module and service still save me a ton of time and frustration compared to the other options I used before. It is the single best weapon in my anti spam arsenal and I greatly appreciate all that you and the other coders responsible do on my behalf, so thank you and thanks also for your detailed response.

Just an FYI, this is happening to me only when I select testing mode. If I had previously added keys and also hit testing mode it deletes the keys I had.

-