On Feb 16, 2009, at 1:18 PM, Paul Davis wrote:
On Mon, Feb 16, 2009 at 1:02 PM, Damien Katz <[email protected]>
wrote:
The problem with b) admin-enforced replication policies is that
it's not
really possible. The replicator is just an agent of the user who
invoked it,
it can choose to follow some rules set by the admin, or it follows
it's own
rules. You can't give a user access to the database, but enforce
that they
can only replicate it the admin specified way. If the user can
perform a
certain update in the database using regular methods, he can also
do so via
the replicator.
As we were mulling over the security considerations of allowing users
to run arbitrary code on a CouchDB node, I had the idea to allow the
node's admin to store a set of predefined methods that could be used
as replication endpoints. As in, instead of posting a JS function, we
post a {"filter": "foo/name"} member and it pulls the replication
filter code from {"replication_filters": {"name": "function...."}}
defined in "_design/foo". This way we have the full benefit of using
JS to do our filtering while preventing arbitrary code execution.
Yes, that's a excellent idea I hadn't thought of. I think that solves
a lot of problems.
Also, something I didn't mention before, the selective replication
code isn't something that actually needs to occur server side. It's
just way more efficient if it does. Client replicators could just pull
everything and filter it client side. Server side filters are just an
optimization.
-Damien
