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 21:30:34 GMT
I was thinking that view results would go thru the validation/sanitizing
only if include_docs option was selected. Any data that is baked into the
view itself would be returned to any user with permission to access the
view's URL.


On Fri, Dec 3, 2010 at 11:28 AM, David Pratt <fairwinds.dp@gmail.com> wrote:

> 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 <chad@mgproducts.com> 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 <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