Feature Request: read variables from OS environment

[jensemann19]

It would be great if environment variables from the operating system can be read. This is needed for accessing security credentials (like a password) from Postman/Newman. Storing security credentials in a environment file is not a good idea.

[x6j8x]

That's a great idea. This way you wouldn't have to check in your credentials with the normal collection/environment file, but could handle them on you CI server. +1

[shamasis]

Reading credentials from within Chrome App Sandbox is IMHO not possible. :-/ Correct me if I am wrong. :-)

[x6j8x]

That might be, but there is a use-case for newman on the CLI

[mambax]

@a85 and postman team? How about this feature? I can not find it anywhere in the docs but would need it since I do not want to store sensitive data in the environments... 👍

[openhoat]

I also need this feature :+1:

[wbartensleben]

Would love this feature! 👍

[shyamz-22]

Second that, awesome idea.

[simonjohansson]

I also need this!

[ivanboev-vw]

me too.

[intacctcoleenho]

Second this request!

[msadasivam]

Absolutely necessary to work with secure credentials.

[chudson121]

Up Voting; this is really necessary in a CI environment

[fedemendez]

Please, I want this. I am doing things that are bad for my psyche

[mrollo]

This is needed. And/or, prompting for credentials (or any value) at runtime. I'm not sure that using Postman is really a valid option for me without it. Storing any sensitive data in a cleartext Postman file basically equates to "Don't use Postman" for me.

[gosiapolitowska]

any updates on it? this feature would be awesome :) I want to introduce postman to my team but sharing the sensitive data (passwords, api keys) is out of the question. Even creating individual postman accounts is out of question cause the sensitive data stored in variables would be synced with postman cloud. being able to use os variables would solve all these problems

[chrisLaflamme]

Yep. 👍 I second all the of words that were said up there by everyone else☝️.

[neildavis]

+1

[matthew-auto]

+1

[shisapian]

+1

[QuinnBast]

I found a solution!

After sifting through many google searches I finally found out how to pass OS environment variables in to newman. This allows you to not include plain text usernames and passwords in your git repositories if using travis-CI with postman!

The simple procedure is as follows:

1. Setup environment variables in your Travis-CI repository.

2. Pass variables through .travis.yml

Use the --global-var key=$varName tag. This will set a postman global from the environment variable from your OS. Update your command in .travis.yml to something like this:

newman run collection.json --global-var postman_username=$postman_username --global-var postman_password=$postman_password

3. Access OS variables in postman

You can you can access the variables in a pre-request script or test with:

var password = pm.globals.get("postman_password");
var username = pm.globals.get("postman_username ");

Or you can access them directly inside of a request with: {{postman_password}} and {{postman_username}}

[gosiapolitowska]

@QuinnBast your solution works for newman but not for postman so the original problem is still not solved

[kaustavdm]

Reading environment variables makes sense for Newman. We still don't have it on our roadmap though. Till then, @QuinnBast's workaround in this comment can work for those who want to use system env vars in a CI setup with Newman.

But, we have decided not to implement this for the Postman app itself.

Trying to read system env vars has multiple quirks that will tie Postman to a local environment. Any reference to system variables in collections cannot be clearly resolved across machines. This will affect portability of collections and, in turn, of Postman. This will hurt collaboration, which is one of the main principles of Postman.

Apart from that, I see security concerns in this thread around using your credentials in environments. This is why we have Sessions (see docs) in Postman. Values added in the Current Value column of environments are not synchronized, and they stay on your local system. When you share that environment, others can add their own credentials in the Current Value column.

Also, see this comment by @shamasis on why encrypting these values don't make a lot of difference from Postman's perspective.

[dellagustin]

Hello @kaustavdm how about referring to environment variables in the Current Value of environment / collection variables instead? This would make the setup more flexible to the user of the environment / collection.

[saswatds]

Hi @dellagustin can you provide a bit more insights into your current setup as to how you are using postman? It would be helpful to understand your use-case and how having OS environments in Current Value would solve your problem.

[mhowlesb]

@saswatds I have a similar use case to @dellagustin . I have Postman environments set up for interacting with my team's applications in AWS. We all use the saml2aws script for AWS authentication, which stores auth keys/tokens locally for each profile. Copying each of those keys and tokens for each profile into each Postman environment after each auth refresh would be very tedious. When sharing Postman collections among teammates, we already have the same env variable names, and it would be helpful to tie the Postman Env vars to OS env vars for these sorts of tasks.

Reference to saml2aws: https://github.com/Versent/saml2aws

