Jason, I would like to offer another use case related to "access control" In the userCtx.roles you can store objects created at signup (e.g. via social login) that may be used as shared or individual access keys. Having roles available in _rewrite makes it possible to have one design document as an "API server":
-- vhost point to a design document _rewrite that work as your API server (everything can forced through this point, at least for Cloudant users) -- "unsafe" rewrites allow you to rewrite to (or not) any DB on the Couch Example: Web site team workflow -- one DB holds the live version of a site, another the "staging site" for final review -- several other DBs hold various contributor's updates to various categories of documents at the site -- the various editor roles can be checked in the "API server" ddoc _rewrite and redirect to the appropriate DB -- content is replicated to the staging site and that is replicated to the live site with a request that require "publisher" role All of the above can be defined in a simple API, making the _rewrite the place to manage your resources rather than spreading the access control around in various show, lists, and databases. I think a function-based rewrite would reduce the need for workarounds like db-per-user pattern. johs > On 28. sep. 2015, at 10.37, ermouth <[email protected]> wrote: > >> Can you unpack "access control"? > > More accurate terms would be ‘userCtx-based query restriction’ and/or > ‘userCtx-based query rewrite’. > > Assume we have views, that fetch by keys [%username%, > startKey]…[%username%, endkey]. Using rewrite we can ensure user won‘t be > able to fetch docs he has no rights for.
