Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1257)
Subject: Re: Issues blocking the 1.2.0 release
From: Jan Lehnardt <jan@apache.org>
In-Reply-To: 
 <CAN-3CBKk8K0ArPAUi18vQzcUJCVG3gL2kWzvqhULL5woASLQzQ@mail.gmail.com>
Date: Wed, 15 Feb 2012 11:11:33 +0100
Content-Transfer-Encoding: 7bit
Message-Id: <64783B69-52F2-4E7B-92C6-D27D54CE0F06@apache.org>
References: 
 <CA+Y+445m_ofkwvLuB9eRnVwmAnOBR2LwQV2ZMbiARTwSCzj-ug@mail.gmail.com>
 <CAAL6JQi53Fs73aevYVd6OP3Ua2rdZyTH7PTw13rASuNTymvpOw@mail.gmail.com>
 <55B3B2E5-6FD5-4240-B171-A7768FEFD3EF@apache.org>
 <CAAL6JQigNO=eF=FcqPYnvXaK+c2Sf0uBrU1+hvqM05Z--DkQyA@mail.gmail.com>
 <DCBA4635-1F15-4777-8868-8A71E0593A77@apache.org>
 <CAAL6JQgTPREiAQ69sWrB7KqXKBNq+CKB7__T4MBB48BZ8x3j3g@mail.gmail.com>
 <44A852CB-79D3-40BE-A49C-D59D426B17E4@apache.org>
 <327A2529-EB40-4147-B915-558824AFF552@apache.org>
 <CAN-3CBKk8K0ArPAUi18vQzcUJCVG3gL2kWzvqhULL5woASLQzQ@mail.gmail.com>
To: dev@couchdb.apache.org


On Feb 15, 2012, at 01:41 , Jason Smith wrote:

> Thanks for your feedback, Jan.
> 
> I am in the camp that views should be allowed but it's not the end of
> the world. I would have spoken up but the RFC was security-related and
> not public (which is fine, that's life.) I noticed it in Git but
> didn't speak up then either.
> 
> On Wed, Feb 15, 2012 at 2:51 AM, Jan Lehnardt <jan@apache.org> wrote:
>> The reasoning was as follows:
>> 
>>  - I tried to design the system to be as simple as possible.
>>  - I also tried to design it to be the least intrusive to the 1.2.x
>>   codebase given the maturity of the branch.
> 
> That's cool. However that goal somewhat conflicts with being intrusive
> to *users* upgrading to 1.2.x. Specifically, people who used the
> CouchApp, Evently, etc. examples and tutorials which use /_users for
> public profiles. (The database is is named _users, not _passwords.)

Yup, that is the trade-off. Making the _users db more secure means
taking away existing features. I believe that this is the right thing
to do. :)


>> It was these goals and J Chris's email about how to solve the conundrum
>> of per-doc-auth* a few weeks earlier (disable views when you enable
>> per-doc-auth) that lead to the current situation.
> 
> Strong point. However this implementation doesn't meet Chris's
> description because we have neither (a) per-doc control, nor (b)
> views. If we had per-doc control, then we could allow access to docs
> like "profile:jhs" and disallow "org.couchdb.user:jhs".

The system-db security handler for both _users and _replicator disallows
access to documents of user A by user B. That is per-doc-auth in my book.
It isn't user-accessible as it was discussed (and not solved) in the
past, but it is most definitely an implementation of the same concept.


> Without (a) or (b), users will have to migrate profiles from /_users
> to e.g. /profiles. They can't even replicate, because the point is
> protecting the password fields. That's not earth-shattering, but if
> you read the BreakingChanges page, you might agree that this is the
> biggest user-facing change for a long time.

Yes, and that is for now intentional. :)


> My suggestion was a prefab view, /_users/_auth/_view/profiles that
> outputs emits public information. Maybe the ddoc also has
> .views.lib.profile_config where options are. The map function would
> look like this:
> 
> function(doc) {
>  var config = require('views/lib/profiles_config')
> 
>  if(!config.enabled)
>    return
> 
>  if(!doc.public)
>    return
> 
>  var val = {}
>  config.whitelist.forEach(function(key) {
>    if(key in doc)
>      val[key] = doc[key]
> })
> 
> emit(doc._id, val)
> }
> 
> Thus to have profiles, the admin must:
> 
> 1. Add a .public = true key to the user doc.
> 2. Edit .views.lib.profiles_config and set enabled = true
> 3. Edit .views.lib.profiles_config and add some fields to the
> whitelist (e.g. ["gravatar_url"])

Do you want to put this into a JIRA for 1.2.1 and 1.3.0?


Cheers
Jan
--