Download & Extend
Mollom » Issues

Audio CAPTCHA redirect on SSL (via Secure Pages) not handled

Posted by Gábor Hojtsy on March 29, 2011 at 11:29am
Project:Mollom
Version:6.x-1.x-dev
Component:Code
Category:bug report
Priority:normal
Assigned:Unassigned
Status:active

Issue Summary

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.

Login or register to post comments

Comments

#1

Posted by sun on April 1, 2011 at 7:00pm
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.

#2

Posted by sun on April 5, 2011 at 6:40pm

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?

#3

Posted by Gábor Hojtsy on April 8, 2011 at 7:14am
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.

#4

Posted by easp on July 20, 2011 at 3:29pm

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.

nobody click here