couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: Enforced filter functions
Date Tue, 13 Mar 2012 20:26:55 GMT
Another way to solve the particular feature would be "per-doc changes":

    GET /db/doc/_changes

I can see tons of use-cases for that already :)


On Mar 13, 2012, at 21:17 , Dale Harvey wrote:

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

View raw message