I would like to send email with Mailgun via Postman. I write my Private API key in all different way in the Authorization section in Postman. But it always refuse me, got a HTTP 401.
What is wrong?
I tried send via CURL as tutorial suggest, but is fails also:
https://documentation.mailgun.com/en/latest/quickstart-sending.html#send-via-api
kukodajanos#Kukoda-MacBook-Pro-2 ~ % curl -s --user 'api:b3c5...' \
https://api.mailgun.net/v3/mg.tiket.hu/messages \
-F from='janosontech#gmail.com' \
-F to=kukodajanos#icloud.com \
-F subject='Hello' \
-F text='Testing some Mailgun awesomeness!'
Forbidden%
Basic authentication (as in your first screenshot) should work. (Also make sure, you don't have any spaces, newlines or other wrong characters included in your token)
Are you using your primary API key or a sending key specifically for that domain? If the first, try creating a sending key for you domain. If the latter, try recreating the key.
Related
I have some cloud run that make http requests between them, the url is hardcoded in the code, is there a way to resolve the url by the cloud run name or another attribute?
Another possible solution could be using Method: namespaces.services.get.
If the service name is known to you, you can make a GET HTTP request in API calls to https://{endpoint}/apis/serving.knative.dev/v1/{name} where endpoint is one of the supported endpoints and name is the name of the Cloud Run service to retrieve. For Cloud Run (fully managed), replace {namespace_id} with the project ID or number. It takes the form namespaces/{namespace}/services/{service}.
Authorization requires the following IAM permission on the specified resource name : run.services.get
For example :
curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" https://us-central1-run.googleapis.com/apis/serving.knative.dev/v1/namespaces/your-project/services/your-service| grep url
Output :
"url" :"https://cloud-run-xxxxxxxxxx-uc.a.run.app"
There is a gcloud command to do so. You could for instance get the url during your build and save it into an environment variable. The following command will get the complete url:
gcloud run services describe YOUR_CLOUDRUN_NAME --region=INSTANCE_REGION --platform=managed --format=yaml | grep -m 1 url | awk '{print $NF}'
There is no easy way for now (but Cloud Next 21 is coming, maybe great announcement on that; it's a feature requested by many Alpha tester like me).
However, you can implement a bunch of API calls to achieve that. I wrote an article where I use that to get the current Cloud Run service URL. But it could be another service.
It's in Golang. Have a look on it, and let me know if you have issues to translate the calls in your preferred language.
You can:
gcloud run services ${NAME} \
--platform=managed \
--region=${REGION} \
--project=${PROJECT} \
--format="value(status.address.url)")
when I execute
curl --request GET "https://${ES_DOMAIN_ENDPOINT}/my_index_pattern-*/my_type/_mapping" \
--user $AWS_ACCESS_KEY_ID:$AWS_SECRET_ACCESS_KEY \
--aws-sigv4 "aws:amz:ap-southeast-2:es"
where $ES_DOMAIN_ENDPOINT is my AWS Elasticsearch endpoint, I'm getting the following response:
{"message":"The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details."}
I'm confident that my $AWS_ACCESS_KEY_ID:$AWS_SECRET_ACCESS_KEY are correct.
However, when I send the same postman request with the AWS Authentication and the parameters above, the response is coming through. I compared the verbose output of both requests and they have very minor differences, such as timestamps and signature.
I'm wondering, what is wrong with the --aws-sigv4 config?
This issue happens due to the* character in the path. There is a bug report in curl repository to fix this issue https://github.com/curl/curl/issues/7559.
Meanwhile, to mitigate the error you should either remove a * from the path or build curl from the branch https://github.com/outscale-mgo/curl-appimage/tree/http_aws_sigv4_encoding.
I have created a cloudfront distribution and configured with restrict viewer access. So i'm just looking for a way to view the contents within the distribution by assigning the cookies. I've manage to generate the below signed cookies.
{
"CloudFront-Policy":
"CloudFront-Key-Pair-Id":
"CloudFront-Signature":
}
Can we just call the cloudfront destination(https://d1fzlamzw9yswb.cloudfront.net/17-Sep-201%3A05%3A48_1.jpg) in browser and test it whether it works by assigning cookies from browser? What is the best way to test whether the signed cookies are working or not?
I assume that you already created a signed cookie.
You can use curl to send cookies to your CloudFront distribution. This is one way of testing if your setup works correctly. Here is how to pass a cookie with your request:
curl -b 'session=session_id' https://yourdistribution.cloudfront.net
The full header that curl sets for this request looks like this Cookie: session=session_id
UPDATE:
Concretely, CloudFront will expect the following cookie set:
curl -v -X GET --output test-file -b "CloudFront-Expires=4762454400" -b "CloudFront-Signature=k9CxLm0HL5v6bx..." -b "CloudFront-Key-Pair-Id=APKA..." "https://yourdistribution.cloudfrontnet/test-file"
Alternatively, we can also use --cookie flag, like this:
curl -v -X GET --output test-file --cookie "CloudFront-Expires=4762454400;CloudFront-Signature=k9CxLm0HL5v6bx...;CloudFront-Key-Pair-Id=APKA..." "https://yourdistribution.cloudfrontnet/test-file"
Best, Stefan
I'm trying to post a request using curl to my es cluster in AWS using my accessKey and secretKey. I have successfully done this through postman (details here) where you can specify AWS credentials but I would like to make this work with curl. Postman can auto-generate your curl request for you but all I get are errors.
This is the generated curl request along with the response
curl -X GET \
https://search-00000000000001.eu-west-1.es.amazonaws.com/_cat/indices \
-H 'Authorization: AWS4-HMAC-SHA256 Credential=11111111111111111111/20181119/eu-west-1/es/aws4_request, SignedHeaders=cache-control;content-type;host;postman-token;x-amz-date, Signature=11111111116401882398f46011f14fdb9d55e012a4fb912706d67c1111111111' \
-H 'Content-Type: application/x-www-form-urlencoded' \
-H 'Host: search-00000000000001.eu-west-1.es.amazonaws.com' \
-H 'Postman-Token: 00000000-0000-4001-8006-9291e208a000' \
-H 'X-Amz-Date: 20181119T220000Z' \
-H 'cache-control: no-cache'
{"message":"The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details."}%
IDs have been changed to protect the innocent.
I have checked all my keys and region, and like i said this works through postman. Is it possible to access this AWS service using my keys through curl?
This is quite a long rabbit hole. Thanks to Adam for the comment that sent me in the correct direction. The link https://docs.aws.amazon.com/apigateway/api-reference/signing-requests/ really helps you understand what you need to do.
I've since found a script that follows the signing requests method outlined above. It runs in bash and whilst it is not written for use with elasticsearch requests it can be used for them.
https://github.com/riboseinc/aws-authenticating-secgroup-scripts many thanks to https://www.ribose.com for putting this on github.
If your host contains ':443' remove it and try again.
This worked for me.
"My initial problem: If I access it with Postman using the same url, I get the same error, but removing the ‘:443/’, it works fine, so it’s nothing wrong with the key and secret I’m using."
Am trying to use this call to delete comment on an #Instagram ad post
curl -X DELETE -G \
-d "access_token=<ACCESS_TOKEN>"\
-d "ad_id=<AD_ID>"\
"https://graph.facebook.com/<API_VERSION>/<INSTAGRAM_COMMENT_ID>"
however I get the following message
{"error":{"message":"Unsupported delete request. Object with ID does not exist, cannot be loaded due to missing permissions, or does not support this operation.
Please read the Graph API documentation at https:\/\/developers.facebook.com\/docs\/graph-api","type":"GraphMethodException","code":100,"fbtrace_id":"At\/K4NqgQ+9"}}
I am sure that the ad_id is valid and the permission are not missing.
is there a better way to do, any ideas?
Per https://developers.facebook.com/docs/marketing-api/guides/instagramads/post_moderation/v2.6, you need the comment ID as a URL parameter.
curl -X DELETE -G \
-d "access_token=<ACCESS_TOKEN>"\
-d "ad_id=<AD_ID>"\
"https://graph.facebook.com/<API_VERSION>/<INSTAGRAM_COMMENT_ID>"
https://graph.facebook.com// as the Graph API URL just won't work.
This has been confirmed as a bug in marketing api
https://developers.facebook.com/bugs/261618244219382/