On Thu, Apr 28, 2011 at 4:39 AM, Brian Mitchell <[email protected]> wrote: > On Wednesday, April 27, 2011 at 6:48 PM, Jan Lehnardt wrote: >> On 27 Apr 2011, at 15:43, Randall Leeds wrote: >> > I think the answer is actually "yes". If you can see the design >> > document you can see everything the view emits, even if it came from a >> > document you can't view.Hm, I was thinking that the view updater would >> > match the design doc acl against the doc acl when the view is created and >> > exclude it if it doesn't match up for reads. > I agree in this case. > > I think it'd be much more valuable to have a general read access policy on > all documents (_uid/_gid) and allow views to break these rules. Each view > could be tagged with a _uid/_gid. For writes, I'd use existing validations > for regular writes and possibly allow update functions to be tagged with a > _uid/_gid as well. _all_docs and _changes would have to be filtered on read > unfortunately. > For _all_docs, I think we should filter it globally, not on read. Just like on file system only admins can do it. We could have a specific mask for it in db security obj.
For changes, that won't change the way we can filter changes anyway. Having a way to filter feeds by users in such functions may be interesting so we can create private feeds. > This allows users to craft more refined access policies in their design > documents rather than with overly-complex special attributes. CouchDB needs > only to put the foundation for a feature like this, not do all the work. It > does make writing design document a high privilege for any database but it's > no different now. If we wanted to emulate a more fine grained access pattern, > I'd encourage the developer to create more specific design documents and/or > use a proxy server. I agree this is easier to do like it. On the other want we can have have an option to check doc permissions before passing them to the view, It shouldn't impact much the performances on write. - benoƮt
