6

I just got a failure with the captcha system. Sequence of events:

  1. Answered a question
  2. The OP changed the question such that my previous answer didn't apply, so I deleted that answer
  3. Wrote a new answer that answered the new question
  4. Got a captcha display with the usual robots picture and the "I'm a human being" button
  5. There was NO captcha display or box to enter anything
  6. Pressing the "I'm a human being" button said I didn't enter the words correctly
  7. Tried several times to add a new answer, with the same results as above
  8. Gave up and undeleted and edited my previous answer instead, which worked without any captcha required

I'm using Firefox 4 on Windows 7 with HTTPS Everywhere installed. (I'm sure that I've successfully used the captcha after installing HTTPS Everywhere several weeks ago.)

3

2 Answers 2

7

It seems Google nowadays wants sites to use www.google.com/recaptcha/api/ rather than api.recaptcha.net. The old domain redirects to the new URL, and Google recently stated it will continue doing so.

However, Google has recently stopped HTTPS support for the old domain:

IMPORTANT: changes to reCAPTCHA SSL API (api-secure.recaptcha.net) on April 11

In April, we will begin to turn down the legacy URL for reCAPTCHA's HTTPS API. If your site uses reCAPTCHA over SSL, you will need to make a minor code change before April 11.

[...]

FYI, we are now purposely serving an expired SSL certificate for api-secure.recaptcha.net. This is expected behavior.

HTTPS Everywhere rewrites api.recaptcha.net to the obsolete api-secure.recaptcha.net. This https://api-secure.recaptcha.net/challenge?k=6Ld... still works with a warning, but apparently fails silently when embedded in another web page.

But the new URL from the documentation, https://www.google.com/recaptcha/api/challenge?k=6Ld..., is fine for both HTTP and HTTPS. So: though not officially required, maybe the Stack Exchange HTML could be changed to adhere to the current documentation? Without any additional work, that would magically also make add-ons such as HTTPS Everywhere work again.

In the meantime, in HTTPS Everywhere: how about an exception for api.recaptcha.net, or some rewrite to https://www.google.com/recaptcha/api for that domain?

1
  • That's for the analysis! There's a recent update to HTTPS Everywhere that appears to fix this problem. Commented May 2, 2011 at 22:24
3

We're using a ReCaptcha supplied library, and it's still* emitting the old API paths.

Frankly, if Google doesn't think its worth fixing I don't. Furthermore, its only a problem because HTTPS Everywhere is re-writing to the (now) incorrect url.

<rule to="https://api-secure.recaptcha.net/" from="^http://api\.recaptcha\.net/"/>

in \chrome\content\rules\GoogleAPIs.xml.

*We were on an older library version, so I've kicked us up to the latest. Both link in the same resources.

3
  • It turns out there's an update to HTTPS Everywhere that fixes this redirect. I suggest the question tag be changed to "status-resolved". Commented May 2, 2011 at 22:23
  • We can't trust Google any more ;-) "The plugins we officially support have been updated to use the new URLs by default." Still then, as HTTPS Everywhere fixes this, I guess it's indeed fine to not change things.
    – Arjan
    Commented May 2, 2011 at 23:11
  • @Greg, maybe this should be the accepted answer?
    – Arjan
    Commented May 2, 2011 at 23:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .