couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <randall.le...@gmail.com>
Subject Re: Enforced filter functions
Date Tue, 13 Mar 2012 19:32:37 GMT
Do filters already have access to the user context? My first thought is
that this would allow such a filter function to be written (one that works
for all users, but filters based on user).

On Tue, Mar 13, 2012 at 08:33, Dale Harvey <dale@arandomurl.com> wrote:

> On 13 March 2012 15:30, Dale Harvey <dale@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
> >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message