I could completely execute my Day 13 challenge using postman Web. All test cases passed. But I am unable to run the same using newman.
The command I used to invoke the collection is as follows newman run https://api.getpostman.com/collections/mycollection-uid?apikey=myapikey --environment https://api.getpostman.com/environments/mycollection-uid?apikey=myapikey.
Out of the two folders under Day 13 collection, ‘Newman’ folder completed successfully but ‘submit’ api is throwing [401 Unauthorized, 575B, 262ms].
I could make it work if I set initial value of my x-api-key instead of only current value. As per the document it is not safe to add my API key value to initial value.
vdespa, As I understand it you are absolutely not supposed to persist your API key like that (just like te OP says.)
Since the 30 Days Challenge collections are public, persisting something (i.e. putting it as INITIAL VALUE makes it publicly available.) And the API key is a private credential. No?
You can use flags to specify a JSON file to use for variables in when running your newman command. It’s -e <path> for enviroment variables and -g <path> for globals. I found this out by looking at the help with newman run -h.
So if you use -g the command would be newman run "Day 13- Newman.postman_collection.json" -g <path-to-file>
What to put in the file? You can export the variables from Postman to a file. But if the key is not persisted the variable value will just be an empty string. But you can figure out the structure from that file. I found the simplest file to be
If you are not sharing your workspace or environment, you are no exposing your API key.
But as @devies-daniel correctly said, if your workspace is public, this is not a good approach. In my original reply, I was trying to explain why it does not work as it is.
A more secure option would be to inject these values directly to newman, using --env-var
I managed to validate my solution in Newman successfully, using the command below:
newman run "[path to Postman JSON collection]" --folder "Submit your solution" --env-var collection_uid=[my_collection_uid] --env-var postman_api_key=[my_api_key]
But I was wondering, is this considered a secure way, passing the value of my API key in the command parameters? Or is there something better?
I saw @devies-daniel 's reply above, where we can export the api key with the rest of the variables (if we persist them as current and not initial, I guess). Is this a better approach?
I am not saying they are not secure, just wondering so that I can stop studying this challenge (day 13) and go to the next!
@kostassav you may have misread me, or tagged me when you meant someone else. I was arguing directly against saving keys as Postman variables. Especially if they are persisted.
The reason for this is that if the workspace or environment should be public, those keys would be public too.
As @vdespa said, if your workspace or environment is not public, then those keys will be safe and it should theoretically not matter. BUT! In practice I would say that this falls under the same best-practice as committing keys to your git repo. That is, DON’T DO IT! Even if the repo is private.
As long as you are also masking your credentials in the logs. Most CI/CD systems will do this for you when you define environment variables with credentials.