couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Pratt <fairwinds...@gmail.com>
Subject Re: Per Document Filtering/Authorization
Date Fri, 03 Dec 2010 16:28:02 GMT
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
View raw message