Affects Version/s: 3.2
Fix Version/s: None
This issue originally started while testing the signup procedure at learn.moodle.net. For some reason, the recaptcha did not work. I was able to debug things to what I believe is a core bug.
Back in 2008, in the issue
MDL-14073, commit 83947a36a8c5854f0d9fb5da8f58740069082d22, we introduced a new parameter for the _recaptcha_http_post() function:
The new parameter affects whether the Google API servers will be contacted via HTTPS or via HTTP. From what I saw, the intention was that if the Moodle site itself returns is_https() true, it should talk to google via HTTPS too. Note there are relics that try to pass the "https" argument via the mform element contructor explicitly, but that seems to be ignored.
Anyway, when we call that _recaptcha_http_post() at https://github.com/moodle/moodle/blob/v3.2.0/lib/recaptchalib.php#L240-L248 we do not pass the $https argument correctly. We pass it as the 4th parameter, but it should be the 5th one. The 4th argument $port is ignored.
Now this apparently did not cause any trouble on most sites. It even works well for us at moodle.org. For some reason, on learn.moodle.org (which itself is running on HTTPS), this caused that cURL did not return any response when calling the Google API via HTTP:
Fixing the $https argument fixed the signup issue on learn.moodle.net. I don't understand the reasons for this. The site should use same cURL version as moodle.org and has similar setup.
Still, the way how the argument is passed now is apparently wrong. And we have at least one documented case where it helped (even if i don't really understand why). So even if there is an open issue to migrate to recaptcha v2 (
MDL-48501), I am submitting a patch for this.