Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of randall.leeds@gmail.com
 designates 209.85.161.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAAL6JQhytD90Jn3f7LT-HUMVH=T5GgTEMXWzaR6kQ5BgqZGRSw@mail.gmail.com>
References: 
 <CA+5KyPSE3BULUc7KONgx8ZqfNKW++_r8vgdhh7HLxLr0JgfM0A@mail.gmail.com>
	<CAONf+LQKjE6NVCsLKWb3wzmWOwrS2ej+_PCJS4Z=uV3hj0OtOg@mail.gmail.com>
	<CAOHkvcP0XMAFvvFhaw3azEyqBxPMhNxFwkYX+5_x52ScSaxEbg@mail.gmail.com>
	<CAMkGvyNO4GC8e+PWu8u7BpV6b4OUvXZ3v37y5kpnXdrYgn_nBA@mail.gmail.com>
	<4E371B93.8060303@kearns.net.au>
	<CAAL6JQj_u0RgDhQG95oFrQfJ3MUeRXHb+Q6d1Cc6DEBUwaE_vA@mail.gmail.com>
	<CAONf+LTt0Hmuhx8PTs_LdzzX-fHQDAhQg_kJabTQAnfnBdxZqQ@mail.gmail.com>
	<CAOHkvcNutCimOggckR3ivc2=DCAP1ZhPTC2XpnP1o_E82_Pvaw@mail.gmail.com>
	<CA+5KyPR56FpKXiQ6Zyxu0V2jwaKbOghbTZyJ10Ou=YXyyk6zhA@mail.gmail.com>
	<CAONf+LTd+qQtLBb7iXb-H_HJs4Xm+t+Bw0G4CMLCC8X=bYwdFQ@mail.gmail.com>
	<CAAL6JQhytD90Jn3f7LT-HUMVH=T5GgTEMXWzaR6kQ5BgqZGRSw@mail.gmail.com>
Date: Wed, 3 Aug 2011 14:22:22 -0700
Message-ID: 
 <CAAL6JQjbpOD9GOu-dDDf7-1-44pANT3U=ZKaNYEBXPcX11C8pA@mail.gmail.com>
Subject: Re: to CouchApp or not to CouchApp
From: Randall Leeds <randall.leeds@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=UTF-8

On Wed, Aug 3, 2011 at 14:19, Randall Leeds <randall.leeds@gmail.com> wrote:
> On Tue, Aug 2, 2011 at 16:55, Max Ogden <max@maxogden.com> wrote:
>> My point with vhosts and security was that if you arent exposing couch to
>> the world you can route requests for certain couch-hosted domains to your
>> couch and let vhosts limit the exposed API.
>>
>> this means you need to run something like nginx in front of couch and
>> register couch as an nginx upstream. then when people hit your domain they
>> will be routed directly to the _rewrite handler and you can expose whatever
>> you want from there
>>
>> if you expose the root api of couch over the internet there aren't built in
>> ways to lock down everything. the solution would be to not expose the couch
>> root api.
>
> To add to this, when you create a vhost configuration on iriscouch, I
> believe iriscouch actually sees that configuration change and changes
> a downstream proxy. Submitting a request without a Host header will
> make it so that iriscouch does not know where to route your request
> and it returns an error.
>
> Now there's still the problem that if someone knows your
> username.iriscouch.com address they can bypass that. It would be a
> valid question for iriscouch support to ask whether that can be locked
> down by requiring a valid user, at which point you could use vhosts
> pretty securely.

Here I mean to say that require_valid_user=true is great for locking
down your couch, but one might want to only lock down the raw couch
interface and not require a valid user when going through a vhost, so
you could still have a logged out public landing page for your
couchapp.

>
> Security on CouchDB is evolving slowly, and so is the power of
> CouchApps. Keep the comments and questions rolling because it keeps
> the devs mulling, and, as always...
>
> ...patches welcome. :)
>