couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <>
Subject Re: Input validation and limits
Date Mon, 25 Mar 2013 05:01:24 GMT
On Mon, Mar 25, 2013 at 4:14 AM, Alexander Shorin <> wrote:

> Hi Jason!
> On Mon, Mar 25, 2013 at 7:22 AM, Jason Smith <> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message