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 b.candler@pobox.com designates
 208.72.237.25 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from:to:cc
	:subject:message-id:references:mime-version:content-type
	:in-reply-to; q=dns; s=sasl; b=l4+eEvJtD/10E7LxP/LagdZf3sUACYOvv
	3w+3PG/b8fOpxPJMmsa1GNMCPMekmRES6NcNOPBgHt+fbKCRo0mdRi2EcFMWLD1I
	yP2kn97TXayJkj1WWjgZdehcm5T5v+0+SGRy/rE4T4n+VxKjNM8uSmVnc6IBKTmJ
	hFW4Zj9+cI=
Date: Thu, 7 Jan 2010 09:45:33 +0000
From: Brian Candler <B.Candler@pobox.com>
To: Joscha Feth <joscha@feth.com>
Cc: user@couchdb.apache.org
Subject: Re: Modeling question
Message-ID: <20100107094533.GA5833@uk.tiscali.com>
Mail-Followup-To: Joscha Feth <joscha@feth.com>, user@couchdb.apache.org
References: <hi01b3$f1c$1@ger.gmane.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <hi01b3$f1c$1@ger.gmane.org>
User-Agent: Mutt/1.5.20 (2009-06-14)

On Tue, Jan 05, 2010 at 07:44:51PM +0100, Joscha Feth wrote:
> >If you store the full path (A, B) on the Cs as well, then you can collate like:
> >
> >A,
> >A, B
> >A, B, C
> >A, B2
> >A, B2, C
> >A, B2, C2
> >
> >etc.
> >
> >If you are paginating through large directories, then you'll want to
> >store the parent metadata in client state, so you don't have to reload
> >it for each page.
> 
> I don't see how that can help when a user requests a C without
> knowing that it is a C and has a parent B and A.

You could emit the 'reverse' path in the view: so when you search for C
you'd actually look for [C] -> [C,{},{}] and you would find

[C2, B2, A]

But if C2 itself denies access, then it would still be up to your
application to determine whether the user has access to B2 and/or to A which
might in turn permit them to access C, which would involve further queries.
(*)

I think if you want to *enforce* this sort of access control, you're bound
to have middleware.  Otherwise, if you're storing the ACL for C2 within
document C2, then you have to trust the client to read C2, check the ACL,
find out that they're not allowed to read the rest of the document, and
ignore the rest of it.

Another option is: would it be possible to combine A, all its child B's, and
all their child C's into the same document? You can then use a view to spit
out the keys and access rights for each component. (i.e. a view which walks
the document and emits multiple k,v pairs)

I'm assuming here that you're going to block direct access to _view (e.g. in
a http proxy), and force all access through _list. Otherwise a user will be
able to look at the whole key range, and use ?include_docs=true to view the
entire source document.

> I can not use a database per user or group, as both are completely
> dynamic (e.g. a user may gain or loose access on some documents any
> time).

Fine-grained read access control is not provided within CouchDB, not per
document and certainly not for data within views.  Middleware is your best
bet, and _list is the closest that CouchDB provides to middleware if you
want to avoid a separate tier.

HTH,

Brian.

(*) There is a new feature in CouchDB, which I haven't tried, which allows a
view to emit different documents than the one being processed. That is, if a
document C2 'points' in some way to the docids for B2 and A, then when
mapping document C2 you can also emit docs B2 and A. This means that the
parent documents can be made adjacent to the target document in the view,
which means your list function can have the data to hand to make the union
access rights. At least, I think this is possible.

Looking at
share/www/script/test/view_include_docs.js 
I think you do something like
emit(key, {'_id': 'B'})
emit(key, {'_id': 'A'})