Sessions in Postman

Postman’s first public RFC

This would be Postman’s first public RFC! We are working on solving a whole bunch of key issues around variables, security, and UX with the notion of a session in Postman. Please read through the PDF below:

and feel free to leave your comments in the thread.


Sneak Peek


Comments: Sessions in Postman


6 Likes

First: My understanding is that introducing sessions are done to solve issues related to teamwork and shared workspaces. I have not used that feature, and I am commenting as one of the “other type of users” of Postman here. All of this is meant as constructive feedback.

How will this change affect users that only have 1 Workspace? I am already struggling with Postman getting rather sluggish when I have larger collections that rely on different sets of environment variables + global variables.

If I understand the suggested change, the session will be stored in the memory heap - together with the collection, environment and global variables? How do you plan to ensure that this will not introduce even slower performance in Postman?

Customizable settings: Are you slowly moving over to making Postman more customizable than it is today (in regards to changes possible to do in the Settings menu)? The two-pane view is still in beta, and has been for quite a while.

Collection runners: How will this change work together with sessions? As it stands today, if I run a collection through the collection runner; Postman itself is really sluggish. The reason for this is (seems to be) that the collection I’m running is updating a lot of environment variables.

Postman SDK/Collection version: How will this affect the sdk, introducing data types to the collection will perhaps be a breaking change? Are there any way we can prepare for this change?

2 Likes

I think the sessions abstraction will eventually enable us to improve performance. Right now, variables are written to disk which causes an overhead. Using sessions will help tell Postman which variables are actually being used. We are putting in performance benchmark tests in the Postman app and I hope we can publish them publicly soon.

Customizable settings: Yeah. We are starting with separating our tab management layer. Panes as an abstraction will be next.

Collection runners: Will work the same way but I don’t think performance changes will be apparent right way. Sessions will make the behavior for a collection run and a request run in the builder consistent. For example we will have an option to persist a value from/to a session in the main view now. Earlier this option was only in the collection runner.

SDK/Collection version: Data types won’t be part of the first cut of sessions. We will ensure that Postman is backwards compatible by choosing sane defaults. I think that might be another thing we should post a public RFC on.

2 Likes

Congratulations on your first RFC. I think this is a big step in the right direction to get input from the community.

I have read the document a couple of times and my first impression is that it makes sense with the objection that it is rather technical and open to interpretation in some of the points.

Since Postman is an UI tool, it would make sense to show sort of a prototype on how things could look like. I understand that this idea is in an incipient state, but what I am actually missing are a few use-cases for the sessions (prototypes actually showing how it will solve the problem).

I know that the problems mentioned need to be addressed somehow, but my concern is that variables are anyway complicated in Postman as they are. Introducing a new layer of variables (without reducing the others) can cause even more confusion. For most of the users today it is hard to understand when and how to use each type of variable that exists already (global, environment, collection, local, data).

Looking forward to a more detailed iteration of the idea.

1 Like

Thanks! Great feedback. This is the first public RFC that I posted and learnt a lot in the process. :slight_smile: We will share the prototypes design here soon.

There is lots of work going on in making variables easier. The goal is that sessions should not complicate anything for any use case. This won’t be an additional layer but something that spans across all scopes. The prototype will make it clearer.

Thanks for the feedback guys. Here’s a sneak peak of what we want to build towards.

Would love to hear your thoughts on it. Expect an update with some of these features out soonish!

1 Like

Hi @abhinav ,
Introducing sessions can be useful in making writing better integration tests without needing to make environment/global variables dirty (manipulating or adding n number of environment variables on the fly doesn’t look right details on one of the usecase)

My heavy vote on this :+1:

However, here are some points I think much needed:

  1. Like everyone said above: The requirement of Heap space (Memory leak, StackOverflow issues) for huge test suits having many persisting variables.
  2. Is there a future plan to make collection run in parallel (normal speed-up or enabling performance testing right within postman can be next big thing), sessions have to be more carefully built. Any static object and boom! At present, I’m suspecting, collection level variables are kind of static in nature (if not, please bear with my ignorance, not sure internal architecture wise, just guessing from a user point of view)

It wasn’t clear to me how this implements the Prompt for Values request that we’ve all been wanting for quite a long time. Can you please show how that would work under your proposal?

1 Like

Hello, I still do not see an explanation as to how Users can store the value of their password or other sensitive data in a Team environment, without the rest of the team having visibility to it. A user who commented on this, prompting this RFC, called that “a show-stopper”. I would appreciate a link to how to do this, or clarification as to why this can’t be done. Thank you

@sdooley_he - It’s not recommended to store your sensitive data in the Team environment. Instead you can either:

  1. use a local, session value to work with your Team collection, or
  2. share the Team collection to a Personal workspace (so that the collection exists in two workspaces, one Personal and one Team), and then use a Personal environment (that contains your sensitive info) to work with that collection.

Here’s some documentation about how to do the first option:

https://learning.getpostman.com/docs/postman/environments_and_globals/sessions

And a video:

Thank you Joyce- I was afraid that was the case, after reading the RFC. It pretty much said that. I will review the resources you sent.

Thanks for posting these options as they are helpful when working in Postman. However, when exporting an environment json to be able to run in our CI/CD pipelines, this is still missing the mark for securing sensitive data.

Are there any workarounds for the ability to hide or obfuscate the passwords in an environment json file?

Hi @obasekia,

If you do not wish to export the environment data because it contains sensitive data, there is an alternative of using a Postman API to run collections using Newman from the CI/CD pipeline.
To use the Postman API you would need to have the API key with you which you can generate by following the steps given in the docs: https://learning.getpostman.com/docs/postman/postman_api/intro_api/

For example, if you wish to run the collection for a specific environment using Postman API, you would execute the following newman command :
$ newman run https://api.getpostman.com/collections/myPostmanCollectionUid?apikey=myPostmanApiKey -e https://api.getpostman.com/environments/{{environment_uid}}?apikey=myPostmanApiKey

Relevant doc on the different elements which can be accessed using the Postman API is given here:

Hi Aamir,

Thanks for the response. I wanted to circle back on this. Is there currently a way to access global variables through postman API?

Thanks,

Hi @obasekia,

You cannot directly access global variables through Postman API, but you have the option to save them in a local directory using Newman CLI and reusing those global variables in subsequent collection runs.

For example:

Run collection using Newman and specify an output file to dump Global variables before exiting.
$ newman run https://api.getpostman.com/collections/myPostmanCollectionUid?apikey=myPostmanApiKey --export-globals <path>

Run collection using Newman and specify a URL or Path to a file containing Postman Globals.
$ newman run https://api.getpostman.com/collections/myPostmanCollectionUid?apikey=myPostmanApiKey -g <path>```