Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 74911 invoked from network); 16 Feb 2009 21:40:29 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 16 Feb 2009 21:40:29 -0000 Received: (qmail 92043 invoked by uid 500); 16 Feb 2009 21:40:28 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 92011 invoked by uid 500); 16 Feb 2009 21:40:28 -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 91969 invoked by uid 99); 16 Feb 2009 21:40:28 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Feb 2009 13:40:28 -0800 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=FS_REPLICA,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of jchris@gmail.com designates 209.85.221.21 as permitted sender) Received: from [209.85.221.21] (HELO mail-qy0-f21.google.com) (209.85.221.21) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Feb 2009 21:40:20 +0000 Received: by qyk14 with SMTP id 14so3172081qyk.11 for ; Mon, 16 Feb 2009 13:39:59 -0800 (PST) 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=ct65EVj2vjdooj5q05bUuqiWfQMyhoTvcuJUky63OMY=; b=n6wxIW9pzjnIuvMzpHN5mmUwr9zoiz6bS31IP0UonAmiUyO7WjJZwHIWq1+Vu2QoHP vxcjO+dbN/1RcQOmHx9wlIIUIa5YtclYi8KzPRJSZO5sDWExk9p1HZyiDnYgFQDKZKcJ dQrrbOHdO3l04+CUNcQWGG9DQzfCDS4e1amO0= 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=bhNHJmh7B5pfO5R3f3EcsPTMHYiyM24ROjPWiDF1jBlyOMzvuotcaTrt1zrWla8nph ENlE/IDdWGELNoz1xG1qYAlPf+67fnq93yD2WwNu6/xv4T8EdqMO7co9QWVZIHAmOTi0 dSpR0XzvJHP87ctexxQgdYEQvIRYbZOC6JsgA= MIME-Version: 1.0 Sender: jchris@gmail.com Received: by 10.224.2.138 with SMTP id 10mr7688549qaj.299.1234820399089; Mon, 16 Feb 2009 13:39:59 -0800 (PST) In-Reply-To: <74F5F8C1-EEB0-40D5-934C-8479743B8166@apache.org> References: <49999A45.9040302@diskware.net> <74F5F8C1-EEB0-40D5-934C-8479743B8166@apache.org> Date: Mon, 16 Feb 2009 13:39:59 -0800 X-Google-Sender-Auth: 0f6f1af65fc7cd2f Message-ID: Subject: Re: Partial replication -orelse- sending interpreted data to another server From: Chris Anderson To: dev@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On Mon, Feb 16, 2009 at 10:02 AM, Damien Katz wrote: > > Therefore the answer is to not distinguish between replicated updates and > direct updates. Instead enforce same security rules either way. This user > can update this document with these values, or he can't. Doesn't matter if > it's replicated or direct. > This pretty much describes the way I understand it as well. This makes the constraints on validation functions interesting. Under what circumstances should they ensure that the documents author-id matches the saving user? Will the previous_rev always be available at replication, as it is in the function signature? Validation functions make me want a distinction between document creation, and subsequent updates. > > Timeouts suck, but so does everything else. > classic Damien. I'm glad we're talking about this. Distributed identity is a tough problem, and validation / security plays a central role in that. Chris -- Chris Anderson http://jchris.mfdz.com