One of the best parts of CouchDB is the Document and View APIs. Direct document access, multi-doc, views + include_docs, etc. These are part of the core that makes the db nice to build applications on.
As I understand it the original motivation behind shows and lists was public facing websites that need to be searchable and accessible. My concern with also using these as the main security mechanism is that we cripple (or at best make painful) the development of apps that don't need or want to use only the shows/lists feature. That said, an extension to the URL rewrite handler to provide some ACL based protection mechanisms would be very useful and I think sufficient to protect views and design documents, and patching up unexpected edge cases from APIs that aren't needed for mixed annon/auth users of the website. Definitely a purely ACL based authorization is faster than executing some arbitrary JS code. But I don't think it meets all the required use cases, access cannot always be determined by the type of document, and I'm not certain there is consensus that documents should have an explicit type field to enable security to work. We already have mechanisms that use JS function for validating all document updates, so I don't think its stepping outside the CouchDB way of thinking to add a validate_doc_read() function on the design documents. ACL/doc type based mechanisms would be just as easy to implement in JS code as in some list elsewhere. If it later turns out that we mostly use the simpler ACL list validation it could easily be added as a native erlang method for higher performance, while still leaving the more flexible mechanism for those that need it. It might be useful for document URLs that have been previously allowed by the ACL based URL protection mechanism to bypass the validate_doc_read(). This would allow most of the static resources of a couchapp to be authorized in the most efficient way, while still validating everything else thru a function. Also I think its useful to have the validate_doc_read() be able to return a sanitized (like remove SSN, phone number, etc) version of the document rather than just allow/prevent access. Anybody have a thought or concern on that feature? - Chad On Fri, Dec 3, 2010 at 1:37 AM, Benoit Chesneau <[email protected]> wrote: > On Fri, Dec 3, 2010 at 5:31 AM, David Pratt <[email protected]> > wrote: > > Hi Randall. Am not opposed to this either, however we are currently > > two dbs with _users at present and see per document authorization as > > an opportunity to extend current authorization policy. > > > > If not a separate db, can you elaborate on your ideas and how you > > would reconcile with _users with roles, and with Admins and Readers > > groups. What sort of mechanism are you suggesting? > > > > On Fri, Dec 3, 2010 at 12:42 AM, Randall Leeds <[email protected]> > wrote: > >> A separate database is a bad idea IMHO. Whatever solution to > >> per-document filtering we come up with should allow for the > >> CouchApp-style database-as-application paradigm where one expects to > >> get a fully working application by replicating a single db. > > > > I was thinking auth could be done as document level while maintening > users in a db. A db could have metadata like owner, readers and > writers. Tnen the main problem to solve is in views. But in the > hypothesis, the docs know who are their users, you can do the same and > put auth to a design document and restrict access to a group of views > defined on a design doc. Last problem to solve is the all_docs, but I > guess it could be replaced with a view if needed. > > - benoit >
