Best solution for generating and storing access token using newman

[dmudge (David Mudge)]

Hi this would have been asked but have been googling for over an hour haven’t found the solution yet!

The Problem we have a bunch of API requests to run which we want to automate in jenkins so we are using Jenkins to run them via newman. All the requests require an access token which expires after an hour

Now we already have this working by writing a pre-request script for the collection which gets an access token (Microsoft azure 2.0) and then sets it as a collection variable. Great!

But I see this means every time it runs a request inside the collection it runs this pre-request script every time so every new request gets a new token

We would like to be able to run the whole collection using the same token and the only way I thought we can do that is by running a separate collection that does a get token and stores it back to the environment variable.

However, while this works when running in Postman, when its running using Jenkins, it is not setting the environment variable for the token, and also its reading the token back from the environment variable as null

I worked out why this is. When you run in postman and do a pm.environment.set(“key”, “value”) it stores it as the “current value” for the variable
But when newman runs it only reads from the “initial value”

Also it seems when the pm.environment.set(“key”, “value”) runs from newman it doesnt set it anyway and I read this is because of security risk because you dont want to send this stuff back through the postman servers

I noticed even though when the request runs from newman and runs the pre-request script and sets the token back to the collection variables: pm.collectionVariables.set(“key”, “value”) it is not actually saving that back to the collection when viewing it in postman anyway so Im guessing thats also because of the security risk and while it sets it back to the collection, its only set locally for the collection run but doesnt it set it permanently so hence its not setting it back through postman servers

so I accepted the fact that we probably cant have a solution where its going to generate a token once only and re-use it for the whole collection? However I noted that when I run a collection locally and it runs the pre-request script it actually does save the access token back to the collection variables! So isn’t that a security risk because that means it’s sending the access token back through postman servers so it can be saved? Because when I refresh the postman the access token is there saved to the collection!

Whatsmore you cannot make a colelction variable to be secret like you can do with the environment variables

Sorry for the long post but I would just like to know whats the best solution when you need an access token generated so that following requests can still use it?

Seems so far the best solution is as Im doing running a pre-request script to generate it and store it to the collection variable but is there any way when you run this inside postman it can run the same as newman does and only sets it locally and doesnt actually save it back to the postman variables and therefore isnt sending it back through the web?

alternatively, the only way I could get it working setting the token at the environment level is to get newman working so when its setting an environment variable it works and saves it back to the initial value but I dont think thats an option as it wont let you do that?

Thanks

[michaelderekjones (Mike Jones)]

Environment variables can be set and changed in Newman.

I’m assuming the method you tried was running the collections with separate command lines in Jenkins.

The variables will not natively persist between the two Newman runs.

However have a look at this post by @w4dd325

250 collection runs per month on Professional?

Hi @heamshrij Say I have request 1 that, in the test tab, picks a nationality randomly from an array… I then ‘set’ the value to an environment variable. [image] And I want to use this value as a param in request 2. I could do that by calling the environment variable in the second collection. [image] However, you would also need to use the ‘–export-environment [path]’ option, as without this the ‘initial value’ would remain static. (current value is not shared with postman servers so it wo…

There is a way that you can run your first collection in Newman and export the environment to be used in the second.

As all of the info is in the same collection, I wouldn’t recommend running the Newman command line twice. Have a think about the structure of your collection.

If your collections are in a folder, you can put the authentication in the first folder. You should then be able to save it to the environment variable which can be used by requests in the other folders.

All of my collections use Environment variables for the more confidential stuff like client secrets.

My authentication keys are generated each time (as its not a problem for my scenarios) and they are also saved to the environment.

If you have a long lived token which you don’t want to keep changing then you might want to consider storing it somewhere else in something like a keyvault and retrieve that instead and send it in the Jenkins pipeline using the appropriate Newman command line attribute.

This is easy using Azure Pipelines and Azure Keyvault. You can create a separate Azure runbook (using PowerShell) to check the token expiry and update when you hit a particular trigger.
I also use the same keyvault to store the client secrets as I don’t want those saved to the Postman cloud or our code repository.
It might be slightly more challenging using Jenkins.

Best practice\best solution is subjective. It’s really down to whatever works for you based on products and skillset. I’m fairly proficient with PowerShell so Azure Runbooks are a good solution for a lot of situations for me. It might not be for you.