Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of bchesneau@gmail.com
 designates 209.85.215.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CALp38EM8oUraQ3dP3QVynSOJwgK1wnGXJdYcMcHsNGywGe5i_Q@mail.gmail.com>
References: 
 <CALp38EM8oUraQ3dP3QVynSOJwgK1wnGXJdYcMcHsNGywGe5i_Q@mail.gmail.com>
Date: Mon, 28 May 2012 14:59:27 +0200
Message-ID: 
 <CAJNb-9rxbi16yXDTfO7OuNpfM7+j-N6E9q028NgQrU4CNceSig@mail.gmail.com>
Subject: Re: Request object in validate_doc_update
From: Benoit Chesneau <bchesneau@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Fri, May 25, 2012 at 1:43 PM, Luca Matteis <lmatteis@gmail.com> wrote:
> I have a scenario where I'm building a CouchApp that needs to deny
> certain behavior from happening based on the user's IP address.
> However, the request object isn't available in validate_doc_update()
> functions.
>
> Would it be good to consider this as a new feature to be implemented?
> This would enable people to build much more secure CouchApps, without
> having to use proxies/firewalls and such. I personally think that
> CouchApps are opening up a whole new paradigm for developing web-apps,
> making them really easy to distribute around and to install (think of
> kanso), since they only require a simple push to a Couch instance.
>
> So adding new security features such as this, would enable even more
> apps to be built this way.
>
> What do you think?

I'm -1 on that feature. Rather I would prefer to have some extra data
added to the userCtx to keep it distinct from the HTTP APIs. Then the
HTTP auth handler could add these extra metadat. For example:

{
   "name": "username",
   "roles": []
   "extra": {
      "ip": ...
   }
}

The main point of it is to keep the core db api distinct from HTTP so
someone could add its own API level or even change the current HTTP
level without impacting low level.

- benoit