On Mon, Mar 25, 2013 at 4:14 AM, Alexander Shorin <[email protected]> wrote:
> Hi Jason! > > On Mon, Mar 25, 2013 at 7:22 AM, Jason Smith <[email protected]> wrote: > > ## reCAPTCHA support > > ... > > ## Rate limiting > > Wouldn't these things break bulk updates and replications? Both of > them triggers vdu much and let them fail on half way just because they > hit update rate wouldn't be nice. > Good point. This is why I wanted to have the discussion. I think the feature should be disabled by default. So upgrading CouchDB would not change how updates validate. I did mention a whitelist in my ideas, however I am not sure how it would work. That is why I identified "clients" rather than "users" or "remote ip addresses." Do you whitelist users or ip addresses or {user,ip} tuples? Or something else? And I don't think we want to start leaking client information into validate_doc_update. (Note that the req object is not passed to it, I think intentionally.) Anyway, yes, I agree, a client which fails validation very often Perhaps instead of a config, there could be a new flag when validation fails. So legacy code could never trigger banning. throw {"forbidden":"Not allowed", "fail":true} So we might ban on "fail" frequency, not just anything thrown. > P.S. Currently, these questions could be solved via nginx in front of > CouchDB + fail2ban. May be better to integrate with existed tools? For > example, providing auth.log with authentication successful and failure > attempts - fail2ban will be happy for this. Currently you have to live > with verbose logs (or configure per-module logging, thanks to Jan!) > which looks a bit overhead if you're interested only in auth problems. > I have not looked at fail2ban for a while. However I am encouraged by my javascript.log work. I would love to make a fail2ban-friendly auth.log file. -- Iris Couch
