This problem has been reported by one of our clients on a Drupal 6 site. They received many complaints from users that they were filling in CAPTCHAs correctly, but they were being told they were wrong. The number of complaints seemed to outweigh the possibility that it's just certain users who had mistyped a CAPTCHA.
We hacked the mollom module to intercept and log all mollom-served CAPTCHA images alongside the users' solutions. We did this by having the website request the CAPTCHA image from mollom, and serve it to the user.
We are finding that in more than 50% of the cases where mollom CAPTCHAs have been incorrectly solved, the image appears to be an exact match to what the user has entered, suggesting that mollom is getting it wrong.
I should note that we are using mollom on dozens of other sites, and none of the others have any reported issues.
I have no idea what the next step might be in identifying this problem, but there is definitely something wrong here so is there any way for us to find out what might be causing this?
Comment | File | Size | Author |
---|---|---|---|
#10 | mollom.readme.patch | 5.47 KB | sun |
Comments
Comment #1
sunIs your site sending correct author IP addresses to Mollom?
Comment #2
sunSorry, without further information this issue can only be closed as not reproducible.
Feel free to re-open this issue if you want to provide further information. Thanks.
Comment #3
chriscohen CreditAttribution: chriscohen commentedSorry for the delayed response. The site is not changing the IP it uses to submit to Mollom, so whatever the module default is, it will still be using that.
Could you explain what effect the author IP address has and how it might affect this issue?
Comment #4
sunYour site needs to send the actual IP addresses of your site visitors to Mollom.
When you look into your Drupal logs, do you see different IP addresses for your site visitors?
In case you see different + actual IP addresses of visitors, can you supply a couple of session/captcha IDs of affected form submission attempts? You can find them in your Drupal logs (you can filter by category "mollom").
All of that being said, this issue does not seem to pertain to the functionality of the Drupal module, but rather the Mollom service. However, I can forward the session IDs to Mollom Support.
Comment #5
chriscohen CreditAttribution: chriscohen commentedThe IP addresses are correctly listed in the Mollom logs. Thanks for pointing out where to find this.
I have another theory that might explain this, which is that these IPs appear to correspond to known spammer addresses. What is the default behaviour when Mollom knows that the CAPTCHA is solved correctly but that the solution comes from a known spammer? Will it simply be rejected with no explanation, or is there more?
Comment #6
sunIf can you provide some recent session IDs, then we don't need to make any assumptions or theories.
That said, could you try whether the latest development snapshot makes any difference?
Comment #7
johnmcgeechan CreditAttribution: johnmcgeechan commentedOk if you are not running a reverse proxy like varnish, then read no further...
If you are, then ensure that you have this in settings.php. It took us about a day to to figure out that that was causing legitimate captcha entries to "fail" in Mollom..
if you need to see the full details of this you can see it at..
http://simpleritsolutions.com/drupal/mollom/proxyservers
Hope it helps...
Comment #8
chriscohen CreditAttribution: chriscohen commentedThanks johnmcgeechan. Is this settings.php solution for Drupal 6, or Drupal 7? We're specifically having this problem with a Drupal 6 site.
Comment #9
sunYes, this also applies to Drupal 6.
The configuration variables are extensively documented in
sites/default/default.settings.php
, both for D7 and D6.Comment #10
sunThat said, we can do more. :)
I wasn't aware of the poor state of the INSTALL.txt file... didn't look at that file for a very long time.
Attached patch completely rewrites the file into a new README.txt, and makes it include the bare essential information everyone should be aware of when setting up the Mollom module.
Comment #11
sunThanks for reporting! Committed to 7.x-2.x and backported to 6.x-2.x.
A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.
Comment #12
chriscohen CreditAttribution: chriscohen commentedThanks for the patch. Would anyone be able to show me how I can verify that the lack of this stuff in settings.php is causing this fault with Mollom?
In our own testing of this site, we cannot reproduce the bug, so it's not something that happens every time, or even very often. We've also only ever had reports of this problem on this one site, despite running many other Drupal 6 sites with Mollom. So it makes me believe that our own varnish config is fine, without the settings.php change. I'd be interested to know how a settings.php change would affect Mollom's behaviour here and if it would fix this issue, and if so, how we'd verify it.