[alishtory]

mark

[william-wallace-simplisafe]

Using shell environment variables is a long standing programatic solution to the problem of requiring variables to be written where they can be shared. I have been searching for this feature in postman and I have come to this feature request (I see it is implemented in Newman). Is there any movement on this issue? This is desperately needed.

[scottashipp]

@saswatds I have a similar use case to @mhowlesb

1. Postman can already be configured to read conventional environment variables like HTTP_PROXY, HTTPS_PROXY, and NO_PROXY. I already configure these variables in my environment in order to be able to reach a given environment where my service runs.
2. In addition to having the proxy configured, I need a couple of tokens to access my service. These tokens have to be generated within the past X period of time.
3. I can programmatically generate these tokens with shell + curl and store them in environment variables.
4. But I currently have to manually copy/paste them into Postman session variables, every time I use Postman.

I would propose that this painstaking process be replaced instead with the ability for Postman to read the tokens from their environment variables.

[Cody-at-Benjamin]

+1

[mmoutonn]

Need this too!

[Dariusz-Gunia]

Great idea!

[jkleint]

+1 The argument of hurting portability doesn't make sense; postman collections with secrets already don't work out of the box, you have to manually set the secrets. It's no harder and in fact easier to get those from the system environment rather than copy/pasting, especially when they change often.

[StrohmyerTR]

This should be closed.

There are multiple, safe options for both the GUI, and (sheeeeesh - hopefully) quite obviously newman/CLI to accomplish this.

Global variables are stored locally and can be used safely, especially with the new 'secret' drop-down option.

Highly-encouraged, simple tip/trick - write yourself an encryption method and don't store your information raw, ever. Example...

function encrypt(something) { return CryptoJS.AES.encrypt(something, pm.variables.get('yourKeysKey')).toString(); }

and, when it is time for it to be decrypted...

function decrypt(something) { return CryptoJS.AES.decrypt(something, pm.variables.get('yourKeysKey')).toString(CryptoJS.enc.Utf8); }

Another (less elegant) option - if storing the encrypted value in your global variables doesn't suit your needs - you can encrypt and save them in the first index of your data file. This implementation can be handled quite simply in the first request-level pre-request script, by including an if else, which - to be as smart as possible with - should negatively check for that operation before each request is sent if you are going to be executing that code repeatedly.

I really shouldn't have to write this part out, but for completeness' sake.. If you are running newman via CLI, you can access them directly with the simple %some_system_var% format... Or, if you are using PowerShell - $Env:some_system_var.

P.S. - The raw values are going to exist somewhere, always - regardless how careful you are.. if the raw values are to be sent over any network. That's just, how it is. The Postman desktop application is a Chrome app.

[StrohmyerTR]

@saswatds I have a similar use case to @mhowlesb

1. Postman can already be configured to read conventional environment variables like HTTP_PROXY, HTTPS_PROXY, and NO_PROXY. I already configure these variables in my environment in order to be able to reach a given environment where my service runs.
2. In addition to having the proxy configured, I need a couple of tokens to access my service. These tokens have to be generated within the past X period of time.
3. I can programmatically generate these tokens with shell + curl and store them in environment variables.
4. But I currently have to manually copy/paste them into Postman session variables, every time I use Postman.

I would propose that this painstaking process be replaced instead with the ability for Postman to read the tokens from their environment variables.

I am in the same situation as you - see solution(s) above. Good luck!

[scottashipp]

@StrohmyerTR I appreciate the attempt to help, but no this issue should not be closed. It's about giving Postman the capability to read (more) OS environment variables.

The other stuff is not relevant to this particularly issue. The fact that Newman can read environment variables is irrelevant since Newman isn't Postman. Newman vs. Postman was already covered in the conversation above.

The fact that you can store secrets in global variables is similarly irrelevant. Those are nice features, but they just are not what this issue is about. And the ability either to use Newman or to store secrets in global variables just does not address the dozens of use cases already outlined in support of this issue.

Let's take my specific example which you quoted with the comment "...see solution(s) above. Good luck!" I really appreciate that you're trying to help, but the solution you mentioned does not meet my use case. I have environment variables in my OS with the value of an auth token which are populated through an external (separate from Postman) means. They update on a period of time. If it helps to think of it in concrete terms, just assume that the value updates every minute. I have to manually copy/paste these values into a global variable in Postman when I want to use them. That's tedious and seems silly considering that Postman is already reading HTTP_PROXY, NO_PROXY, etc. environment variables.

Along with everyone else here, I'd love to just see Postman have the ability to read OS environment variables.

