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 <[email protected]> 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. >
