5

In particular, can filtered replication be done with PouchDB? I want to make sure that the client can't omit the filter and thus sync against the whole database.

Bob Aman
  • 32,839
  • 9
  • 71
  • 95

1 Answers1

5

There is no CouchDB replication "protocol." The replication process is simply a client connecting to two CouchDB endpoints, reading documents from one, and writing them into the other. Of course, CouchDB comes with such a client ("the replicator") built-in; but conceptually it is a third-party application.

What that means is, you can remove replication from your security analysis of your application. First consider normal web clients reading and writing to your server. Lock that down. You might assume a hypothetical adversary with a hacked web browser, or using a custom HTTP client (which does not respect cross-origin policies for example).

With that problem solved, replication will, by necessity, follow your security policy.

In other words, replicating between PouchDB and CouchDB:

  • If you are pushing to the remote server, your security tool is the remote validate_doc_update function.
  • If you are pulling from the remote server, your security tool is the database _security object--specifically the "members" arrays. A client can either read a database entirely, or not at all. Of course, you can make filtered replications into special-use databases on the server side.
JasonSmith
  • 72,674
  • 22
  • 123
  • 149
  • This was my assumption, that you wouldn't expose CouchDB directly (much as you wouldn't expose MySQL or any other data store directly), but rather implement some sort of pass-through endpoint. But I'm a little confused here when you say that there's no CouchDB "protocol"? I understand what you mean by it acting as a third-party client, but my assumption would be that PouchDB's replication is achieving interop by essentially treating that behavior as a protocol, or am I still missing something here? – Bob Aman May 22 '12 at 14:32
  • 1
    Yes, you are right. My comment is a casual one, not meant to be crystal clear. Of course, there is a rigid conversation between endpoints to replicate: a protocol. But the cool thing is that this conversation is simply a client connecting and making normal updates. There is no magic out-of-band channel for replication. I describe the conceptual model a bit more here: http://stackoverflow.com/questions/4766391/what-is-the-couchdb-replication-protocol-is-it-like-git – JasonSmith May 23 '12 at 04:03
  • CouchDB is actually designed to be exposed directly to users, like an app server. Of course, many people successfully use it in a traditional 3-tier model too (like MySQL). The decision about exposing to users comes down to whether you can work with CouchDB's users and authentication model. That is either a life saver (if your app fits with that model) or a deal breaker (if it doesn't) – JasonSmith May 23 '12 at 04:05
  • Yeah, I'm aware of the design choice around their auth model. It's not a deal breaker as far as I can tell, but I'm definitely not exposing it directly to users. I'll probably be deploying a BigCouch instance. – Bob Aman May 24 '12 at 11:23