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 Fri, 03 Dec 2010 15:50:26 GMT
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 <bchesneau@gmail.com> wrote:

> On Fri, Dec 3, 2010 at 5:31 AM, David Pratt <fairwinds.dp@gmail.com>
> 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 <randall.leeds@gmail.com>
> 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
>

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