From dev-return-5170-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Mon Jul 20 15:50:39 2009 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 63072 invoked from network); 20 Jul 2009 15:50:38 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 20 Jul 2009 15:50:38 -0000 Received: (qmail 74937 invoked by uid 500); 20 Jul 2009 15:51:43 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 74874 invoked by uid 500); 20 Jul 2009 15:51:43 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 74778 invoked by uid 99); 20 Jul 2009 15:51:43 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 20 Jul 2009 15:51:43 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of jchris@gmail.com designates 209.85.212.176 as permitted sender) Received: from [209.85.212.176] (HELO mail-vw0-f176.google.com) (209.85.212.176) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 20 Jul 2009 15:51:33 +0000 Received: by vwj6 with SMTP id 6so2206587vwj.13 for ; Mon, 20 Jul 2009 08:51:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=+NF3iLwxW0PXhs8qSQa92i1FyR82ab1/GVyK4QsqcRA=; b=NgkcbeznbpDzp7iSCp2K3V4k7/UXThwbytnvz7H4d4wwcXsTeZfz2Gc3LimfDEBu/d GkkLXy8YK/vQp0txiL4eeKTZOzAxJ7kB7Is0qA38oTjc9CI8BAG5Y1I1fo+4//MmEePp k5/KtHfICE7aSnphtOVr23kWyia35J65yJ+zw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=WfyZj2WqPABJRuCG4kLiec0OaNdrS5aOBDhRa+3FUNQPQMdJaYnhE37NE1qoETtH/f IZw3p4THqZKyUSbfMKWHqgxadFQvMCBw3KhzkJY655cNWuGlyHDMLByk0qvL6L3+oleY 6UK5e0KlC9yrkQZB/T65MYe6eACyBEavEYFfQ= MIME-Version: 1.0 Sender: jchris@gmail.com Received: by 10.220.92.143 with SMTP id r15mr4813114vcm.42.1248105072160; Mon, 20 Jul 2009 08:51:12 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Jul 2009 08:51:12 -0700 X-Google-Sender-Auth: 307f3136889d03f0 Message-ID: Subject: Re: filter for _changes From: Chris Anderson To: dev@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Mon, Jul 20, 2009 at 12:19 AM, Benoit Chesneau wrot= e: > 2009/7/20 Chris Anderson : >> Devs, >> >> I've just committed a patch (r795687) that adds the ability to filter >> _changes requests with a JavaScript function. >> >> The function signature is: >> >> function(doc, req, userCtx) { >> =A0return (true or false); >> } >> >> When it returns true (or something truthy, like a non-empty string or >> a non-zero number), the change is passed along to the user, otherwise >> it is skipped. >> >> The filter functions are stored on design documents under the >> "filters" field. The current best source of documentation is the >> changes.js test. >> >> To query changes with a filter, the syntax is like: >> >> GET /db/_changes?filter=3Dddocname/filtername >> >> The biggest problem with this patch is that it uses a JavaScript OS >> process per connected filtered listener. Fixing this is an >> optimization as it won't effect the API, which is why I'm comfortable >> committing this. >> >> I'd appreciate some review to make sure the implementation is on the >> right track. >> >> Cheers, >> Chris >> >> -- > > Implementation seems good for me and tests pass. For userCtx filtering > I guess it would be needed to have a way to filter all changes without > passing any parameter to forbid all changes read. Maybe by adding a > main validate_changes on top of a design doc ? Same args but this > fucntion would be applied on all changes. What do you think about it ? > I think you're suggesting using filtered changes as a security mechanism? That is certainly possible, but to do it right we'd have to ensure that it filters all document requests, which itself is non-trivial, and would certainly require us to address the performance issues. The other problem with using the filter for security is that we'd need to filter view rows. There's not really a fast way to do that for reduce views. I'd suggest we punt on JavaScript security functions for a while, at least until we've given this stuff a chance to sink in. Chris --=20 Chris Anderson http://jchrisa.net http://couch.io