Thanks Daniel, I like this idea and will give it a go! It shouldn't be too hard to extrapolate into a generic web service swapping plugin as well.
Cheers -Chris On Thu, Apr 22, 2010 at 9:53 AM, Daniel <daniel.r.he...@gmail.com> wrote: > If you can reach the reCAPTCHA site and the client can reach you, you > should be able to assume the client can get to recaptcha (since the > internet routes around damage). > Therefore you should be able to write a keepalive sweeper that pings > reCAPTCHA every few minutes, and provides a class method to decide > which captcha method to use. > > > > On Apr 21, 11:10 am, Chris Mayan <chris.ma...@gmail.com> wrote: > > Hello all, > > > > One of the services we use is recaptcha... and without it, potentially no > > new user can sign up among other parts of the site. (Last night we > couldn't > > reach the recaptcha service or 50% of the net for that matter as a pipe > was > > down!) > > > > So if the recaptcha service (or any other service that you depend on etc) > > goes down, then we effectively go down... > > > > So my question is - how do you mitigate against this? > > > > The obvious solution that comes to mind is to: > > > > Have a fallback local captcha service that is not as good as recaptcha, > but > > will suffice for when we detect the recaptcha service is not available, > and > > only validate against the local captcha service when we are REALLY sure > the > > recaptcha service is down. > > (The validation would strictly be conditional to stop attackers just > always > > attacking our local captcha instead of recaptcha which in theory is > easier > > to overcome then recaptcha) > > > > The question is... how does one go about this in rails? Has anyone tried? > Is > > there a plugin that someone has already made to wrap remote services, and > on > > error use an alternate service (be it local or somewhere else) ? > > > > Some technical questions that comes to mind... > > > > a) How do you on the client side decide that your recaptcha script should > > time out (ok some some crazy jquery + ajax might solve this - but does > that > > mean only with javascript you could do this switching of services?) > > > > b) On the controller and model side, how can we be sure that the client > (and > > us) can't reach recaptcha (without taking such a long timeout response > that > > would render page loading unbearable for the user) so that we only decide > to > > relax our validation and only validate to the lesser quality service if > and > > only if recaptcha service is down, otherwise enforce that all validations > > must be through recaptcha. > > > > Or have I gone about solving this problem all wrong? What would you all > do? > > > > Thanks! > > > > -Chris > > > > -- > > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > > To post to this group, send email to rails-ocea...@googlegroups.com. > > To unsubscribe from this group, send email to > rails-oceania+unsubscr...@googlegroups.com<rails-oceania%2bunsubscr...@googlegroups.com> > . > > For more options, visit this group athttp:// > groups.google.com/group/rails-oceania?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To post to this group, send email to rails-ocea...@googlegroups.com. > To unsubscribe from this group, send email to > rails-oceania+unsubscr...@googlegroups.com<rails-oceania%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to rails-ocea...@googlegroups.com. To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.