Open purplespider opened 10 years ago
Think I finally got to the bottom of this.
The response from the Mollom API for the comments that were incorrectly accepted despite being marked as spam all started with HTTP/1.1 100 Continue
followed by the HTTP/1.1 200 OK
.
It appears it was this unexpected 100
code the caused the response to be incorrectly parsed by the SilverStripe Mollom module.
In PR #24 I've added an Expect
header to the request that stops Mollom from returning these occasional 100
's in the response. Been running it for a couple of weeks and not had a single spam comment accepted!
For several months now my blog has been receiving spam comments, despite being protected the Mollom module.
After some initial debugging I discovered that Mollom was correctly detecting the comments as ‘spam’ but they were still being posted to the site.
I initially believed the problem was due to some incorrectly formatted responses from the Mollom servers that the Mollom PHP script and SilverStripe Mollom module is unable to read correctly.
So I sent this info to Mollom to investigate. (But see their response below)
On line 1186 of Mollom.class.inc ( https://github.com/Mollom/MollomPHP/blob/master/mollom.class.inc#L1186 ) I inserted a mail() statement to obtain the contents of the $result array whenever a comment was submitted.
I put Mollom in testing mode, and made a test ‘spam’ comment, the comment was correctly marked as spam and the $request array correctly looked like this:
I then turned off testing mode, and waited for the next spam comment to come in. When it did, the array was empty, and the spam comment was incorrectly accepted:
With some further mail() statements throughout Mollom.inc.php and the SilverStripe Mollom Module. I managed to obtain more details about the response that came back from Mollom.
For my test spam comment (with test mode on) the response looked like this:
But for the real (with test mode off) spam comment (ID: 140509784898bf6cf8), the response looked like this:
As you can see, in that last response, the ‘body’ seems to contain the header information, and the ‘headers’ key is empty. Whereas when testing mode was turned on, the ‘body’ just contained information about the spam request and the headers were correctly in the ‘headers’ key.
I believed it is the presence of these headers in the ‘body’ of the response whenever a comment is detected as spam that is causing the Mollom modules to be unable to read the response, and therefore it isn’t marking the spam comments as spam.
However Mollom support responded with the following:
So they are saying it's a problem with the SilverStripe Mollom module.
Any idea's what's causing this?