couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hammond <skippy.hamm...@gmail.com>
Subject Re: roadmap 0.11/1.0
Date Mon, 02 Nov 2009 00:55:20 GMT
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)

Thanks,

Mark

Mime
View raw message