couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johs Ensby <j...@b2w.com>
Subject Re: [PROPOSAL] Allow rewrites to be JS function
Date Mon, 28 Sep 2015 10:13:20 GMT
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 <ermouth@gmail.com> 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.


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message