Handle Mollom session via javascript like ReCAPTCHA does [#1142686]

I was working on a site with Mollom and full page CDN based caching. The contact form is set to show CAPTCHA always but anonymous users are unable to pass the CAPTCHA validation even if they enter the correct CAPTCHA text.

I would imagine that this issue would exist for boost based caching as well.

Would it be possible to have the CAPTCHA validation handled like in ReCAPTCHA where the CAPTCHA session is initialized via Javascript rather than from PHP?

Comments

Comment #1

sun

German

Karlsruhe

CreditAttribution: sun commented 6 May 2011 at 16:45

Category:	bug	» support
Status:	Active	» Postponed (maintainer needs more info)

No, that's not possible. The Mollom module actually tries hard to inform all kind of page caching modules that a page containing a CAPTCHA must not be cached:

    // Prevent the page cache from storing a form containing a CAPTCHA element.
    $GLOBALS['conf']['cache'] = CACHE_DISABLED;
    // Pressflow in CACHE_EXTERNAL caching mode additionally requires to mark
    // this request as non-cacheable to bypass external caches (e.g., Varnish).
    if (function_exists('drupal_page_is_cacheable')) {
      drupal_set_header('Cache-Control', 'no-cache, must-revalidate, post-check=0, pre-check=0', FALSE);
    }

All page caching modules need to respect the runtime configuration. In case there's anything we can do to also make your CDN/Boost use-case aware of this page caching override, I'd love to know that.

Comment #2

zyxware CreditAttribution: zyxware commented 6 May 2011 at 18:26

Title:	Mollom CAPTCHA does not seem to work with full page caching	» Handle Mollom session via javascript like ReCAPTCHA does
Category:	support	» feature
Priority:	Normal	» Minor
Status:	Postponed (maintainer needs more info)	» Active

I have more information regarding this. The site uses a CDN service that offers only minimal configuration options. The only caching related configuration that is available is setting a string which if present in a cookie in a request will prevent caching of the response of that particular request. This works fine because POST requests are custom handled and the nocache cookie is set before the drupal_goto so that the next request which contains output related to the post will be requested with nocache. The nocache cookie is reset with every request. So perhaps the issue is only specific to the site at hand.

I am changing the request to a feature request though to allow for ReCAPTCHA like operation.

Comment #3

sun

German

Karlsruhe

CreditAttribution: sun commented 6 May 2011 at 19:04

Category:	feature	» support
Priority:	Minor	» Normal
Status:	Active	» Fixed

Sorry, but a "ReCAPTCHA alike operation" is impossible to do for the Mollom module, since CAPTCHAs issued by the Mollom service are based on user "sessions". This means that Mollom CAPTCHAs are stateful, and once requested/solved, they are no longer valid (and the same CAPTCHA cannot be solved more than once).

For that sake, the Mollom module has to request a new CAPTCHA resource/URL when the form is being rendered and before it is presented to the user. If the page containing that form (and CAPTCHA) is cached, then the Mollom module is not even invoked, and thus, the CAPTCHA is always invalid.

However, any kind of CDN or proxy has to take at least the Cache-Control header into account. If it doesn't, then that's the bug which causes this issue, and there's not really something we can do in the module.

Comment #4

zyxware CreditAttribution: zyxware commented 6 May 2011 at 19:37

Status:

Fixed

» Active

I am curious if a mechanism like this would work

a) Javascript sends AJAX request to server with unique URL
b) Server sends request to Mollom to create session and get URL of captcha image + link to play audio file and sends this as AJAX response
c) User submits form to server with text + mollom keys
d) Server validates the request with mollom servers to see if captcha was processed correctly

Even though the actual page and form might be cached the mollom session would only be created when a user views the page/form

Comment #5

neclimdul

He/Him

CreditAttribution: neclimdul commented 23 May 2011 at 19:35

Sub.

Getting random reports of weird problems like this might be associated with the CDN case listed. Random people unable to pass the Captcha and dead images.

We don't have a CDN but we do use varnish. From all inspection Varnish is behaving correctly though and the vast majority of users don't have this problem. They do seem to be people far away though. For example one was in Australia and our server is in Texas so I have wondered if there's some proxy we're not doing enough for and there's a way around it.