Hi Chad. I don't disagree with anything you are saying. It won't really be known how much of a performance drag there could be until this is put into code and evaluated. I am not sure about the sanitization feature. It sounds useful to be able to manipulate output based on authorization however when you create a view are you not creating a contract with the system to return object attributes in the output? Maybe not but worth discussing.
On Fri, Dec 3, 2010 at 11:50 AM, Chad George <[email protected]> wrote: > 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 >> >
