Summarizing some things I said on IRC: I'm more than a little nervous about any more steps that appear to give fine-grained read access control within a database. We have repeatedly rejected the idea when it's been raised by community members citing the numerous problems that come with it (data leaking via views, for example) so we risk introducing even more confusion with a volte face. If we pursue this, we must get it right.
Today there's at least one case where we currently have mandatory code execution, validate_doc_update, that is causing issues. Because it cannot be bypassed, even by an admin, BigCouch, which strives to make N copies of every document, can be hindered. This example illustrates some part of the danger that 'enforced' code execution brings. Dale does state that the proposed filters would affect non-admins but we should be be conscious of how different couchdb looks and behaves to users vs admins. I agree completely that we need to add features incrementally rather than attempt some giant feat within a release. What I haven't yet heard is a coherent plan for where we'll end up. As a committer, I share responsibility in helping to define and deliver that plan. B. On 13 March 2012 15:33, Dale Harvey <d...@arandomurl.com> wrote: > On 13 March 2012 15:30, Dale Harvey <d...@arandomurl.com> wrote: > >> So I was trying to implement the ability for logged in users to subscribe >> to the changes feed for updates to their own documents (its currently admin >> only), its a simple patch but its not very clean (mostly because the we >> dont want to have the changes feed read the full document) >> >> A way that I could implement it, that seems a lot more globally applicable >> and applies cleaner, is to allow the ddoc author to enforce filters to >> happen on non admin access to _changes and replication (on any database) >> >> This should negatively affect anything else, filters are already used and >> supported in both places, I have also seen it asked for regularly in the >> context of replication, ddoc authors could specify exactly what users are >> allowed to replicate, the enforced filter would override any users filter >> >> > Obviously I meant "should not negatively affect" :) > > >> As far as I can tell the only problem would be how to have the author >> specify the enforcement, apart from that it should apply cleanly, >> introduces a fairly large amount of new functionality and adds very little >> overhead >> >> Ideas? >> >> Jan mentioned this could be used more widely for updates / shows / lists, >> that is starting to sound more complicated and does start introducing >> problems, I would prefer to look at the simple case of filters for changes >> / replication for now, but if there was an even more global solution that >> applied cleanly, I would be happy to >> >> >>
