reCAPTCHA failover?

[jon]

There might be a time when reCAPTCHA's API or verification servers are
unavailable. What is the best way to check for errors so we can fall
back on our own captcha system? Will the response return specific
error codes or just HTTP 5xx errors?

[reCAPTCHA Support]

We should return 5xx errors when we're unavailable, however this type of issue is unlikely. Our code is designed such that if the web server is running, there is a way to verify reCAPTCHA. On the other hand, the possibility that the servers are unreachable is equally unlikely. We use servers in multiple cities and a redundant DNS setup that queries each server every second.

- Ben

--
reCAPTCHA: stop spam, read books
http://recaptcha.net

[j.prost]

On Jan 16, 9:53 am, "reCAPTCHA Support" <supp...@recaptcha.net> wrote:
> We should return 5xx errors when we're unavailable, however this type of
> issue is unlikely. Our code is designed such that if the web server is
> running, there is a way to verify reCAPTCHA. On the other hand, the
> possibility that the servers are unreachable is equally unlikely. We use
> servers in multiple cities and a redundant DNS setup that queries each
> server every second.

This isn't a good answer. Let's say that we are implementing
reCAPTCHA within a corporate environment, on an internal server...or
let's say that I have a development server running within vmware with
no Internet access, DNS poisoning. There are far to many potential
issues between "us" and "you".

I can accept the argument that implementing a CAPTCHA solution that
requires Internet access will come at a cost (that cost being
reliability). I can also accept the argument that this has not been
an issue that has plagued reCAPTCHA, and therefore it has not been
made a priority. However, I'm not sure that there are any arguments
that actually diminish the concern over reliability. I imagine that
many, like myself, are also looking at CAPTCHA solutions that would be
locally resident, and therefore be as dependable as the web system
itself.

It would seem to me that there would be an easy method to simply check
the availability of the server during the presentation of the CAPTCHA
and the form's processing. If the server is unavailable it could fail
open or closed based on configuration.

All this said...I personally find your solution to be wonderful.
Providing the ability for anyone to implement a strong CAPTCHA form
that also supports those that are hearing impaired, is simply
terrific. My comments are simply to suggest that for a system that is
dependent upon the unreliability of the Internet, networking
equipment, and DNS, it makes sense to consider methods for ensuring
that a form would be able to be used during those brief periods of
inaccessibility.

thanx...
jason...

[reCAPTCHA Support]

Hi,

The only kind of check one can really make is on the server side (you can't trust the client to be truthful about if it can reach reCAPTCHA). An easy way to do this is to set a timeout for the verification API. If that timeout fails, you can simply let the request pass. If enough of these failures happen for a period of time, you can then turn off the reCAPTCHA entirely.

 - Ben

[Bryan L]

Hi -

On this thread, and in general I was searching for a method to provide "CAPTCHA" without internet connectivity being provided to the client PRIOR to passing CAPTCHA.   J. Prost suggest reliability as a concern - and agree w/ that concern, but my concern is that I only want to provide Internet to a client who is an actual person vs. a machine.  Thus I would use CAPTCHA plus a login to assure the device that associated and logged in is being driven by a person - Does Google provide a CAPTCHA option that can be hosted locally, or locally via proxy...   For example:

Client ---local lan ----- Local.Service.Provider.Server (with ReCaptcha Proxy) ----  internet --- Google.ReCaptcha Service.  

Thus the local service provider can leverage ReCAPTCHA/Invisible or otherwise, w/o opening up the internet to the client to do so.

Thoughts please

bryan