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 <[email protected]> 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') 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"]) > 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
