ban local endpoints #41
Conversation
|
+1 though I still don't understand how cluster doesn't knows about his own databases to reference them by simple name, not url. |
|
it's ambiguous. "foo" is that a clustered database or a node-local database? |
|
Oblivously, for cluster _replicator it's cluster database while for node _replicator it's local database (: |
|
It might be possible to support this. I'll try. |
|
That would be awesome if you could. In the end, that's one more point for backward compatibility (: |
|
it's tricky. I think I could fix the ambiguity between cluster/not-cluster, but there's an authentication issue. we don't know who wrote the replicator doc. even if we did, we don't have their password. so we can't convert local to remote like we do for _replicate (which we can do because we have the authenticated Req object). |
|
the best I can think of is to alter the document as it's being written, which will involve writing the user's password into the document on the fly, which seems like a really bad idea. |
|
But if we inject userCtx based on who created document which we already support in order to let replicator access to local dbs? |
2 participants
Using "local" names in source and target yields unexpected behaviour (creating unsharded dbs which are also, by default, unreachable). This patch insists that "source" and "target" are http or https URL's.
COUCHDB-2980