couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Issues blocking the 1.2.0 release
Date Wed, 15 Feb 2012 10:11:33 GMT

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
-- 


Mime
View raw message