I am trying to automate via the Postman CLI my collections.
I am able to run a folder (with the Postman Runner) without problems, using Basic Authentication to access many endpoints I am calling.
If I try to run the very same folder with the Postman CLI, all the protected endpoints answer with 403 Forbidden.
It seems that the requests are not using the authentication header.
Is it a known problem? Is there a workaround?
Plus, to troubleshoot better, is there a way to inspect the requests when the collection is run with the Postman CLI? I can see a recap but I cannot see the detailed requests with all the headers, body, ect...
I am running the collection/folder with
postman collection run COLLECTION_UUID -k --verbose -e ENVIRONMENT_UUID -i FOLDER_UUID --env-var "source=X.X.X.X" -d "datafile.json"
Related
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'm trying to get the wsdl from a soap ws but I'm getting a:
ERR_BAD_SSL_CLIENT_AUTH_CERT
error, when I tried to access https://dummyurl.com:8446/data.php?wsdl from my browser.
I've been given 3 files: ca.crt, pablo.crt and pablo.key but I don't know how to use these files in order to authenticate with this service.
I've also tried to use curl to get the wsdl (without any luck)
curl -k https://dummyurl.com:8446/data.php?wsdl -v -key=pablo.key -cacert=ca.crt -cert=pablo.crt
So my question is, how can I use this certificates and key in order to authenticate and and get the wsdl?
You might find documentation useful
https://curl.haxx.se/docs/sslcerts.html
I've setup a private composer repository via gem-fury, but when I'm trying to download one of the packages (using composer-require) I receive the following error:
[Composer\Downloader\TransportException]
The 'https://s3.amazonaws.com:443/gemfury/gems/[SOME_STRING]/[VENDOR][PACKAGE]_[VERSION]_zip?Signature=SIGNATURE&Expires=1481739039&AWSAccessKeyId=[AWS_ACCESS_KEY]' URL could not be accessed: HTTP/1.1 400 Bad Request
P.S.
I know that the authentication worked because composer does receive the package.json file (the latest version is recognized)
Any help would be appretiated
Short answer: You may see this issue if you are using auth.json to store your Gemfury token. At this time, the only way to work around this issue is to embed the token directly into your repository URL in composer.json.
Long answer: The reason it doesn't work is due to a bug in Composer CLI. In that particular use-case, when Composer acts on Gemfury's redirect from your private php.fury.io repo to a secure S3 download, it includes the Authorization header with your Gemfury token. This header conflicts with S3's authentication model, and results in a 400 Bad Request response.
Resending Authorization header on a redirect from one host to another is a fairly significant security concern, and I recommend you reset your Gemfury token and stop using auth.json authentication method until this issue is resolved.
I am using newman tool to run my postman tests on command line. Get and Post method seems to be working fine but Delete method is not deleting the resource but give status 200 OK. Please see the screen shot. On Postman gui tool it works fine.
I copied the curl from chrome network tool while performing DELETE using POSTMAN Chrome client and saw that it does use postman token in the request header. Added Postman Token to header for Delete operation in newman and it works fine.
We have a series of GET requests api, say in the format of
curl -XGET ip-address/api-keywords
These kind of requests generate a JSON responses.
Now the issue here is when I document using Postman,we do not want the ip address to be exposed. How to edit that in postman?.
You can setup environments in Postman that will let you use variables. Then in your collection, different developers or users can setup their own environments and variables. See https://www.getpostman.com/docs/environments