couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicholas Orr <>
Subject Re: document level filtering
Date Fri, 12 Nov 2010 07:14:38 GMT
i think if something like this was in couchdb then i'd be inclined to
attempt to develop a couchapp - right now what stops me from doing this is
all the apps I've had to build have had a requirement to not expose the
entirety of all documents information. In order to satisfy this I've had to
stick ruby in the middle. Being able to replicate the whole app to one's
desktop is not desirable when some of the information in the database should
not be accessible by certain people.

I get that I can filter writes, however I'd prefer the person didn't have
the opportunity to modify the data in the first place :)

On Fri, Nov 12, 2010 at 2:40 PM, Chad George <> wrote:

> I'm curious if there are any significant technical obstacles or
> philosophical objections to having per-document filtering for reads.
> My idea is to add a new special field on the document that indicates a
> function that can modify the document before returning it to the user.
> function(doc, req) {
>  /* modify doc based on req or just throw exception */
>  return doc;
> }
> I was thinking the contents of the special field could be either the
> content
> of the function or a string path to a function on a design document in the
> same db.
> If the field is present on a document then the function is applied whenever
> the document is being directly accessed by the user: http get, view w/
> include_docs, pull replication, etc.
> In general, I like the idea of using database partitioning and filtered
> replication for the major firewalls of security in an application. But I
> think a large class of applications would benefit from some mechanism to
> prevent anonymous reads for a few special documents (like design documents)
> or sanitize fields within a class of documents for
> particularly unprivileged users.
> Obviously, just having the option available imposes a performance hit even
> on documents without the special field (whatever it takes to check if the
> field is present). Is this significant enough to strike the entire idea?
> - Chad

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