I'm trying to use the Microsoft cognitive API for text analysis using the recommended curl method from their documentation:
curl -v -X POST "https://westus.api.cognitive.microsoft.com/text/analytics/v2.0/sentiment" -H "Content-Type: application/jscp-Apim-Subscription-Key: {bc94cba9b84748ebb2f2b79a28ee3450}" --data-ascii "{I had a wonderful experience! The rooms were wonderful and the staff were helpful.}"
But I get back:
{ "statusCode": 401, "message": "Access denied due to invalid subscription key. Make sure to provide a valid key for an active subscription." }
I also tried removing the {} surrounding token and text to be analyzed. What am I doing wrong here?
Note: yes I realize the security issue with showing key but I have re-generated thanks.
There are three issues with your request:
Content-Type header should be application/json. This is likely a copy-paste error.
Ocp-Apim-Subscription-Key header value must be the API without the curly braces. This is the cause for your 401 error.
The body must be JSON of a particular format. You can find the schema here.
Here's the rewritten request:
curl -v "https://westus.api.cognitive.microsoft.com/text/analytics/v2.0/sentiment" -H "Content-Type: application/json" -H "Ocp-Apim-Subscription-Key: $OXFORD_TEXT_KEY" --data-ascii '{"documents":[{"language":"en","id":"1234","text":"I had a wonderful experience! The rooms were wonderful and the staff were helpful."}]}'
Which should result in:
{"documents":[{"score":0.9750894,"id":"1234"}],"errors":[]}
Related
I am creating a Firebase HTTP function that uploads a file to Cloud Storage, creates a signed URL to the file, and then redirects the client to that URL. Using Postman with automatic redirect following turned on, the file is retrieved correctly. However, if I try to turn on redirects while using cURL (curl -L -H "Content-Type: application/json" "https://us-central1-example.cloudfunctions.net/exampleFunction" -d '{"example": true}'), the following error is returned by Cloud Storage:
<?xml version='1.0' encoding='UTF-8'?>
<Error>
<Code>SignatureDoesNotMatch</Code>
<Message>The request signature we calculated does not match the signature you provided. Check your Google secret key and signing method.</Message>
<StringToSign>GET
application/json
1602245678
/example.appspot.com/exampleBucket/exampleFile.txt</StringToSign>
</Error>
If I make the request with form encoded data instead, it works in cURL as well: curl -L "https://us-central1-example.cloudfunctions.net/exampleFunction" -d "example=true"
If I try to manually make a GET request to the URL in Postman, I get an equivalent error:
<?xml version='1.0' encoding='UTF-8'?>
<Error>
<Code>SignatureDoesNotMatch</Code>
<Message>The request signature we calculated does not match the signature you provided. Check your Google secret key and signing method.</Message>
<StringToSign>GET
1602246219
/www.google.com/example.appspot.com/exampleBucket/exampleFile.txt</StringToSign>
</Error>
If I paste the URL into a browser or use cURL to download the signed URL, the file is also downloaded correctly.
I am using the following function to get the signed url:
async getSignedUrl(file: File, expireAt: number): Promise<string> {
const [url] = await file
.getSignedUrl({
action: "read",
expires: expireAt
});
return url
}
which returns a signed URL in the following format:
https://storage.googleapis.com/example.appspot.com/exampleBucket/exampleFile.txt?GoogleAccessId=[Access ID]&Expires=1602246219&Signature=[Signature] (I've noted that the value of "Expires" is the same value returned in the tag).
My suspicion is that Postman and cURL adds something to the request which results in a different signature, but I am not sure exactly what is going on.
What is happening when letting cURL follow the redirect or when creating a GET request in Postman, that leads to this difference in signature?
If I understood correctly, the issue arises in two scenarios
When hitting your CF through curl with
curl -L -H "Content-Type: application/json" "https://us-central1-example.cloudfunctions.net/exampleFunction" -d '{"example": true}')
According to the example in github in the docs Signed URL v4, 'Content-Type: application/octet-stream' should be used:
curl -X PUT -H 'Content-Type: application/octet-stream' --upload-file my-file '${url}'
I tried with the following with successfully result:
curl -X PUT -H 'Content-Type: application/octet-stream' -d '{"example": true}' 'https://storage.googleapis.com/...'
If I try with the content-type you shared with failed results.
2.
If I try to manually make a GET request to the URL in Postman, I get an equivalent error:
I tried a simple GET in postman using a Signed URL and it worked just fine
Command used in gsutil to get the signed URL:
gsutil signurl -d 10m key.json gs://BUCKET/aa.png
Then I tried a GET on postman and worked just fine.
I also tried with a Signed URL to upload a File in Postman and worked just fine.
My thoughts are that, according to Common MIME types
application/octet-stream is the default value for all other cases (not textual files).
When you set the content type as application/json you specify a JSON format, but not an object or file. That's why it works with the following, since you are not specifying the header content-type, the default is taken application/octet-stream
curl -L "https://us-central1-example.cloudfunctions.net/exampleFunction" -d "example=true"
Joss Barons answer helped me in the right direction, but it is not true that the Content-Type has to be application/octet-stream. That is only used for creating a signed url that can be used for uploading a file. In my case, when creating the signed url using the Cloud Storage SDK for node, I didn't specify a Content-Type, so when sending a GET request to the signed url, it must not contain a Content-Type header.
I tried to get an access token with the google documentation.
curl -L -X POST 'https://www.googleapis.com/oauth2/v4/token?
client_id=oauth2-client-id& client_secret=oauth2-client-secret&
code=authorization-code& grant_type=authorization_code&
redirect_uri=https://www.google.com'
With this request it didn't worked.
I added -H 'Content-Length: 0' and now I'm ending up with
{
"error": "invalid_grant",
"error_description": "Bad Request"
}
Anybody have an idea?
If fixing the space didn't work, re-do you linking here from the Google guide, steps 1-6. Then get a new authorization code. I had the same issue and re-linking worked for me (with the -H flag).
it seems you have a space in the request:
/v4/token? client_id=oauth2-client-id
when i tried to copy past the commands from the documentation it didn't work.
i had to re-edit the request before i could use it and it worked.
I've got the same issue.
curl -L -X POST "https://www.googleapis.com/oauth2/v4/token?client_id=<client_id>.apps.googleusercontent.com&client_secret=<secret>&code=4/4wGANiKF5......N0Jg&grant_type=authorization_code&redirect_uri=https://www.google.com"
Stumped
Don't you have to use a different redirect_uri? Your own configured redirect uri?
I am trying to add commit to the pull request using GitHub API for issues. But seeing error
curl -H "Authorization: token "Key"" -X POST -d '{"body": "Failed"}' "https://github-site/repos/:repository/issues/PR_NUMBER/comments"
Response for the curl command.
{
"message": "Not Found",
"documentation_url": "https://developer.github.com/enterprise/2.15/v3/issues/comments/#create-a-comment"
}
Ah I found my mistake. I was passing basic authorizing keys. To Post the comment or to create a Label we need OAUTH token generated on github.
https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/
I am using R.
I am new to API's and trying to figure out how to put the post call together to get the required bearer token.
I am using the Experian Sandbox.
Once I have the bearer token i'm good but getting the Post call put together is proving to be very difficult for me.
+below was clipped from the developer portal.
The call to get the Oauth2 token is a POST request with a Content-Type
which needs to be specified as JSON; the response will also be in JSON
format:
Request example:
curl -X POST
-d '{"username": "youremail#email.com", "password": "YOURPASSWORD"}'
-H "Client_id: xxxxxxxxxxxxxxxxxxxxxxxx"
-H "Client_secret: xxxxxxxxx"
-H "Cache-Control: no-cache"
-H "Content-Type: application/json"
"https://sandbox-us-api.experian.com/oauth2/v1/token"
The following solution took care of my issue should anyone else need it for future reference. Thank you to R Community on helping to get me up to date on how this call is performed.
post_req <- httr::POST(
"https://sandbox-us-api.experian.com/oauth2/v1/token",
add_headers(
"Content-Type" = "application/json",
"Cache-Control"="no-cache",
"Client_secret"="xxxxxxxxxx",
"Client_id"="xxxxxxxxxxxxxxxxx"),
body = '{"username": "youremail#email.com", "password": "YOURPASSWORD"}',
verbose()
)
I am working with Nexus OSS 2.11.x and would like to create new users through the REST API. The following command correctly retrieves the list of all users, thus confirming that I am able to call the API:
curl -u $NEXUS_USER:$NEXUS_PASS $NEXUS_LOCAL/service/local/users
Based on the API documentation, I've constructed a JSON user object:
export USER='{"data":{"email":"testing#example.com","firstName":"Test","lastName":"Ing","userId":"testing","status": "active","roles":["repository-any-read"],"password": "test123$"}}'
And then I submit a POST request:
curl -i -H "Accept: application/json" -H "ContentType: application/json; charset=UTF-8" -v -d "$USER" -u $NEXUS_USER:$NEXUS_PASS $NEXUS_LOCAL/service/local/users
The response comes back with HTTP 201 (created) - but GET /service/local/users only gives me back the original user list. The user is not in the list provided from the UI, and the log (available in the UI) does not even indicate that any activity took place. The $NEXUS_USER account is in the "Nexus Administrator" role.
Does anyone have a suggestion for what I'm overlooking here?
I used the above code and had the same problem:
HTTP/1.1 201 Created
and nothing happened.
After some debuging I noticed a simple typo above which was a problem.
Instead:
-H "ContentType: application/json; charset=UTF-8"
should be:
-H "Content-Type: application/json; charset=UTF-8"
(notice the dash in Content-Type) and it started working.
The code above is correct and executes just fine today. The server was rebooted overnight and somehow that fixed things.
To further clarify the environment variables
NEXUS_LOCAL is your nexus server. If you install on localhost with the default settings, then export NEXUS_LOCAL=http://localhost:8081/nexus (Bash) or SET NEXUS_LOCAL=http://localhost:8081/nexus (Windows).
NEXUS_USER and NEXUS_PASS are plaintext for an account with in the Administrator role, or presumably UI Administrator (have no tested the latter).