couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <>
Subject Re: Issues blocking the 1.2.0 release
Date Wed, 15 Feb 2012 00:41:40 GMT
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 <> 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.)

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

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.

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



  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"])

> I'd still say we don't enable this for 1.2.0 as it is close to the
> release, but consider adding an option to enable this (e.g. in the
> _security object) down the road (in 1.2.x and later).

Love it.

Iris Couch

View raw message