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 <j...@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
--
