From user-return-22011-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Thu Sep 6 21:30:40 2012 Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A66BCD3FD for ; Thu, 6 Sep 2012 21:30:40 +0000 (UTC) Received: (qmail 32510 invoked by uid 500); 6 Sep 2012 21:30:39 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 32479 invoked by uid 500); 6 Sep 2012 21:30:39 -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 32471 invoked by uid 99); 6 Sep 2012 21:30:39 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Sep 2012 21:30:39 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FSL_RCVD_USER,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of eduardoscoz@gmail.com designates 209.85.215.180 as permitted sender) Received: from [209.85.215.180] (HELO mail-ey0-f180.google.com) (209.85.215.180) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Sep 2012 21:30:34 +0000 Received: by eaad13 with SMTP id d13so625595eaa.11 for ; Thu, 06 Sep 2012 14:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=kDrk/3S1tIit7/63aJ/VeEcfdryql7vqqY+29WXK7yA=; b=a6VRP+JhiFSsbRnuXDKmrzKLuqVbY1h1t/KtwqutaLtaHXJILA1O0uixTG0nfz0ttk yvF7ERusB6WesP79pRy26AILNA+0L0+2W/ezEw4FIH0xlR2h3mlTPXfdRXpuHmImicuQ DlySWy2DIsP9ISY4UZo0BVcH60KwNKEHRLYdHVtAeYm4vyeTeM7SgJkrJ5XIVufjur/g sPl3xCRT4HwX+TRzpUCzAYW8gxTd5W4MNjubEMY43ZbWgZVm6XtHVF2Cj2STtuDU8ygk h0qmxbm4E/YdJPNMkPkfhycfwudl7fbnMOXjmsUCtb8wyu+xc0ORWWvlLBnZ1Uv7Mo9K JQSQ== Received: by 10.14.203.69 with SMTP id e45mr5122415eeo.23.1346967012794; Thu, 06 Sep 2012 14:30:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.223.3 with HTTP; Thu, 6 Sep 2012 14:29:52 -0700 (PDT) In-Reply-To: References: From: Eduardo Scoz Date: Thu, 6 Sep 2012 16:29:52 -0500 Message-ID: Subject: Re: App layer on top of replication To: user@couchdb.apache.org Content-Type: multipart/alternative; boundary=047d7b34410052616604c90f32e1 X-Virus-Checked: Checked by ClamAV on apache.org --047d7b34410052616604c90f32e1 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 6, 2012 at 4:04 PM, Dave Cottlehuber wrote: > On 6 September 2012 22:41, Eduardo Scoz wrote: > > Hi guys, > > > > Is there any way to put an app server between two CouchDB instances to > > manage security during replication? > > > > I'm working on a mobile app using TouchDB (iOS and Android), and I'm > > replicating the data back to the server using the normal CouchDB > > replication. In my use case, user creates new documents locally on the > > device, and syncs the DB with the host to push changes and get new > > documents. Filtered replication works well for getting only important > docs > > and validate_doc_update is enough to prevent unauthorized writes, but > that > > still leaves the database open for anybody with an ID to read other > user's > > docs. > > > > My idea is to put CouchDB behind something like Nginx or NodeJS that > would > > intercept direct calls to the database, but still let replication work > (as > > described above). all_docs replication would also have to be disabled, I > > guess. > > > > has anyone done anything like this? Any pointers on how one would make > it? > > > > Thanks! > > > > Eduardo > > Hi Eduardo, > > Security is enforced at the DB level in CouchDB. Does your app architecture > allow this? > > Fundamentally, the replicator is a clever, optimised HTTP client, so > blocking all except > the replicator will be very difficult, if not impossible. > > Any other ideas out there? > > A+ > Dave > My problem with the way couch implements security is that there's no per-doc read validation, only on writes. A user either have full read access, or no access at all (please correct me if I'm wrong). A proposed solution by the couchbase guys is to have multiple databases, one for each user, and then use replication to share the data, but this seems unmanageable to me once you get thousands of users syncing docs around. The replicator also uses GETs on the documents to get their revisions, though, no? I know it doesn't do it for new documents, but the filtered replication would not cause that situation, I guess.. Thanks Dave! --047d7b34410052616604c90f32e1--