Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of jochenkempf@gmail.com
 designates 209.85.215.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=fvYoC0XMR5SmxR0gh8rOhQ7iAao5V5eS78HFC8IczmuKRXtR7gFauF0S79tzliDJqW
         pMJ07L9opEVg+TqlJzLBaabo41YHDoKX79lg4gZo+TutUPrcmugmcZ7xP+0mFmlxcVu3
         jat0Iw+LZ4/cohJw0RzYMGghoMWaBvjB91Ezw=
MIME-Version: 1.0
In-Reply-To: <C9FC5F4F-9852-44E7-A004-DE9B6CC4A5B9@googlemail.com>
References: <AANLkTinw2UEo7=Y1r7Scc92D1qzkGCdFEFOSmP454LF4@mail.gmail.com>
	<C9FC5F4F-9852-44E7-A004-DE9B6CC4A5B9@googlemail.com>
From: Jochen Kempf <jochenkempf@gmail.com>
Date: Wed, 11 Aug 2010 10:07:06 -0400
Message-ID: <AANLkTi=AvRpQUs7CrpG3gyaG7ox2WyU3YDQGsJk__6Bg@mail.gmail.com>
Subject: Re: Replication error using basic authentication on nginx
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1

Hi Daniel,

I also tried replication disabling basic auth and setting the
authorization header with "proxy_set_header Authorization
$http_authorization;" in nginx.

Unless I didn't do something wrong here it should work, right?
But I get the same error during replication!

I think I'll have to wait the new CouchDB releases as J Chris Anderson
recommended here:

------------------------
sorry the list keeps bouncing my reply. so here it is direct:

There is a bug in 0.11.1 and 1.0.0 (fixed in trunk and 0.11.2, and
will be in the 1.0.1 release which is due this week).

The 0.11.2 release has been approved, currently we're just waiting for
it to be uploaded to the mirrors and the website. Watch this space for
details: http://couchdb.apache.org/downloads.html

The bug is that the replicator "forgets" basic-auth credentials when
there is a redirect (as there is for design documents.)

The redirect for design documents is because the URL
/db/_design%2Ffoo/_view/foo is considered too ugly, so we make that
resource available at /db/_design/foo/_view/foo. To avoid having the
document in 2 places, we do a redirect, which in this case, the
replicator has to follow.

The solution is to upgrade to 0.11.2, the 1.0.x svn branch, or wait
for the 1.0.1 release. (Or turn off basic auth.) I'm not aware of
another workaround.

Chris
------------------------------------

Thanks for your reply Daniel!

2010/8/11 Daniel Truemper <truemped@googlemail.com>:
> Hi,
>
> From the gist I see that you have enabled basic authentication inside nginx. Why so? Try do disable it and only use the CouchDB authentication.
>
> In the "http response of replication" the 401 is from nginx not CouchDB. So maybe it gets mixed up somewhere...
>
> Daniel
>
>> Hi,
>>
>> I have been trying to figure out quite for a while why I cannot do
>> "pull replication using nginx basic authentication on the source
>> system.
>> I simply do not know what I am doing wrong nor why couchdb fails
>> replicating giving a not authorized error considering I can
>> successfully do a put request to a design doc.
>> I tried replication both in futon as on console but no chance to get it work :-(
>>
>> I have put a public gist at: http://gist.github.com/518113
>> which shows a couchdb log for the corresponding "pull replication, a
>> couchdb log for a put request to a design doc, the replication http
>> response, my complete nginx.conf file and my iptables. Both systems
>> use Ubuntu 10.04 and Couchdb 0.11.1.
>>
>> As I use the same credentials for both the basic authentication in
>> nginx and couchdb the put request to a design doc succeeds - why
>> doesn't the replication?
>>
>> Can anyone explain the logic of the couchdb replication log?
>> Why is there a 404 response?
>> Why are there a 301 response?
>>
>> I really got stuck with that and need to find any suitable solution to
>> use couchdb without admin party mode.
>>
>> Any hint is highly appreciated!
>
>