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 7F5A3DB80 for ; Thu, 30 Aug 2012 20:34:10 +0000 (UTC) Received: (qmail 84940 invoked by uid 500); 30 Aug 2012 20:34:09 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 84906 invoked by uid 500); 30 Aug 2012 20:34:08 -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 84897 invoked by uid 99); 30 Aug 2012 20:34:08 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Aug 2012 20:34:08 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=FSL_RCVD_USER,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.85.210.52] (HELO mail-pz0-f52.google.com) (209.85.210.52) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Aug 2012 20:34:01 +0000 Received: by dakf10 with SMTP id f10so1453247dak.11 for ; Thu, 30 Aug 2012 13:33:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=5pBjhWFXkhocTgYE8Hh64iy2gA4/zsxYNm8Utk9bbys=; b=TwAgaZ+C24BEjG/XdH6Kg5rBQJbk6ZTBRSPnaKKDOGBzw4Zqt7dl03t0e/GUTO+wve 6zeKLhkCOzUm1W3mDlH4fmoNCLY10I1xpl1YNi+g74bsO8LAIoRmfTKydNmhT0qPsvVK vUSGqYEtzOAdB6tJPna5+v3AgC3mepWQOSvDtwoDLrRPG/Fqw1vIteJzQkVYw572lchK JgO+JMWVoSe4cdJ+OVqn73G95wUmfUA4/+Pmww/8ej6GN9eGndU1Q27En2LaWtb4yKcL Ckmn8ExsfIs7Fdw6jO1YthT9niNHU0x9sIrhgrA1OjYmMprCXmUA/Rri6BG0NkiDbcBc IkuQ== Received: by 10.68.130.163 with SMTP id of3mr13474384pbb.108.1346358820233; Thu, 30 Aug 2012 13:33:40 -0700 (PDT) Received: from wlaptop.localdomain (c-98-232-199-158.hsd1.or.comcast.net. [98.232.199.158]) by mx.google.com with ESMTPS id ka4sm2119191pbc.61.2012.08.30.13.33.38 (version=SSLv3 cipher=OTHER); Thu, 30 Aug 2012 13:33:39 -0700 (PDT) Message-ID: <503FCE21.9000108@83864.com> Date: Thu, 30 Aug 2012 13:33:37 -0700 From: Wendall Cada User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: user@couchdb.apache.org Subject: Re: userCtx extra information References: <503CA33A.6080305@gmail.com> <503F06B4.8010303@gmail.com> <503F4934.3010007@gmail.com> <503F592D.2000208@gmail.com> <8B6A2452-D9B7-4F1D-80A3-40E5170171DC@sri.com> <503FB309.4050908@83864.com> <101B7D24-F7A8-40E5-A821-63474277FAAA@apache.org> In-Reply-To: <101B7D24-F7A8-40E5-A821-63474277FAAA@apache.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQm9jUVyDiey/r7ncN/4w1w/OMNL4Ta4/WkLft6uXacR3Jvj2SkgmiM9z1Yhcc0rKYfSQrUE X-Virus-Checked: Checked by ClamAV on apache.org On 08/30/2012 12:08 PM, Robert Newson wrote: > "An example of this is a comments thread moderator. They need permissions to edit portions of a doc that doesn't belong to them. Is it proposed that I just make everyone an admin?" > > No. You would invent a role called "moderator". You would assign this to users you wish to be moderators, and your validate_doc_update function would prevent users who don't have the "moderator" role from editing portions of docs that don't belong to them. My example here is bad, trying to keep it simple. I understand that this would be done through validation. The situation is that I have non-admin roles where the user can create other users, assign users to specific roles. This is necessary for our use-case. Is there a way to do this in a non-admin role? Or are there ways to have different levels of administrators? A better example is that you'd have a lead moderator. They have a non-admin account. They need to be able to add other users to the moderator role. This type of question comes up frequently, and this type of behavior combined with attributes which are typically stored in the userCtx and reside in the users session allow for fine grained control of user behavior without having to use admin accounts for anything but creating databases and other admin accounts. Maybe my understanding of this is completely incorrect here. But I'm not seeing any way possible to replace a third party authentication system with CouchDB except for the most simplistic situations possible. Wendall > B. > > On 30 Aug 2012, at 19:38, Wendall Cada wrote: > >> An example of this is a comments thread moderator. They need permissions to edit portions of a doc that doesn't belong to them. Is it proposed that I just make everyone an admin?