See also https://github.com/pouchdb/express-pouchdb/issues/262
Convention + Filtered views + intersections = access control.
Start with a standardised-by-convention honour-system access control scheme, which can be
implemented client-side as an honour system, or enforced by a proxy. Add a system view
which gives the sd for each document.
Add filtered views to (COUCHDB-707) provide server-side support. Then add intersections
(joins) with other filtered views so access control information is indexed.
Finally add ability to optionally apply access control filters transparently to all views.
1. Honour System access control.
Extend the _security document to name additional groups than admin and member.
Specifically add "reader" (implicit read of all non-system documents) and "restricted"
(no implicit access), and allow adding any number of arbitrary groups.
Extend the userCtx to contain the property "principals" being a list of DB groups the user is in.
The user and the roles generate the list of principals at request time. Therefore only principals
need to be consulted for
"group:project X Admins"
Each document can have a new system property, _sd. This can be consulted to discover desired access.
An absent _sd means anyone may access. An empty _sd means only admins. Otherwise as described by the sd.
Levels are read-only, and full access (including delete).
"group:project X Admins":"rw"
We now have a client-side honour system access control.
2. Allow filter functions to be used for views and for document reads.
This would allow users to specify a filter function which implemented
access control to see only parts of the view they wish to see.
The filter function would be applied before the reduce step. Queries without
a filter function would proceed as at present. Queries with a filter function
On the honour system, this would be slow for views because it requires
reading the document to retrieve the sd, unless the sd were output in the value.
Need to ensure multiple filter functions can be used together.
3. Allow intersection queries when querying views. (Yes, a bit like a join.)
Specify multiple views (potentially each with their own filter).
The output of the first view is the only one returned, but it is filtered by only accepting the document IDs
which are produced by the other views.
4. Create a new system view _doc_sd which emits an entry for each document _sd entry.
If the _sd is empty, it will emit the implicit equivalents
5. Now we can (if configured) implement access control by implicitly querying _doc_sd
for intersection with the usrCtx.groups as keys.
6. Write access control can, as now, be implemented by the validation function.
7. Protection of namespaces from pollution by downlevel users can be provided by
validation functions. These would consult a _namespace_sd document which would contain
prefix to _sd mappings.