[jira] [Commented] (COUCHDB-1623) Replication of user database and conflicts

["Dave Cottlehuber (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/COUCHDB-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510356#comment-13510356 ] 

Dave Cottlehuber commented on COUCHDB-1623:
-------------------------------------------

Hi Fedor,

Unless I'm missing something this is a WONTFIX.

Some clarifications:

The _users DB is just a normal DB, except that you must be a server admin to see docs other than yours. I am assuming that you don't have access, and therefore what you think you're replicating doesn't contain the necessary fields like hashed salted passwords. The npm registry uses a normal _users db for auth, and I'm guessing but can't tell that public_users is a view on top of that stripping out the salted hashed passwords, with a rewrite rule for prettiness. If you access https://user:passwd@isaacs.iriscouch.com/_session you'll see the npm service uses a standard _users DB.

compare curl http://isaacs.iriscouch.com/public_users/org.couchdb.user%3Adch or http://isaacs.iriscouch.com/public_users/org.couchdb.user%3Afedor.indutny for example with curl -k https://user:passwd@isaacs.iriscouch.com/_users/org.couchdb.user%3Adch using your npm username and then https://user:passwd@isaacs.iriscouch.com/_users/org.couchdb.user%3Afedor.indutny you'll see the difference.

You may find that duplicating your fedor.indutny doc from the real npm _users db might be enough to get your duplicated NPM working, but it depends if there are other views in the _users DB (which you won't have access to the ddocs to read) that are required.

Conflicts:
These are normal in a multi-master replication environment. If you don't replicate conflicts, how will different couch instances ever resolve & potentially re-integrate those differing versions? CouchDB's role is simply to replicate conflicts to all nodes, ensure a consistent algorithm is in place for choosing a winning version, and then it's up to the application developer to decide how to handle those conflicts. 

If you have more questions on this, best to email user@ or hop on irc.

A+
Dave

                
> Replication of user database and conflicts
> ------------------------------------------
>
>                 Key: COUCHDB-1623
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-1623
>             Project: CouchDB
>          Issue Type: Bug
>          Components: Database Core, Replication
>            Reporter: Fedor Indutny
>
> Heya,
> I'm trying to setup a private couchdb clone of npm repository: http://isaacs.iriscouch.com/registry
> And apparently I'll need to make authorization work, I've replicated http://isaacs.iriscouch.com/public_users database and set is as authentication_db. But authorization doesn't seem to be working, because couchdb's database contains a lot of conflicts for almost every user... So, basically how could one resolve it? And why documents with conflicts were replicated at all?
> Also, after removing conflicting revisions, authentication doesn't seem to be working (while it does in upstream database).
> Cheers,
> Fedor.

--
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