incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <jch...@apache.org>
Subject Re: roadmap 0.11/1.0
Date Mon, 02 Nov 2009 01:11:56 GMT
On Sun, Nov 1, 2009 at 4:55 PM, Mark Hammond <skippy.hammond@gmail.com> wrote:
> On 2/11/2009 9:13 AM, Paul Davis wrote:
>>>
>>> couchjs security
>
> ...
>>
>> The first step to securing cURL handlers I'm going to tackle is the
>> basic all-or-nothing HTTP support. With something like --with-http as
>> Chris suggests. Mark also made a suggestion on including a
>> --with-http-host=127.0.0.1 or similar to support HTTP requests to a
>> specific host only. This is probably doable but I'll have to think a
>> bit harder on how to force that in the cURL handlers.
>
> My use-case is to avoid allowing full-blown cURL access to javascript while
> still allowing a couchdb 'external' to have access to "its" database.
>  Specifically, I want to use the 'externals' mechanism to build an
> application specific API - an API which hides/abstracts multiple couchdb
> calls and subsequent data munging into a single call which is more relevant
> to the application's direct requirements.
>
> For example, if I have an external which is referenced via
> http://host:port/dbname/_external, the implementation of that external needs
> access to the referenced 'dbname', but no others.
>
> On IRC, there were 2 thoughts:
>
> * Paul mentioned the cmd-line switch to disable cURL - if we provided a new
> option that only allowed connections back to the same DB (probably by
> exposing an API where the host and DB name can't even be specified by the js
> code), it might still meet the general security requirements.
>
> * Benoit mentioned that if we changed the externals 'protocol' slightly, we
> could probably offer a javascript API back to the database which uses
> stdin/stdout to exchange requests and responses, allowing us to live without
> cURL support at all.  Such an API may also be able to help allow cron jobs
> etc to have "safe side-effects" - the only side-effects they can perform are
> ones exposed by couchdb itself, not via generic http requests.
>
> The second option sounds better, but much more work.  I'm willing to roll my
> sleeves up on this, so please share your thoughts (or ask me to expand on my
> use-case if necessary)
>

Eventually I'd like to see an API to allow users to grant applications
the right to use HTTP in an unrestricted way. Think of the HTTP
requirement for an XML feed-reader CouchApp.

It seems odd to me that CouchDB has so much application horsepower,
but has to rely on browser + JSONP to be the API client of 3rd party
services. Bridging this gap safely is important.

I like your proposal of safe DB-only access via restricted curl. The
original action.js I committed long ago [1] had an insecure
implementation of this. Once we have something here, extending it for
more nuanced models will be worth a lot.

Chris

[1] http://svn.apache.org/viewvc?view=revision&revision=727141


> Thanks,
>
> Mark
>



-- 
Chris Anderson
http://jchrisa.net
http://couch.io

Mime
View raw message