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 36B77DE23 for ; Mon, 10 Sep 2012 17:31:08 +0000 (UTC) Received: (qmail 26243 invoked by uid 500); 10 Sep 2012 17:31:06 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 26212 invoked by uid 500); 10 Sep 2012 17:31:06 -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 26204 invoked by uid 99); 10 Sep 2012 17:31:06 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Sep 2012 17:31:06 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FSL_RCVD_USER,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of wordituk@gmail.com designates 209.85.223.180 as permitted sender) Received: from [209.85.223.180] (HELO mail-ie0-f180.google.com) (209.85.223.180) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Sep 2012 17:31:01 +0000 Received: by ieak11 with SMTP id k11so3580793iea.11 for ; Mon, 10 Sep 2012 10:30:41 -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=0jiTgnHj/pqCGwtAAXkUTTPI8zSCjeHmmf8Ut1pwP+U=; b=joU5/n4n99ZA/MWH8c51bHhiCZVf9YjJA6WraV8vbJUqjAN7GwrJMBEe1mxWgmsexE yML9lCGwHoP3723DDRp6Xt3uGN7v/P1maHi5w43XhJPJul+WadA7v0uKMHFtmTPQYJZe vnXThxNN/ppduNsx8fNtv7TSvJFnsCzW5csv4M8jKO1W9+tvgcDTjAB7Hxg3rXcIyABx mQSSFg21lOqQ99/qWac0ouyXZ6QdsrzSEe9bdXzL3y9Cirl1HpFh+DoW6fUbgckoz8DU PRox7qyYPC3n7rBLDIXAyyiGEcUIm6rffXD8DtOYc5csFjxF9B+Q2K0C1HqIWNH3yhlj oplw== Received: by 10.50.57.202 with SMTP id k10mr12592421igq.45.1347298241037; Mon, 10 Sep 2012 10:30:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.93.69 with HTTP; Mon, 10 Sep 2012 10:30:00 -0700 (PDT) In-Reply-To: References: From: Wordit Date: Mon, 10 Sep 2012 19:30:00 +0200 Message-ID: Subject: Re: Allowing access only to authenticated users To: user@couchdb.apache.org Content-Type: text/plain; charset=UTF-8 X-Virus-Checked: Checked by ClamAV on apache.org On Sun, Sep 9, 2012 at 6:50 PM, Dave Cottlehuber wrote: > > My question is - what does this role actually do for you? All > authenticated users will have a UsrCtx available in ddocs, so the mere > fact it exists implies they're in users. Where else might you want a > specific, separate role? Am I missing something? Quite often with a couchapp you need the main page, or certain parts, to be publicly accessible but not all the data. Personal profile data would be hidden. New users need read access to view the sign up form, which they cannot do if the whole couch is limited to authenticated user access. If you have a role of _user you can put the "authenticated users only" data into a separate database while still allowing access to the sign up and info about the application. At the document level, you could write validation functions allowing public read access but only authenticated users write access. A use-case is a forum. It's standard to allow public read access but require authentication to write. You need to easily group all signed-up members. I'm ruling out server-side scripts. There's little advantage in using CouchDB if you are doing things the LAMP way. Is there a client-side way that I'm missing? Thanks, Marcus