[StrohmyerTR]

@StrohmyerTR I appreciate the attempt to help, but no this issue should not be closed. It's about giving Postman the capability to read (more) OS environment variables.

The other stuff is not relevant to this particularly issue. The fact that Newman can read environment variables is irrelevant since Newman isn't Postman. Newman vs. Postman was already covered in the conversation above.

The fact that you can store secrets in global variables is similarly irrelevant. Those are nice features, but they just are not what this issue is about. And the ability either to use Newman or to store secrets in global variables just does not address the dozens of use cases already outlined in support of this issue.

Let's take my specific example which you quoted with the comment "...see solution(s) above. Good luck!" I really appreciate that you're trying to help, but the solution you mentioned does not meet my use case. I have environment variables in my OS with the value of an auth token which are populated through an external (separate from Postman) means. They update on a period of time. If it helps to think of it in concrete terms, just assume that the value updates every minute. I have to manually copy/paste these values into a global variable in Postman when I want to use them. That's tedious and seems silly considering that Postman is already reading HTTP_PROXY, NO_PROXY, etc. environment variables.

Along with everyone else here, I'd love to just see Postman have the ability to read OS environment variables.

I would disagree - both with your unsolicited passive-aggressive undertones (i.e. you appreciate the "attempt" to help + everything I offered is "irrelevant"), and your opinion that my post is not a solution at all. It certainly is a solution - pertaining to most people looking for a less hyper-specific solution. There are reasons this is not a feature in Postman - main one being security. That aside, have you tried manually editing the no_proxy.bat and no_proxy_me.bat files? They could (potentially) offer you a solution.

[dbraynard]

One possible workaround to avoid the tediousness of copying and pasting an access token is to create a local http server that only you can reach from your machine to serve up the OS environment variable. Then use the pm.sendRequest to call and transfer it to a variable.

pm.sendRequest("https://localhost:12345", function (err, response) { pm.collectionVariables.set("my_token", response);; });

I had a hard (impossible) time in the first place getting the OAuth access_token mechanism to work in Postman due to what I can only assume is my IDP server not liking the non-localhost redirect URL that Postman uses. So, I'm left with getting an access token every minute or so using my own local custom app.

[mcqj]

@StrohmyerTR Citing security as a reason for not adding support for OS environment variable to Postman doesn't really make any sense. Use of environment variable is a well established practice that thousands of applications use, including many well respected testing solutions. As noted elsewhere, Postman already reads some environment variables to support the use of proxies. If these are not a security risk, then why would others be a security risk. If the environment variables are to be used by users, those users will assess their own risk, and it won't really be more or less than it would be if Postman's own variables are used instead of OS environment variables. I would argue that making it so inconvenient to pull externally set values into postman is likely to lead to reduced security as people leave some secrets in postman environment files out of pure frustration. One option that could help would be to allow multiple postman environments to be included in a test suite. That would at least allow us to separate secrets into one file that is separate from all of the non-secret environment variables that we do want to be able to freely share. As it stands there might be 30 or more values that we cannot share because we have one or two secrets and only one file in which we can store values.

[scottashipp]

I would disagree - both with your unsolicited passive-aggressive undertones (i.e. you appreciate the "attempt" to help + everything I offered is "irrelevant"), and your opinion that my post is not a solution at all. It certainly is a solution - pertaining to most people looking for a less hyper-specific solution. There are reasons this is not a feature in Postman - main one being security. That aside, have you tried manually editing the no_proxy.bat and no_proxy_me.bat files? They could (potentially) offer you a solution.

@StrohmyerTR Sorry you had feelings. (Is that passive-aggressive enough?) The point of my post is let's talk about the substance of the request. It's late 2024, and this feature has been requested since 2015. My own use case and my comment here wasn't the only one (in fact it was one comment which came pretty late in the game). In fact, there's a dozen use cases mentioned (at least). I have all kinds of workarounds for the lack of this feature in Postman. But the existence of other ways doesn't mean that those ways are just as good. It would be better to handle some of these use cases with system environment variables. The argument you're making amounts to, "it's possible to workaround the lack of this feature, so we don't need this feature." This kind of argument among devs is so common it should have a name (maybe it does). What if I scoffed at people for using a stove because I can cook on a fire just fine? What if Steve Jobs had said, "we can run a business with pencil and paper so we shouldn't make the Mac?" What if Henry Ford had said, "we have horses so why would we put so any resources into cars?"

At any rate, I think having Postman be able to read system environment variables would be useful, along with dozens of others here.