I managed to receive a token which looks reasonable and it is saved to the token variable.
I'm using this curl command to query the API:
curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' --header "Authorization: Bearer $token" -d '*JSON format query*' '*Link*' | jq -r
In the API documentation provided by Swagger UI, inputting the JSON format query gives a Response Code 200 with a sensible Response Body. Basically the above code is just copied from the curl command generated by Swagger UI.
But I don't receive any output from my bash script besides:
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 655 0 0 100 655 0 3266 --:--:-- --:--:-- --:--:-- 3275
[0][user#ip-xyz:/home/user/abc]
I tried playing around with the script (e.g. replacing $token with something unsensible) and still get the same output which makes me question if the token is even required and/or correct.
I have the following bash script that uses its arguments to hit a RESTful web service (via curl) and prints out both the curl request made as well as the response:
#! /bin/bash
# arguments:
# $1 - username
# $2 - password
#
# outputs:
# if the script exits with a non-zero status then something went wrong
# verify that we have all 6 required arguments and fail otherwise
if [ "$#" -ne 2 ]; then
echo "Required arguments not provided"
exit 1
fi
# set the script arguments to meaningful variable names
username=$1
password=$2
# login and fetch a valid auth token
req='curl -k -i -H "Content-Type: application/json" -X POST -d ''{"username":"$username","password":"$password"}'' https://somerepo.example.com/flimflam'
resp=$(curl -k -i -H "Content-Type: application/json" -X POST -d ''{"username":"$username","password":"$password"}'' https://somerepo.example.com/flimflam)
# echo the request for troubleshooting
echo "req = $req"
if [ -z "$resp" ]; then
echo "Login failed; unable to parse response"
exit 1
fi
echo "resp = $resp"
When I run this I get:
$ sh myscript.sh myUser 12345#45678
curl: (3) Port number ended with '"'
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (6) Could not resolve host: 12345#45678"
100 1107 100 1093 100 14 2849 36 --:--:-- --:--:-- --:--:-- 2849
req = curl -k -i -H "Content-Type: application/json" -X POST -d {"username":"$username","password":"$password"} https://somerepo.example.com/flimflam
resp = HTTP/1.1 400 Bad Request...(rest omitted for brevity)
Obviously, I'm not escaping the various layers of single- and double-quotes inside the curl statement correctly, as is indicated by outputs like:
curl: (6) Could not resolve host: 12345#45678"
and:
req = curl -k -i -H "Content-Type: application/json" -X POST -d {"username":"$username","password":"$password"} https://somerepo.example.com/flimflam
where the username/password variables are not parsing.
In reality my script takes a lot more than 2 arguments, which is why I'm changing them to have meaningful variable names (such as $username instead of $1) so its more understandable and readable.
Can anyone spot where I'm going awry? Thanks in advance!
Update
I tried the suggestion which turns the req into:
curl -k -i -H 'Content-Type: application/json' -X POST -d "{'username':'myUser','password':'12345#45678'}" https://somerepo.example.com/flimflam
However this is still an illegal curl command and instead needs to be:
curl -k -i -H 'Content-Type: application/json' -X POST -d '{"username":"myUser","password":"12345#45678"}' https://somerepo.example.com/flimflam
First, as I said in a comment, storing commands in variables just doesn't work right. Variables are for data, not executable code. Second, you have two levels of quoting here: quotes that're part of the shell syntax (which are parsed, applied, and removed by the shell before the arguments are passed to `curl), and quotes that're part of the JSON syntax.
But the second problem is actually worse than that, because simply embedding an arbitrary string into some JSON may result in JSON syntax errors if the string contains characters that're part of JSON syntax. Which passwords are likely to do. To get the password (and username for that matter) embedded correctly in your JSON, use a tool that understands JSON syntax, like jq:
userinfo=$(jq -n -c --arg u "$username" --arg p "$password" '{"username":$u,"password":$p}')
Explanation: this uses --arg to set the jq variables u and p to the shell variables $username and $password respectively (and the double-quotes around the shell variables will keep the shell from doing anything silly to the values), and creates a JSON snippet with them embedded. jq will automatically add appropriate quoting/escaping/whatever is needed.
Then, to use it with curl, use something like this:
resp=$(curl -k -i -H "Content-Type: application/json" -X POST -d "$userinfo" https://somerepo.example.com/flimflam)
Again, the double-quotes around $userinfo keep the shell from doing anything silly. You should almost always put double-quotes around variables references in the shell.
Note that I never used the req variable to store the command. If you need to print the command (or its equivalent), use something like this:
printf '%q ' curl -k -i -H "Content-Type: application/json" -X POST -d "$userinfo" https://somerepo.example.com/flimflam
echo
The %q format specifier tells the shell to add appropriate quoting/escaping so that you could run the result as a shell command, and it'd work properly. (And the echo is there because printf doesn't automatically add a newline at the end of its output.)
try changing this:
req='curl -k -i -H "Content-Type: application/json" -X POST -d ''{"username":"$username","password":"$password"}'' https://somerepo.example.com/flimflam'
to this
req="curl -k -i -H 'Content-Type: application/json' -X POST -d \"{'username':'$username','password':'$password'}\" https://somerepo.example.com/flimflam"
and similarly for the resp
ah those pesky "curly" thingies...
how 'bout...
req="curl -k -i -H 'Content-Type: application/json' -X POST -d '{\"username\":\"$username\",\"password\":\"$password\"}' https://somerepo.example.com/flimflam"
This needs even more escaping:
With:
resp=$(curl -k -i -H "Content-Type: application/json" -X POST -d "{\"username\":\"$username\",\"password\":\"$password\"}" https://somerepo.example.com/flimflam)
In bash, the variables are still expanded when they're inside single quotes that are inside double quotes.
And you'll need the \" double quotes in the payload as per the JSON definition.
EDIT: I rerun the curl through a HTTP proxy and corrected the script line (see above, removed the single quotes). Results (in raw HTTP) are now:
POST /flimflam HTTP/1.1
Host: somerepo.example.com
User-Agent: curl/7.68.0
Accept: */*
Content-Type: application/json
Content-Length: 44
Connection: close
{"username":"user","password":"12345#abcde"}
(which should be fine)
I'm issuing the following command in zsh to send a POST request with a bearer token.
curl -o -X POST -H "Authorization: Bearer ${TOKEN}" http://localhost:8090/services/item/0
The output I get is the following:
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (6) Could not resolve host: POST
Update 1
I posted a wrong command which I have corrected now. This is what I'm issuing:
curl -X POST -H "Authorization: Bearer ${TOKEN}" http://localhost:8090/services/item/0
I discovered that the behavior is probably related to running the command in a ZSH. When using Bash the call works fine.
The parameter that follows -o is a file name. Your command line begins with:
curl -o -X POST
... which then means that it will save the output to a file named -X. Then the following word (POST) will be treated as a URL since it doesn't start with a dash...
Using that URL (or host name rather) then causes this error:
Could not resolve host: POST
... because curl fails to resolve that host name. It seems there's no host in your network with that name!
I check must work:
curl -H "Authorization: Bearer ${TOKEN}" http://localhost:8090/services/item/0
Or:
curl -H "Authorization: Bearer ${TOKEN}" http://localhost:8090/services/item/0 -o output.txt
This question already has answers here:
Expansion of variables inside single quotes in a command in Bash
(8 answers)
Closed 3 years ago.
I'm trying to use two variables in a curl command on my ksh program, but it doesn't work.
Example:
Original URL
curl -s --header "Content-Type:application/json" --header "Accept:application/json" -X POST --data-binary '{"username":"foo","password":"foo_pwd"}' URL site
On my program
user=foo
pwd=foo_pwd
curl -s --header "Content-Type:application/json" --header "Accept:application/json" -X POST --data-binary '{"username":"'"$user"'","password":"'"$pwd"'"}' URL site
I've tried also to escape double quote with backslash but it also doesn't work.
First examine your script
user=foo
pwd=foo_pwd
echo '{"username":"'"$user"'","password":"'"$pwd"'"}'
Then run
user=foo
pwd=foo_pwd
curl -s --header "Content-Type:application/json" --header "Accept:application/json" -X POST https://example.com --data-binary '{"username":"'"$user"'","password":"'"$pwd"'"}'
I am able to execute the below cURL request (generated in PostMan) through a Git Bash in windows, and receive a response as expected.
curl -X GET \ https://test.amazon.com/production/john.stones \
-H 'authorization: Bearer dfgjdrjkdrt' \
-H 'cache-control: no-cache' \
-H 'content-type: application/json' \
-H 'postman-token: 53a3fs9a-5ce3-10fe-7f0a-33e9695ec514' \
-H 'referer: king'
I wish to run multiple cURL requests, around a thousand like the above, with the name being the value that changes in each request. I tried placing them into a batch file but each line is taken as a command, so a bit unsure as to how to structure them. Anyone know how I can run multiple cURL requests, either in sequence or parallel, in Windows 10?
I have addressed this by listing each cURL request in a batch file, replacing all single quotes with double and removed all '\' generated in Postman to divide headers. Only after this does windows run the requests successfully.