incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chad George <c...@mgproducts.com>
Subject Re: Per Document Filtering/Authorization
Date Thu, 02 Dec 2010 22:43:15 GMT
One important use case where a validation function works better is when the
same document "type" needs to be only accessible by certain users (like the
document's creator).

I'm not certain what we gain by having a separate _authorization database
over just putting that information in a design document.

Your document "_type" field is conceptually similar to my original idea of
attaching the access validator to a document to give it a type. A more
generic type field that could be used for view filter is probably better
though and might relieve previous objections to directly assigning security
functions on the data.

Perhaps we could combine both ideas:
 - add an official "_type" field to the document API since its pretty common
anyway.
 - design documents have a _access field which is a dictionary associating
_types for that database with either a whitelist/blacklist ACL or a function
that is evaluated with the request context and document.

- Chad

On Thu, Dec 2, 2010 at 12:14 PM, David Pratt <fairwinds.dp@gmail.com> wrote:

> > which is already something most folks do for filtering views etc. If
> > there is no entry in _authorization database, the data accessible to
> > the extent that we have any Readers for database as it is now.
>
> sorry typo - last bit should have read ..
>
> the data would be accessible to the extent that we have any Readers
> for database as it is now.
>
> To add to above, it might be good for the system to have a special
> entity named "ALL" where access to everyone is not implied by the
> absence of record in _authorization for the _type but could be made
> explicitly if desired.
>

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