XDCR fails when admin password contains special characters

Dipti Borkar added a comment - 09/Oct/12 12:28 AM This could be a common issue. let's try to fix in 2.0

Dipti Borkar added a comment - 09/Oct/12 12:29 AM Is this something for ns_server?

Aleksey Kondratenko added a comment - 09/Oct/12 11:06 AM Yes it is. Something I'm not aware of. Will test and fix if needed

Aleksey Kondratenko added a comment - 09/Oct/12 11:53 AM Something happens most likely in couch's http db wrapper code. Administrator/asd#asd gets transformed to this when it arrives to capi_frontend on receiving side: {"Administrator","asd%23asd"} So apparently there's some extra layer of escaping or missing unescaping somewhere

Aleksey Kondratenko added a comment - 09/Oct/12 11:53 AM CC-ing Filipe

Aleksey Kondratenko added a comment - 09/Oct/12 11:53 AM CC-ing Damien

Junyi Xie added a comment - 09/Oct/12 5:30 PM - edited XDCR does not keep and maintain password of remote clusters, and XDCR should not do that. All authentication info XDCR using is from vbucket map, which is returned from remote_cluster_info, fetching vbucket map from remote node. The issue here is that in vbucket map retrieved from remote node, the password is transformed from "123#123" to "123%23123" due to escaping. [xdcr:debug,2012-10-09T15:11:36.705, n_0@127.0.0.1 :<0.1853.0>:xdc_vbucket_rep:init_replication_state:342]xdcr-junyi: RemoteBucket: {remote_bucket,                               <<"7efa38c558ed81858d690c47577a1c9c">>,                               <<"bf353b193ba8bd056b44e12a532bdc72">>,                               {dict,64,16,16,8,80,48,                                   {[],[],[],[],[],[],[],[],[],[],[],[],[],[],                                    [],[]},                                   {{[[0,                                       <<" http://Administrator:123%23123@127.0.0.1:9501/default%2f0%3b7efa38c558ed81858d690c47577a1c9c ">>],                                      [16,                                       <<" http://Administrator:123%23123@127.0.0.1:9501/default%2f16%3b7efa38c558ed81858d690c47577a1c9c ">>],                                      [32,                                       <<" http://Administrator:123%23123@127.0.0.1:9501/default%2f32%3b7efa38c558ed81858d690c47577a1c9c ">>],                                      [48,                                       <<" http://Administrator:123%23123@127.0.0.1:9501/default%2f48%3b7efa38c558ed81858d690c47577a1c9c ">>]], ns_server vbucket map builder, or remote_cluster_info should make sure password is correct, which can be used by XDCR.

Dipti Borkar added a comment - 11/Oct/12 4:17 PM changes on gerrit.

Aleksey Kondratenko added a comment - 11/Oct/12 5:32 PM http://review.couchbase.org/#/c/21461/

Ketaki Gangal added a comment - 22/Oct/12 11:44 AM Tested on 1874, no longer seeing this issue.

Jasdeep Jaitla added a comment - 08/Mar/13 1:09 PM A user on IRC reported this issue with 2.0 and XDCR, he had a password with an @ in it. <Phibs> so replication definitely fails when the password has special chars such as @ in it <Phibs> you guys need to escape/encode that stuff <Phibs> http://www.bsd-unix.net/seitz/jing/2013-03-08_1406.png <scalabl3> i was just clarifying that you saw that bug appear again in the right place, meaning it was XDCR, not just "in-cluster" replica's <Phibs> it was under 'create replication' <Phibs> the last 10 errors button showed up under 'status' <Phibs> vs 'replicating' <Phibs> and it had my password listed (minus the @) as ["Firstpart","Secondpart"] and failures he solved it by changing his password...

Farshid Ghods added a comment - 08/Mar/13 1:13 PM so looks like this issue is not fixed yet , or at least for the special char '@'