couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dale Harvey <d...@arandomurl.com>
Subject Re: Enforced filter functions
Date Tue, 13 Mar 2012 20:17:36 GMT
Yup as Jan said, even the 'only run on non admin access' can live inside
the filter (there may be performance reasons to want to avoid that though)

Robert has expressed some concerns on irc about the implementation of
various security related features in an adhoc way, I do agree, the entire
reason I proposed this was to avoid a special case for subscribing to the
users table.

I think with some eye to the future this can be implemented in a way that
builds towards a reasonably complete set of security functionality, I dont
think it needs to be another edge case feature, I will try to come up with
a proposal that keeps in mind new things that couch will likely want to
implement

Any things to keep in mind, or other proposals would be nice

On 13 March 2012 19:36, Jan Lehnardt <jan@apache.org> wrote:

>
> On Mar 13, 2012, at 20:32 , Randall Leeds wrote:
>
> > 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).
>
> Yes.
>
> The problem with your suggestion is that the client can optionally specify
> the filter, or not, thus bypassing it.
>
> Cheers
> Jan
> --
>
> >
> > 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