From couchdb-user-return-1301-apmail-incubator-couchdb-user-archive=incubator.apache.org@incubator.apache.org Sun Sep 14 11:23:43 2008 Return-Path: Delivered-To: apmail-incubator-couchdb-user-archive@locus.apache.org Received: (qmail 37912 invoked from network); 14 Sep 2008 11:23:43 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 14 Sep 2008 11:23:43 -0000 Received: (qmail 5038 invoked by uid 500); 14 Sep 2008 11:23:39 -0000 Delivered-To: apmail-incubator-couchdb-user-archive@incubator.apache.org Received: (qmail 4998 invoked by uid 500); 14 Sep 2008 11:23:39 -0000 Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: couchdb-user@incubator.apache.org Delivered-To: mailing list couchdb-user@incubator.apache.org Received: (qmail 4987 invoked by uid 99); 14 Sep 2008 11:23:39 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 14 Sep 2008 04:23:39 -0700 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 johan.liseborn@gmail.com designates 64.233.182.185 as permitted sender) Received: from [64.233.182.185] (HELO nf-out-0910.google.com) (64.233.182.185) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 14 Sep 2008 11:22:41 +0000 Received: by nf-out-0910.google.com with SMTP id c7so1059944nfi.40 for ; Sun, 14 Sep 2008 04:23:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Y3hdut7B67LDmONVdE5wRZIAB9TnEZA80GwbIoEeOFE=; b=MyaaoOeqoqrZ4+0ctUfusTMdULglGe24B+19PP+WmLfOKNri/kpryfHuYOytvkqyEI 2sPzdNmjTqoDqLzciudEZD1vouqLx/txJBcR1Rq7vBkOP14a9rEcTaMo9yq9DvagZCgb vYWR/ymdFCbk9CsG7X/tuxuHQNPPFp+7sRexA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=jMcpSUTzS6wGQebcQy1NJypA1CM6Pu+G2/ZuPUmTdIibgYItZb/tZ5FzVWC2N8EFzh 3T3A+W4SBEKd8gMD1PdfzNK9rCpWi0Pb/WZrM8cF1DEgXta/pkYoqxSyLI25/nP6lz6Y iK1hA4E/Zzdk3pbtIWMV9SgbsQ0x/RWO25NPA= Received: by 10.86.31.18 with SMTP id e18mr4862849fge.52.1221391391552; Sun, 14 Sep 2008 04:23:11 -0700 (PDT) Received: by 10.86.83.12 with HTTP; Sun, 14 Sep 2008 04:23:11 -0700 (PDT) Message-ID: <3a344bc70809140423m26bf1d72q60b3a61564ec15f6@mail.gmail.com> Date: Sun, 14 Sep 2008 13:23:11 +0200 From: "Johan Liseborn" To: couchdb-user@incubator.apache.org Subject: Re: Status of security features In-Reply-To: <20080914105217.GA8957@bytesexual.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3a344bc70809140339y70f060d3he3270259db2ab129@mail.gmail.com> <48CCEA68.5010607@eprometeus.com> <20080914105217.GA8957@bytesexual.org> X-Virus-Checked: Checked by ClamAV on apache.org On Sun, Sep 14, 2008 at 12:52, Noah Slater wrote: > On Sun, Sep 14, 2008 at 12:41:44PM +0200, Michele Sciabarra wrote: >> As Jan told in the recent FLOSS weekly podcast, "there is no security in >> CouchDB". Thanks, I had missed the FLOSS podcast; I am downloading it as I write. > But as CouchDB speaks HTTP, you can take advantage of REST architecture by > layering reverse proxies that implement your chosen security restrictions. Absolutely. It also seems quite possible to implement some "security" (maybe not the best word to use) measures yourself, by creating a small wrapper around your chosen method to access CouchDB and leveraging the flexibility of CouchDB documents and databases (for example by adding similar items already mentioned above, such as lists of users and/or groups that are allowed to access a certain document). I haven't really thought this through though, so I may be wrong... but it seems pretty close to what is described in the CouchDB documentation, except there the code is put in the document (and/or in a design document) and it gets automatically called when you try to access a document... I should also clarify that what I am (at the moment) mostly interested in is the ability to do document-level authorization (for example saying that "user a, b, and c are allowed to read and write this document" or "group d is allowed to read this document"). I guess what I am trying *not* to do is duplicate work already been done, or in the pipeline. Anyway, thanks for your input guys! johan