Allow (process) env vars to be used as Environment Variables

Similar to #647 but instead of passing variables as command line switches, allow process.env vars to be used as (Postman) Environment Variables where none already exists. In other words a Postman Environment Variable (api_url) would have precedence over process.env.API_URL.

This is desirable because there are some environment specific settings (passwords) that I don’t want to store in the .postman_environment.json file (which is checked in to source control). Yes, I can rewrite my .postman_environment.json file before I call newman run but using process.env would be more convenient.

Any other suggestions welcome 😃

[kunagpal]

As discussed earlier, automatic insertion brings with it security concerns. You’d have to use the --global-var option as demonstrated above. The former section in my previous comment was just a working sample.

[englishm-llnw]

I understand the concern for users who may inadvertently allow the exfiltration of sensitive environment variables by malicious collections. However, there is another security concern to consider here, too.

On many UNIX-family operating systems, the full command line (including arguments) for each process is visible to all. This means that if I want to pass an API token to a collection and use newman run collection.json --global-var token=$token, the value of $token (expanded by the shell) will be visible to all users on the host where newman is running. This is not ideal, especially on shared hosts like build servers.

I like @gaieges’s suggestion of filtering by a NEWMAN_ prefix.

Alternatively, a list of specific variable names to import could be provided as a command line argument. For example:

newman run collection.json --shell-env-vars token,url

With considerations like the above, shell environment variables could actually be more secure than command line arguments.