You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Jochen Kempf <jo...@gmail.com> on 2010/08/11 00:32:43 UTC

Replication error using basic authentication on nginx

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!

Re: Replication error using basic authentication on nginx

Posted by Jochen Kempf <jo...@gmail.com>.
Hopefully I can figure out one day what is going wrong with ssl
replication (nginx) - by now I just exclude design docs from
replication using a replication filter.

Filter doc:
{
   "_id": "_design/Replication",
   "_rev": "1-26c7c5e5b28a0b67caad16540207982e",
   "filters": {
       "no_design": "function(doc,req){       var s =
doc._id.substr(0,7);       if (s == '_design') {         return false;
      } else {         return true;       }     }"
   }
}





2010/8/12 Jochen Kempf <jo...@gmail.com>:
> Has anyone else tried pull replication with ssl secured CouchDB 0.11.2?
>
> I just tried it and.....still the same problem: design_docs are not
> replicated :(
>
> Here is the log:
> [Fri, 13 Aug 2010 01:03:26 GMT] [info] [<0.31773.0>] 201.215.27.127 -
> - 'GET' /test/_design%2FTest?open_revs=["3-fd3452225ed1b85e7adabb6027f50224"]&revs=true&latest=true&att_encoding_info=true
> 301
>
> I am using Erlang R13B03 (erts-5.7.4) on both servers - do I have to
> use the latest Erlang version?
>
>
>
> 2010/8/11 Jochen Kempf <jo...@gmail.com>:
>> 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 <tr...@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!
>>>
>>>
>>
>

Re: Replication error using basic authentication on nginx

Posted by Jochen Kempf <jo...@gmail.com>.
Has anyone else tried pull replication with ssl secured CouchDB 0.11.2?

I just tried it and.....still the same problem: design_docs are not
replicated :(

Here is the log:
[Fri, 13 Aug 2010 01:03:26 GMT] [info] [<0.31773.0>] 201.215.27.127 -
- 'GET' /test/_design%2FTest?open_revs=["3-fd3452225ed1b85e7adabb6027f50224"]&revs=true&latest=true&att_encoding_info=true
301

I am using Erlang R13B03 (erts-5.7.4) on both servers - do I have to
use the latest Erlang version?



2010/8/11 Jochen Kempf <jo...@gmail.com>:
> 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 <tr...@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!
>>
>>
>

Re: Replication error using basic authentication on nginx

Posted by Jochen Kempf <jo...@gmail.com>.
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 <tr...@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!
>
>

Re: Replication error using basic authentication on nginx

Posted by Daniel Truemper <tr...@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!