On Thu, Nov 8, 2012 at 7:19 PM, Randall Leeds <[email protected]> wrote: > Benoit, could you explain a bit more what you mean by "the issue related to > the coordinated node". > I was referrering to the scenario where a couchdb node acts as a replication gateway only (where source and remotes are different nodes than the one coordinating the replication).
> I feel that TLS is the real security. I also favor using the _replicator > document ID as the checkpoint ID (it makes it impossible to have two > identical replications with different names, and I think this is good). I > would support the ability to specify the checkpoint ID, in any case, as I > believe Benoit is right that applications may want or needer finer control > over routing and checkpoints. > +1 > > On Mon, Nov 5, 2012 at 3:06 PM, Benoit Chesneau (JIRA) <[email protected]>wrote: > >> >> [ >> https://issues.apache.org/jira/browse/COUCHDB-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491019#comment-13491019] >> >> Benoit Chesneau commented on COUCHDB-1259: >> ------------------------------------------ >> >> There is a potential security issue using a remote node id like in the >> second part of the patch. Local to local there is none. >> >> >> I am + 1 for fixing the issue related to the coodinated node. >> >> > Replication ID is not stable if local server has a dynamic port number >> > ---------------------------------------------------------------------- >> > >> > Key: COUCHDB-1259 >> > URL: https://issues.apache.org/jira/browse/COUCHDB-1259 >> > Project: CouchDB >> > Issue Type: Bug >> > Components: Replication >> > Affects Versions: 1.1 >> > Reporter: Jens Alfke >> > Assignee: Robert Newson >> > Priority: Blocker >> > Fix For: 1.3 >> > >> > Attachments: couchdb-1259.patch, couchdb-1259.patch >> > >> > >> > I noticed that when Couchbase Mobile running on iOS replicates to/from a >> remote server (on iriscouch in this case), the replication has to fetch the >> full _changes feed every time it starts. Filipe helped me track down the >> problem -- the replication ID is coming out different every time. The >> reason for this is that the local port number, which is one of the inputs >> to the hash that generates the replication ID, is randomly assigned by the >> OS. (I.e. it uses a port number of 0 when opening its listener socket.) >> This is because there could be multiple apps using Couchbase Mobile running >> on the same device and we can't have their ports colliding. >> > The underlying problem is that CouchDB is attempting to generate a >> unique ID for a particular pair of {source, destination} databases, but >> it's basing it on attributes that aren't fundamental to the database and >> can change, like the hostname or port number. >> > One solution, proposed by Filipe and me, is to assign each database (or >> each server?) a random UUID when it's created, and use that to generate >> replication IDs. >> > Another solution, proposed by Damien, is to have CouchDB let the client >> work out the replication ID on its own, and set it as a property in the >> replication document (or the JSON body of a _replicate request.) This is >> even more flexible and will handle tricky scenarios like full P2P >> replication where there may be no low-level way to uniquely identify the >> remote database being synced with. >> >> -- >> This message is automatically generated by JIRA. >> If you think it was sent incorrectly, please contact your JIRA >> administrators >> For more information on JIRA, see: http://www.atlassian.com/software/jira >>
