I want to execute an api call to a Saas platform. When I generate the api keys with my account in the platform then i get 2 things:-
api key id : 631f39f37564not/631f39f475646real/635c1192756key
Secret key : -----BEGIN RSA PRIVATE KEY----- ABCDE1234 -----END RSA PRIVATE KEY-----
I am executing the api with my following bash script
#!/bin/bash
export FIELD=90
HOST=https://example.com
PUT_BODY="{\"value\":\"${FIELD}\",\"valueObjectType\":\"String\"}"
curl -sk -X PUT "${HOST}/api/v3/xyz/endpoint" \
-H 'content-type: application/json' \
-H 'x-requested-with: XMLHttpRequest' \
-H "referer: ${HOST}/" \
-H "Authorization: apikey 631f39f37564not/631f39f475646real/635c1192756key" \
-d"${PUT_BODY}" | jq '.'
I get 401 unauthorized error
{
"error": {
"status_code": 401,
"status": "Unauthorized"
}
}
Is -H "Authorization: apikey 631f39f37564not/631f39f475646real/635c1192756key" the correct way to specify the apikey or do i need to append secret also in the request?
Edit: I cannot use bearer token, need to use api key only.
I converted your curl to PHP and changed the URL to my test site that response with the request header. Because you did not provide a link to the api documentation, I do not know if the request header is what they want.
I find the output request header is the first step in trouble shooting curl requests.
This is what my test site received:
BODY=
${PUT_BODY}
BODY urlencoded
${PUT_BODY}
Your request headers:
Content-Length: 11
Content-Type: application/json
Accept: */*
Referer: ${HOST}/
X-Requested-With: XMLHttpRequest
What is missing? The authorization not included?
So let's try another way.
When the is a key and secret they are usually posted as post data in a POST request.
Yours is a PUT request? No documentation.
When I tried your
"Authorization: apikey 631f39f37564not/631f39f475646real/635c1192756key"
curl ignored it and it was not in the request header.
Why the application/json content type header?
I would expect
Content-Type: application/x-www-form-urlencoded
And I would expect the key and secret to be posted as post data:
-d 'key=<key>&secret=<secret>'
But no documentation.
If it is supposed to be a PUT then the key and secret would be in the query string following the URL.
${HOST}/api/v3/xyz/endpoint?key=<key?&secret=<secret>"
Your api key does not look good. Again no documentation.
The secret is even not in your request. You say "need to use api key only".
If that is true, why does the secret exist?
Related
Im reading this documentation:
https://api.wm.com/howtotest/#make-an-api-call
And I want to make this test request in the postman:
curl -i https://apitest.wm.com/v1/helloworld \
-H "Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJhbnlvbmVAYW55LmNvbSIsInN1YiI6Ildhc3RlIG1hbmFnZW1lbnQgIHRlYW0iLCJqdGkiOiIwQkQyRTVDQkM2RDE2Mzc0RkNFQSIsInNjb3BlIjpbInNlbGYiLCJoZWxsb3dvcmxkIl0sImlhdCI6MTQ5MDg5ODk1NSwiZXhwIjoxNTIyNDM0OTU1fQ.O2k-senypXFZQwW4Ln3mBg60qzOSo-diPQWVfir3m6Q" \
-H "ClientId: 0BD2E5CBC6D16374FCEA" \
-H "Request-Tracking-Id: 12132"
But i recived response like this:
{
"message": "'eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJhbnlvbmVAYW55LmNvbSIsInN1YiI6Ildhc3RlIG1hbmFnZW1lbnQgIHRlYW0iLCJqdGkiOiIwQkQyRTVDQkM2RDE2Mzc0RkNFQSIsInNjb3BlIjpbInNlbGYiLCJoZWxsb3dvcmxkIl0sImlhdCI6MTQ5MDg5ODk1NSwiZXhwIjoxNTIyNDM0OTU1fQ.O2k-senypXFZQwW4Ln3mBg60qzOSo-diPQWVfir3m6Q' not a valid key=value pair (missing equal-sign) in Authorization header: 'Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJhbnlvbmVAYW55LmNvbSIsInN1YiI6Ildhc3RlIG1hbmFnZW1lbnQgIHRlYW0iLCJqdGkiOiIwQkQyRTVDQkM2RDE2Mzc0RkNFQSIsInNjb3BlIjpbInNlbGYiLCJoZWxsb3dvcmxkIl0sImlhdCI6MTQ5MDg5ODk1NSwiZXhwIjoxNTIyNDM0OTU1fQ.O2k-senypXFZQwW4Ln3mBg60qzOSo-diPQWVfir3m6Q'."
}
This is the example of their official documentation, how it can be it doesnt works, or I didnt do something good?
I think that the error message is potentially misleading. If you are using the test example you need to request a clientid and token from WM per the documentation.
From the documentation:
With a valid access token and clientId, you are ready to make requests to Waste Management API.
I am trying to test one of Mix Panel's API endpoints. I'm using Postman to do this, and in Mix Panel's documentation they use cURL to show you how to make the request. When entering the URL, and the POST data for the request, it works in the sense that it hits the right place, and tells me that I need to be authenticated by adding an authorization header. What I'm confused on is, what should the key be for the header ? in their cURL example its -u API_SECRET, so would the authorization header key be 'username' ?
From documentation
# this uses a test project API secret, replace ce08d087255d5ceec741819a57174ce5
# with your own API secret
curl https://mixpanel.com/api/2.0/jql \
-u ce08d087255d5ceec741819a57174ce5: \
--data-urlencode params='{"from_date":"2016-01-01", "to_date": "2016-01-07"}' \
--data-urlencode script='function main(){ return Events(params).groupBy(["name"], mixpanel.reducer.count()) }'
If I wanted to create an AJAX query for example
$.ajax({
method: 'POST',
url: 'https://mixpanel.com/api/2.0/jql',
data: {
'params': '{"from_date":"2016-01-01", "to_date": "2016-01-07"}',
'script': '\'function main(){ return Events(params).groupBy(["name"], mixpanel.reducer.count()) }\''
},
headers: {
<WHAT GOES HERE>: API_SECRET
}
}).then(function success(response){
console.log('SUCCESS');
console.log(response)
}, function error(response){
console.log('There was an error running JQL');
console.log(response.error)
});
In this case, your API_SECRET is the username and there is no password. So using curl -u <API_SECRET>: without any "username" key is correct.
From the mixpanel documentation on an example call https://mixpanel.com/help/reference/data-export-api
Authorization steps The Data Export API accepts Basic access
authentication over HTTPS as an authorization method. To make an
authorized request, put your project's API Secret in the "username"
field of the Basic access authentication header. Make sure you use
HTTPS and not HTTP - our API rejects requests made over HTTP, since
this sends your API Secret over the internet in plain text.
Examples Here's an example of a properly-authenticated request made
with cURL:
curl https://mixpanel.com/api/2.0/segmentation/ \
-u YOUR_API_SECRET: \
-d from_date="2016-02-11" -d to_date="2016-02-11" -d event="Viewed Page"
Currently, I'm working on a very light version of Docker containers orchestrator and I have to be able to get image digest from public Docker Hub registry. I want to use Docker Registry API v2 for this purposes.
I'm trying to get authorization token using following API call:
curl https://auth.docker.io/token?service=index.docker.io&scope=repository:alpine:pull
... and I get a response like following:
{"token":"eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCIsIng1YyI6WyJNSUlDTHpDQ0FkU2dBd0lCQWdJQkFEQUtCZ2dxaGtqT1BRUURBakJHTVVRd1FnWURWUVFERXp0Uk5Gb3pPa2RYTjBrNldGUlFSRHBJVFRSUk9rOVVWRmc2TmtGRlF6cFNUVE5ET2tGU01rTTZUMFkzTnpwQ1ZrVkJPa2xHUlVrNlExazFTekFlRncweE5qQTFNekV5TXpVNE5UZGFGdzB4TnpBMU16RXlNelU0TlRkYU1FWXhSREJDQmdOVkJBTVRPMUV6UzFRNlFqSkpNenBhUjFoT09qSlhXRTA2UTBWWFF6cFVNMHhPT2tvMlYxWTZNbGsyVHpwWlFWbEpPbGhQVTBRNlZFUlJTVG8wVWtwRE1Ga3dFd1lIS29aSXpqMENBUVlJS29aSXpqMERBUWNEUWdBRVo0NkVLV3VKSXhxOThuUC9GWEU3U3VyOXlkZ3c3K2FkcndxeGlxN004VHFUa0N0dzBQZm1SS2VLdExwaXNTRFU4LzZseWZ3QUFwZWh6SHdtWmxZR2dxT0JzakNCcnpBT0JnTlZIUThCQWY4RUJBTUNCNEF3RHdZRFZSMGxCQWd3QmdZRVZSMGxBREJFQmdOVkhRNEVQUVE3VVROTFZEcENNa2t6T2xwSFdFNDZNbGRZVFRwRFJWZERPbFF6VEU0NlNqWlhWam95V1RaUE9sbEJXVWs2V0U5VFJEcFVSRkZKT2pSU1NrTXdSZ1lEVlIwakJEOHdQWUE3VVRSYU16cEhWemRKT2xoVVVFUTZTRTAwVVRwUFZGUllPalpCUlVNNlVrMHpRenBCVWpKRE9rOUdOemM2UWxaRlFUcEpSa1ZKT2tOWk5Vc3dDZ1lJS29aSXpqMEVBd0lEU1FBd1JnSWhBTzYxSWloN1FUcHNTMFFIYUNwTDFZTWNMMnZXZlNydlhHbHpSRDEwN2NRUEFpRUFtZXduelNYRHplRGxqcDc4T1NsTFFzbnROYWM5eHRyYW0xU0kxY0ZXQ2tJPSJdfQ.eyJhY2Nlc3MiOltdLCJhdWQiOiJpbmRleC5kb2NrZXIuaW8iLCJleHAiOjE0NzQ1NDcyODMsImlhdCI6MTQ3NDU0Njk4MywiaXNzIjoiYXV0aC5kb2NrZXIuaW8iLCJqdGkiOiIzVTdCazF4dm9CLVA0MGJWVF9JSiIsIm5iZiI6MTQ3NDU0Njk4Mywic3ViIjoiIn0.516fS692WGHNi5Sc44iB8OFSLairrM6n1zNvVo5KXAxlsxsP4rE7VDmW5d0YqvTYeKfZAYIi9yEptx4xJlQ6DA"}
It seems that everything is okay and I'm trying to use obtained token for my next API call:
curl -i -H "Authorization: Bearer eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCIsIng1YyI6WyJNSUlDTHpDQ0FkU2dBd0lCQWdJQkFEQUtCZ2dxaGtqT1BRUURBakJHTVVRd1FnWURWUVFERXp0Uk5Gb3pPa2RYTjBrNldGUlFSRHBJVFRSUk9rOVVWRmc2TmtGRlF6cFNUVE5ET2tGU01rTTZUMFkzTnpwQ1ZrVkJPa2xHUlVrNlExazFTekFlRncweE5qQTFNekV5TXpVNE5UZGFGdzB4TnpBMU16RXlNelU0TlRkYU1FWXhSREJDQmdOVkJBTVRPMUV6UzFRNlFqSkpNenBhUjFoT09qSlhXRTA2UTBWWFF6cFVNMHhPT2tvMlYxWTZNbGsyVHpwWlFWbEpPbGhQVTBRNlZFUlJTVG8wVWtwRE1Ga3dFd1lIS29aSXpqMENBUVlJS29aSXpqMERBUWNEUWdBRVo0NkVLV3VKSXhxOThuUC9GWEU3U3VyOXlkZ3c3K2FkcndxeGlxN004VHFUa0N0dzBQZm1SS2VLdExwaXNTRFU4LzZseWZ3QUFwZWh6SHdtWmxZR2dxT0JzakNCcnpBT0JnTlZIUThCQWY4RUJBTUNCNEF3RHdZRFZSMGxCQWd3QmdZRVZSMGxBREJFQmdOVkhRNEVQUVE3VVROTFZEcENNa2t6T2xwSFdFNDZNbGRZVFRwRFJWZERPbFF6VEU0NlNqWlhWam95V1RaUE9sbEJXVWs2V0U5VFJEcFVSRkZKT2pSU1NrTXdSZ1lEVlIwakJEOHdQWUE3VVRSYU16cEhWemRKT2xoVVVFUTZTRTAwVVRwUFZGUllPalpCUlVNNlVrMHpRenBCVWpKRE9rOUdOemM2UWxaRlFUcEpSa1ZKT2tOWk5Vc3dDZ1lJS29aSXpqMEVBd0lEU1FBd1JnSWhBTzYxSWloN1FUcHNTMFFIYUNwTDFZTWNMMnZXZlNydlhHbHpSRDEwN2NRUEFpRUFtZXduelNYRHplRGxqcDc4T1NsTFFzbnROYWM5eHRyYW0xU0kxY0ZXQ2tJPSJdfQ.eyJhY2Nlc3MiOltdLCJhdWQiOiJpbmRleC5kb2NrZXIuaW8iLCJleHAiOjE0NzQ1NDcyODMsImlhdCI6MTQ3NDU0Njk4MywiaXNzIjoiYXV0aC5kb2NrZXIuaW8iLCJqdGkiOiIzVTdCazF4dm9CLVA0MGJWVF9JSiIsIm5iZiI6MTQ3NDU0Njk4Mywic3ViIjoiIn0.516fS692WGHNi5Sc44iB8OFSLairrM6n1zNvVo5KXAxlsxsP4rE7VDmW5d0YqvTYeKfZAYIi9yEptx4xJlQ6DA" https://index.docker.io/v2/alpine/manifests/latest
... and here what I've got:
HTTP/1.1 401 Unauthorized
Content-Type: application/json; charset=utf-8
Docker-Distribution-Api-Version: registry/2.0
Www-Authenticate: Bearer realm="https://auth.docker.io/token",service="registry.docker.io",scope="repository:alpine:pull",error="invalid_token"
Date: Thu, 22 Sep 2016 12:27:54 GMT
Content-Length: 138
Strict-Transport-Security: max-age=31536000
{"errors":[{"code":"UNAUTHORIZED","message":"authentication required","detail":[{"Type":"repository","Name":"alpine","Action":"pull"}]}]}
Does anybody have ideas why token aouthentication fails for such simple flow?
The response in the Www-Authenticate header is trying to tell you what you need, although it could be more helpful.
First thing: the service you want is registry.docker.io.
Second thing: the repository name in the scope is incomplete. Official repositories only have a single-part name like alpine for the CLI, but in the registry it's properly called library/alpine.
So your token request should be:
curl "https://auth.docker.io/token?service=registry.docker.io&scope=repository:library/alpine:pull"
And then your image request is:
curl --header "Authorization: Bearer eyJh..." https://index.docker.io/v2/library/alpine/manifests/latest
And then you'll get the response.
I'm working with an API and I have to send a POST request. I know how to set a header (-H) and (-d) is the body, but what is "--user".
If I submit this with Postman, or in a text editor with axios or just regular XMLRequest, where do I add this?
The docs say it is for regular http auth.
curl -X POST -H "Content-Type: application/json" \
--user "<client_id>:<client_secret>" \
-d '{"grant_type": "client_credentials", "scope": "public"}' \
...
Late to the party, but here goes...
You can use curl with the -v (verbose) parameter to see the headers sent. You will then see that the information provided with --user is transformed into a header, such as:
Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
The text after the Basic keyword is a base64 encoded text string of the username:password combination provided with the --user parameter
To manually generate the base64 encoded credentials on Linux, you can simply call:
echo -n "username:password" | base64 -w0
For windows, save the "username:password" to a file, then use certutil.exe to create a base64 encoded file:
certutil -encode credentials.txt credentials.asc
To test this end to end, you can remove --user username:password and substitute with --header Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l and it will still authenticate just fine.
In summary, to do this manually without curl, you would need to base64 encode username:password combination. You would then need to set the HTTP Authorization header with the type as Basic along with the base64 encoded string.
--user parameter in curl used for server authentication. So if you don't define authentication type via other parameters like --digest or --negotiate, it means USER parameter for http basic authentication, it also could be combined with :PASSWORD chunk to set a password as well. The full answer on your question depends on what kind authentication is used behind API you are sending request to, and maybe curl would not be enough for it, as it support a limited set of authentication schemes ...
--user (or -u) in curl provides a basic auth to your request.
In Postman you can achieve the same result with a choice in Authorization tab.
--user "<client_id>:<client_secret>" becomes
Type: Basic Auth
Username: client_id
Password: client_secret
Specify the user name and password to use for server authentication. If you simply specify the user name, curl will prompt for a password.
If your curl request does not have any -- user, then
server that requires authentication sends back a 401 response code and an associated WWW-Authenticate: header that lists all the authentication methods that the server supports.
< HTTP/1.1 401
< WWW-Authenticate: Basic realm="oauth2/client"
Then you will know the server is using Basic authentication
You can add --basic to explicitly tell it is Basic authentication
Please refer to HTTP authentication for more information
Sometimes (depending on server implementation) the --user will negotiate a digest authenticated session. The headers for digest users are a one-time use. I believe a request to the server will first fail with a 401, but include a WWW-Authenticate response, including the digest realm, and the nonce secret. With these, a second request can be made with a new header Authorization value.
example:
Authorization: Digest username="LXAIQKBC", realm="MMS Public API", nonce="rE3sYnLXEhVMbh72JyUK7kfLIb+bAbKj", uri="/api/atlas/v1.0/groups", cnonce="YTVhM4YwMDB3ZjZjMTkxbCNiODA1ODnxZDFjOGMyMzE=", nc=00000001, qop=auth, response="7a5fcb8e4f92a665315bf62cdd87a67d", algorithm="MD5"
As an addition to Jahmic's answer, Nodejs programmers can do this to convert to base64 string:
const cryptoJS = require("crypto-js");
const base64Str = cryptoJS.enc.Base64.stringify(cryptoJS.enc.Utf8.parse(`${username}:${password}`))
So I got the data that is being sent to a specific server. Now I want to do the same using curl from my local machine to play around with specific repsonses from the server and learn more about curl as well.
Here is part of my data
POST /auth HTTP/1.1
platform: android
X-Auth-Token: <censored>
Content-Type: application/json; charset=utf-8
Host: api.blabla.com
Accept-Encoding: gzip
And the data that is being sent:
{"blabla_token": "sdsadsad", "blahblah_id": "23213", "locale": "us"}
Now when I try cURL in my dos shell, I try
curl --insecure -X POST https://api.blabla.com/auth --data '{"blabla_token": "sdsadsad", "blahblah_id": "23213", "locale": "us"}'
The response I get from cURL is this:
{"code":401,"error":"blablaTokenRequired"}
Even though I specified the token. So there are two possible scenarios because the token is correct:
It has something to do with the SSL thing? (I use --insecure because I get an SSL error otherwise)
Something about my command is not correct but I can't figure out what.
Can someone kindly help me out? I am trying everything I can without success
I am not sure if I understand your application specific right, but probably one thing you need to take into account:
man curl says:
-d, --data <data>
(HTTP) Sends the specified data in a POST request to the HTTP server, in the same way that a browser does when
a user has filled in an HTML form and presses the submit button. This will cause curl to pass the data to the
server using the content-type application/x-www-form-urlencoded. Compare to -F, --form.
-d, --data is the same as --data-ascii. --data-raw is almost the same but does not have a special interpreta‐
tion of the # character. To post data purely binary, you should instead use the --data-binary option. To URL-
encode the value of a form field you may use --data-urlencode.
As I can't see in your example the necessity of sending data as HTML form input, probably your application expects just a "raw" POST body and then you have to try this:
curl --insecure -X POST https://api.blabla.com/auth --data--binary '{"blabla_token": "sdsadsad", "blahblah_id": "23213", "locale": "us"}'
PS and for sure this is error is not about using --insecure which just asks curl to neglect ssl verification
you forgot the headers and enabling compressed encoding (gzip), however, i believe you can't force curl to only support gzip encoding using the curl command line alone, you will have to use libcurl, this will make the request say "Accept-Encoding: gzip,deflate" on most systems, using --compressed .. if that's not acceptable to you, rewrite it using libcurl (where you can force it to say only "gzip", if you wish, via CURLOPT_ENCODING )
curl -X POST https://api.blabla.com/auth --data '{"blabla_token": "sdsadsad", "blahblah_id": "23213", "locale": "us"}' --header 'platform: android' --header 'X-Auth-Token: <censored>' --header 'Content-Type: application/json; charset=utf-8' --header 'Host: api.blabla.com' --compressed
another gotcha: on some systems, there will be a default useragent header (like debian 6), while on some systems, curl comes without a default useragent (like debian 8).. you might want to use --user-agent '' too