XDCR fails when admin password contains @ in the password

Farshid Ghods added a comment - 08/Mar/13 1:14 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...

Junyi Xie added a comment - 08/Mar/13 1:37 PM Aliaskey, I think you have a recent on validating username and password. Does that solve the problem?

Aliaksey Artamonau added a comment - 08/Mar/13 1:42 PM No, my recent commits were unrelated to XDCR. So I guess we still need to fix it.

Junyi Xie added a comment - 08/Mar/13 1:50 PM Aliaskey, it is more about a generic password validation issue in ns_server. XDCR code does not (and should not) validate Couchbase server Admin password contains @ or not. Can you please take over this issue?

Aliaksey Artamonau added a comment - 08/Mar/13 1:53 PM Sure, I'll take a look.

Junyi Xie added a comment - 08/Mar/13 3:02 PM I just found remote_cluster_info is able to correctly talk to remote cluster using password with @. The issue could be within XDCR or CouchDB.

Junyi Xie added a comment - 08/Mar/13 3:38 PM - edited Looks to me root cause is couchdb/src/couchdb/couch_httpd:unquote() is unable to parse the "Host" from token if the password contains '@' Suppose we have a cluster with admin passord "asdas@", In xdc_rep_utils:get_master_db(), the input url is " http://Administrator:asdas%40@127.0.0.1:9501/default%2f0%3b6f2220d6e34f4a4c4de0697a3f9821dc/ " which is correct since it translate '@' to '%40' in the URL However, after couch_httpd:unquote(Token) parse the token [Scheme, Host, DbName0] = [couch_httpd:unquote(Token) || Token <- string:tokens(DbUrl0, "/")], The username:password in Host becomes "Administrator:asdas@@127.0.0.1:9501", which fails all subsequent HTTP request to remote cluster. [xdcr:debug,2013-03-08T16:31:31.532, n_0@127.0.0.1 :<0.1236.0>:xdc_rep_utils:get_master_db:288]xdcr-junyi: scheme: "http:", host: "Administrator:asdas@@127.0.0.1:9501", DbName0: "default/0;6f2220d6e34f4a4c4de0697a3f9821dc" Hand over to couchdb guys to look at it further. Hi Chris, I am not sure who owns couch_httpd module, please assign to right person if necessary. Thanks!

J Chris Anderson added a comment - 08/Mar/13 4:03 PM I'm not sure who owns this module right now. I bet the fix is simple, but I don't have a development environment for the server. It looks like the implementation just falls back to mochiweb, so really we should file a bug / patch against upstream. https://github.com/apache/couchdb/blob/master/src/couchdb/couch_httpd.erl#L532

Aliaksey Artamonau added a comment - 19/Mar/13 6:39 PM http://review.couchbase.org/25250

Maria McDuff added a comment - 05/Apr/13 3:35 AM pls verify in 2.0.2

Thuan Nguyen added a comment - 10/Apr/13 5:37 PM Verified on build 2.0.2-760. Setup both source and destination password with @ in password. xdcr works as expected. Items from source are replicated in destination.

Thuan Nguyen added a comment - 10/Apr/13 5:38 PM Verified in centos 5.8 64bit on both source and destination