The API I am making requests to sets a cookie header with a key that the API uses to authenticate me as a logged in user. I want to have multiple tabs that sets this header isolated from each other, basically have multiple logged in accounts at the same time, similar to if I use multiple different browsers (eg. Chrome, Firefox, Opera, etc.) to log in different accounts and make requests.
If I make a request in tab 1, I am making it under [email protected].
If I make a request in tab 1 to an endpoint that only admins are allowed, it should return 401 as it’s not made under [email protected].
If I log out of [email protected], the cookie header for tab 2 and 3 shouldn’t be affected.
Is this possible? I’ve tried with workspace, collections, environments, and multiple windows but whenever I log out, all tabs and windows loses the cookie header.
In Postman, you have requests, folders and collections.
You can generally only set the header on the request.
You can create a pre-request script at the folder level that does some conditional logic.
Or you can set the cookie to be an environment variable, and the environment selected would control the cookie that is sent. Not sure this will affect the tab, only the individual request you have open.
I’m not quite understanding the logic though of wanting all of these tabs open at the same time.
Surely you would have a single collection with requests for each of these account types, including requests with negative tests for testing access rights. Customer, admin and merchant. Each of those requests will have the appropriate cookie header (or read it from a variable).
It will be multiple requests to the same end point, but you should be expecting different results each time. So they should be individual requests.
My backend uses express-session to handle login and sessions. It sets a header called Set-Cookie with a session key that the backend uses to authenticate users. I cannot edit it in Postman as it is automatically set (it says) so I don’t think it can read from a variable.
The logic is so I don’t have to log in and out of accounts to check things. For example. Customer submits a post request to place an order. I want to be able to check on the merchant side that the order came through and do things like fulfill it. As of right now, I have to log out of customer and log in as merchant to accomplish this, very tedious and unnecessary.
If I have a web application (which I will be building later), I can just have customer logged in on Chrome, merchant logged in on Firefox, and admin logged in on Opera and I can just do all of everything without logging in and out.
How are you logging in and out of this application in Postman to generate this Cookie.
If it generates a cookie header, then you can extract this and save it as a variable for future requests.
When you are talking about Chrome, Firefox and Opera. This is three applications, so not sure why you would expect a single application to provide the same functionality. Although you could probably just use Firefox or Chrome with private windows for each tab. Sounds like you are letting the browser deal with the cookie instead of Postman.
I’m logging in by sending an email and password as the body to my server. The server then sets a cookie header in the response and sends it back. This cookie header is then used for all subsequent requests.
Yes, I was hoping to imitate the 3 different browser technique, basically have 3 tabs in Postman or 3 separate windows where the request data are different from each other.
You should be able to extract that cookie header (which I think is just a string) and then set it as a variable.
I would have three variables to storing the cookies. One each for customer, admin and merchant to avoid any confusion.
You then use these variables in the appropriate requests.
You could potentially add a pre-request script on each request and use sendRequest to login and get the Cookie instead of having a full on request in the GUI for this. (Get it working in the GUI first, but this might be a consideration to cut down on the number of requests).