Reproducible with the following setup:

1. Use secure pages module to secure some of your paths
2. Now to avoid mixed content warnings, you should set your /mollom/* paths to use https too for the benefit of those pages.
3. However, if you still have a form mollom enabled on a non-https page, when switching to audio, the client code only gets a redirect (which it does not handle).

Result: audio captcha will not replace the image captcha, despite repeated cycling clicks on the image/audio captcha links.

Comments

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented
Title: Audio captcha redirect not handled » Audio CAPTCHA redirect on SSL (via Secure Pages) not handled
Status: Active » Postponed (maintainer needs more info)

Sorry, but I'm a bit confused here.

  1. If you use Secure Pages module to secure some of your pages/paths, and a Mollom CAPTCHA happens to be shown on such a path, and you switch the CAPTCHA between image and audio, then Mollom module's JavaScript requests the new CAPTCHA, and it is using a relative URL to do that:
      $.getJSON(Drupal.settings.basePath + 'mollom/captcha/' + newCaptchaType + '/' + formBuildId + '/' + mollomSessionId,

    Hence, if the originating (parent) page is on SSL, then also this request is on SSL. And vice-versa.

    Therefore, I don't quite understand why you have to manually configure /mollom/* paths to force them to use HTTPS in the first place?

  2. I don't understand why there is a redirect involved on non-HTTPS pages. In case Secure Pages module does this, because of the enforced HTTPS for /mollom/* paths, then I guess I understand, though not verified -- most probably, the browser considers http://example.com and https://example.com as different domains/servers. And so, even though jQuery automatically handles and follows redirects, this kind of redirect turns into a cross-domain request, which in turn the browser's security policy does not allow.
sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented

So I think this entire issue boils down to the question why HTTPS is enforced for /mollom/* paths in the SecurePages configuration in the first place. Is there any strong reason for doing that?

Gábor Hojtsy’s picture

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy commented
Status: Postponed (maintainer needs more info) » Active

Well, I've removed /mollom/* from the securepages setup, and it was broken the same way, the audio was requested from http, so I cannot reproduce it using the same domain as you've explained.

easp’s picture

easp CreditAttribution: easp commented

I ran into the same issue where I could not get the audio function to work with secure pages.

I added "mollom/*" to the ignore pages field within the secure pages settings. It fixed my issue.