From user-return-10214-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Tue Apr 20 19:26:47 2010 Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 87755 invoked from network); 20 Apr 2010 19:26:47 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 20 Apr 2010 19:26:47 -0000 Received: (qmail 97467 invoked by uid 500); 20 Apr 2010 19:26:46 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 97369 invoked by uid 500); 20 Apr 2010 19:26:45 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 97361 invoked by uid 99); 20 Apr 2010 19:26:45 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 Apr 2010 19:26:45 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jchris@gmail.com designates 209.85.219.221 as permitted sender) Received: from [209.85.219.221] (HELO mail-ew0-f221.google.com) (209.85.219.221) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 Apr 2010 19:26:36 +0000 Received: by ewy21 with SMTP id 21so1793879ewy.25 for ; Tue, 20 Apr 2010 12:26:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:mime-version :subject:from:in-reply-to:date:content-transfer-encoding:message-id :references:to:x-mailer; bh=CIKywwILNI5deGonBne30k7GXlQuI9UhSyZ0N+NC/To=; b=eF7qckKeWYcPVugXgcW6b1+Whn/qo82J0eNaJHUmoDRyTSyUfYvuBjW6fD+JVPHPFn kxUB/Q3TRdL/450hAuK/SRrUs9Cl0UPPy645O5UhD0hPrCLP9GzatMWnSZulJO7se5Bi V5CmmweBo844k+HbPSAvM9k2F8HZPue8oD8NM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; b=Yt1OwMQwyKep2FZv/9c+M4Xp+lAE+e3IFkOl+gJJE0JiCD9mfDmM/srPKQ/Ic3alNV 3VLgYO+v8XpQex+dYHEl/Zy4BMjJmAuJ5bvczugr+JXblOkx7pwqdsd6SYdQRe8ai4gq gn8k/UsgNZ0q4ctjygHx8mPQwEZOWNrPQN0tY= Received: by 10.103.81.38 with SMTP id i38mr668188mul.112.1271791575847; Tue, 20 Apr 2010 12:26:15 -0700 (PDT) Received: from [10.0.1.213] (h-74-1-186-35.snfccasy.static.covad.net [74.1.186.35]) by mx.google.com with ESMTPS id u9sm8832284muf.32.2010.04.20.12.26.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 20 Apr 2010 12:26:15 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) Subject: Re: Question regarding P2P authentication From: J Chris Anderson In-Reply-To: Date: Tue, 20 Apr 2010 12:26:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <46DCADEB-BC26-4A6D-B8EA-71CC18B384B8@gmail.com> References: To: user@couchdb.apache.org X-Mailer: Apple Mail (2.1077) X-Virus-Checked: Checked by ClamAV on apache.org On Apr 20, 2010, at 11:43 AM, Daniel Truemper wrote: > Hi everyone, >=20 > I have a question regarding P2P apps in CouchDB and the new = authentication method. >=20 > The setup could be like that: a central server is the main = synchronization point. If the user logs in (via some kind of reverse = proxy) she is automatically redirected to her user DB on the server = side. So, the central CouchDB instance has a _users database with her = user document. >=20 > At the same time I want her to run CouchDB locally. I.e. she should = have the same user document on her local CouchDB instance so that the = passwords are the same. If she changes her user document locally I would = like to update this to the server database and vice versa. Could this be = done via filtered replication? >=20 you won't need a filter, as users are only allowed to update their own = user doc. Even if a user defeats the validation locally, the central = server will only allow replication to update the correct document. > If this works like I described it, there is only one open question: = how can I prevent the users from replicating all documents P2P, without = the synchronization server. I have the usecase where not every user is = allowed to see all documents, so I would have to prevent those documents = from replicating between two end users. I think this should be done via = the validate doc update function?! You can use filtered replication to keep a proxy database on the central = server, one for each user, that the user can replicate freely to and = from. Then you can use filters when replicating between the central db = and the proxy db. A simpler option (depending on your app) would be to allow users to = create workgroups, and each workgroup gets a db which members can = replicate, read and write to. This is simpler than a central db plus it = is easier for users to reason about. I think the model of a central db with complex policy controls for each = document is a holdover from the relational days. It's much simpler to = think of a database as a shared workspace, where anyone who has access = has full access. Chris >=20 > If there is a better solution, what would that be? >=20 > Best > Daniel