couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave Cottlehuber (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-1623) Replication of user database and conflicts
Date Wed, 05 Dec 2012 08:31:00 GMT

    [ 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

Mime
View raw message