You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by "Fedor Indutny (JIRA)" <ji...@apache.org> on 2012/12/05 08:34:58 UTC
[jira] [Created] (COUCHDB-1623) Replication of user database and
conflicts
Fedor Indutny created COUCHDB-1623:
--------------------------------------
Summary: 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
[jira] [Resolved] (COUCHDB-1623) Replication of user database and
conflicts
Posted by "Dave Cottlehuber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dave Cottlehuber resolved COUCHDB-1623.
---------------------------------------
Resolution: Won't Fix
Assignee: Dave Cottlehuber
> 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
> Assignee: Dave Cottlehuber
>
> 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
[jira] [Commented] (COUCHDB-1623) Replication of user database and
conflicts
Posted by "Fedor Indutny (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510361#comment-13510361 ]
Fedor Indutny commented on COUCHDB-1623:
----------------------------------------
Ok, I'll try to figure it out in some other way, thank you!
> 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
> Assignee: Dave Cottlehuber
>
> 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
[jira] [Commented] (COUCHDB-1623) Replication of user database and
conflicts
Posted by "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