4

I am working on OpenSuse, and I try to do a data upload toward a dashDB Local environment through cURL utility. When I use a user/password with a simple password (no 'special' characters), it works well, but when the password contains a colon it always fails, whatever the way to specify the couple username/password.

Task working:

curl -X POST -H "Content-Type: multipart/form-data" -u "myuser:mypassword" "https://my_url" -F loadFile1=@"inputfile"

{"result":{...,"resultCode":"SUCCESS","errorMessageCode":"NONE","message":"LOAD started successfully."}

Tasks not working:

curl -X POST -H "Content-Type: multipart/form-data" -u "myuser:my:password" "https://my_url" -F loadFile1=@"inputfile"

Error 401: Basic authorization - bad header

I have tried some things like escaping the colon, replacing it by '%3A', put it in a .netrc file, put it directly in the url (https://myuser:my:password@my_url), etc., but for each case it fails...

I'm pretty sure that it's not cURL which fails, because when I do a similar task toward a Cloudant environment through cURL with a colon into the password, it works well:

[i1058@lat111 ~]$ curl -X POST -H "Content-Type: application/json" -u "myuser:my:password" http://myuser.cloudant.com/mydb/_bulk_docs -d "@inputfile"
[{"ok":true,"id":"125ac5859f1e6f0de25e0ed33abd3198","rev":"1-c7e75ed33e6efae85d053acc1008c2c6"},...]

Any ideas how to specify such a password?

Edit :

Here is the headers for both executions :

Working execution : 

[i1058@lat111 ~]$ curl -X POST -H "Content-Type: multipart/form-data" "https://user1:infotel0@192.168.42.219:8443/dashdb-api/load/local/del/USER1.EMPLOYEE?hasHeaderRow=false&delimiter=','&codePage=1208&hasDateTypes=true&dateFormat="YYYY-MM-DD"" -F loadFile1=@"outfile" -v
* About to connect() to proxy 192.168.42.219 port 3128 (#0)
*   Trying 192.168.42.219...
* Connected to 192.168.42.219 (192.168.42.219) port 3128 (#0)
* Establish HTTP proxy tunnel to 192.168.42.219:8443
* Server auth using Basic with user 'user1'
> CONNECT 192.168.42.219:8443 HTTP/1.1
> Host: 192.168.42.219:8443
> User-Agent: curl/7.29.0
> Proxy-Connection: Keep-Alive
> 
< HTTP/1.1 200 Connection established
< Date: Wed, 22 Mar 2017 13:24:05 GMT
< Content-Type: text/html
< Proxy-Connection: Keep-Alive
< Via: 1.1 TO-PROXY.****
< Connection: close
< 
* Proxy replied OK to CONNECT request
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* skipping SSL peer certificate verification
* SSL connection using TLS_RSA_WITH_AES_128_CBC_SHA
* Server certificate:
*       subject: CN=localhost,OU=dsweb,O=ibm,C=us
*       start date: Sep 08 17:37:29 2016 GMT
*       expire date: Sep 08 17:37:29 2017 GMT
*       common name: localhost
*       issuer: CN=localhost,OU=dsweb,O=ibm,C=us
* Server auth using Basic with user 'user1'
> POST /dashdb-api/load/local/del/USER1.EMPLOYEE?hasHeaderRow=false&delimiter=','&codePage=1208&hasDateTypes=true&dateFormat=YYYY-MM-DD HTTP/1.1
> Authorization: Basic dXNlcjE6aW5mb3RlbDA=
> User-Agent: curl/7.29.0
> Host: 192.168.42.219:8443
> Accept: */*
> Content-Length: 5260
> Expect: 100-continue
> Content-Type: multipart/form-data; boundary=----------------------------cbd0c10a30ab
> 
< HTTP/1.1 100 Continue
< Content-Length: 0
< Date: Wed, 22 Mar 2017 13:24:06 GMT
< HTTP/1.1 200 OK
< Date: Wed, 22 Mar 2017 13:24:06 GMT
< X-Powered-By: Servlet/3.0
< Content-Type: application/json
< Content-Length: 423
< Set-Cookie: dsweb9302=00008jj9QpxOaIwwbWcGZddJ9V8:91d35242-6b49-4d90-9c18-5543188442ec; Path=/; HttpOnly
< Expires: Thu, 01 Dec 1994 16:00:00 GMT
< Cache-Control: no-cache="set-cookie, set-cookie2"
< 
{"result":{"ROWS_COMMITTED":"","LOAD_LOGFILE":"loadlogs\/load_1982878712_USER1_EMPLOYEE_20170322-132406-UTC.txt","START_TIME":"20170322 13:24:06 UTC","LOAD_STATUS":"RUNNING","LOAD_ID":1982878712,"ROWS_LOADED":"","TABLE":"EMPLOYEE","ROWS_SKIPPED":"","END_TIME":"","SCHEMA":"USER1","ROWS_READ":"","ROWS_DELETED":"","ROWS_REJECTED":""},"resultCode":"SUCCESS","errorMessageCode":"NONE","message":"LOAD started successfully."}
* Connection #0 to host 192.168.42.219 left intact

And then the failing one :

[i1058@lat111 ~]$ curl -X POST -H "Content-Type: multipart/form-data" "https://user5:infotel%3A0@192.168.42.219:8443/dashdb-api/load/local/del/USER1.EMPLOYEE?hasHeaderRow=false&delimiter=','&codePage=1208&hasDateTypes=true&dateFormat="YYYY-MM-DD"" -F loadFile1=@"outfile" -v       
* About to connect() to proxy 192.168.42.219 port 3128 (#0)
*   Trying 192.168.42.219...
* Connected to 192.168.42.219 (192.168.42.219) port 3128 (#0)
* Establish HTTP proxy tunnel to 192.168.42.219:8443
* Server auth using Basic with user 'user5'
> CONNECT 192.168.42.219:8443 HTTP/1.1
> Host: 192.168.42.219:8443
> User-Agent: curl/7.29.0
> Proxy-Connection: Keep-Alive
> 
< HTTP/1.1 200 Connection established
< Date: Wed, 22 Mar 2017 13:22:23 GMT
< Content-Type: text/html
< Proxy-Connection: Keep-Alive
< Via: 1.1 TO-PROXY.****
< Connection: close
< 
* Proxy replied OK to CONNECT request
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* skipping SSL peer certificate verification
* SSL connection using TLS_RSA_WITH_AES_128_CBC_SHA
* Server certificate:
*       subject: CN=localhost,OU=dsweb,O=ibm,C=us
*       start date: Sep 08 17:37:29 2016 GMT
*       expire date: Sep 08 17:37:29 2017 GMT
*       common name: localhost
*       issuer: CN=localhost,OU=dsweb,O=ibm,C=us
* Server auth using Basic with user 'user5'
> POST /dashdb-api/load/local/del/USER1.EMPLOYEE?hasHeaderRow=false&delimiter=','&codePage=1208&hasDateTypes=true&dateFormat=YYYY-MM-DD HTTP/1.1
> Authorization: Basic dXNlcjU6aW5mb3RlbDow
> User-Agent: curl/7.29.0
> Host: 192.168.42.219:8443
> Accept: */*
> Content-Length: 5260
> Expect: 100-continue
> Content-Type: multipart/form-data; boundary=----------------------------69215f2ae3da
> 
< HTTP/1.1 100 Continue
< Content-Length: 0
< Date: Wed, 22 Mar 2017 13:22:24 GMT
< HTTP/1.1 401 Unauthorized
< Date: Wed, 22 Mar 2017 13:22:24 GMT
< X-Powered-By: Servlet/3.0
< Content-Type: text/html;charset=UTF-8
< $WSEP:                  <-- Here there is something strange??
< Content-Language: en-US
< Set-Cookie: dsweb9302=0000ihijrP8WYwpQW8TCOzRB-gv:91d35242-6b49-4d90-9c18-5543188442ec; Path=/; HttpOnly
< Transfer-Encoding: chunked
< Expires: Thu, 01 Dec 1994 16:00:00 GMT
< Cache-Control: no-cache="set-cookie, set-cookie2"
* HTTP error before end of send, stop sending
< 
Error 401: Basic authorization - bad header
* Closing connection 0
[i1058@lat111 ~]$ curl -X POST -H "Content-Type: multipart/form-data" "https://user5:infotel%3A0@192.168.42.219:8443/dashdb-api/load/local/del/USER1.EMPLOYEE?hasHeaderRow=false&delimiter=','&codePage=1208&hasDateTypes=true&dateFormat="YYYY-MM-DD"" -F loadFile1=@"outfile" 
Error 401: Basic authorization - bad header
Steph
  • 47
  • 1
  • 8
  • As told in the description, I have already tried with '%3A' or '%3a', with no success :( – Steph Mar 22 '17 at 12:31
  • It says "bad header", maybe checking your sent headers reveals something? And I meant URL encoded as %3a when put in the URL, when used for the -u option it splits user/password on the first colon so the second colon would become part of the password. – Daniel Stenberg Mar 22 '17 at 12:34
  • I think I have already tried this, but to be sure I have retry now : `"curl ... "https://myuser%3Amy%3Apassword@myurl" ..."` doesn't work, am I right with this url specification? I have take a look at the headers with the verbose option, but I'm not an expert. For both working and failing executions I have `HTTP/1.1 100 Continue` and then I have for the working one: `< Content-Type: application/json < Content-Length: 423` and for the failing one: `< Content-Type: text/html;charset=UTF-8 < $WSEP: < Content-Language: en-US`. I don't know if it means anything – Steph Mar 22 '17 at 13:08
  • You still need *one* colon to separate the user from the password in the URL. And please add the response headers you get back into the question! – Daniel Stenberg Mar 22 '17 at 13:10
  • any solution found? have you tried to use variables? store the user and password in distinct variables and then run the command line using these variables? – Tuckbros Feb 11 '20 at 12:44
  • Use $' ' as outlined in the answer to [this](https://stackoverflow.com/questions/48009744/how-to-escape-special-characters-in-header-of-curl-command) question – Colin Daly Jun 02 '21 at 00:13

1 Answers1

2

Recently had a similar problem authenticating with an API that required username:usergroup passed as the username with a colon in between. Adding double quotes around the username:usergroup worked for me.

This did not work:

-u "username:usergroup:password"

This did work:

-u ""username:usergroup":password"

Therefore, this should work for a password containing a colon:

-u "username:"password""
mustaccio
  • 18,234
  • 16
  • 48
  • 57
Ashlee
  • 39
  • 3