In a Postman or Newman run, what does the cookie jar hold and how does a script reach it?
answer
- One store, shared by the whole run
- Two surfaces: a list and the jar
- The writable one is opened by a call
- get, getAll, set, unset, clear
- Every operation names a URL first
basics
~20 sA run keeps one cookie jar: the store every request in that run reads from and every response writes into. Scripts open it with pm.cookies.jar(), while pm.cookies lists what the jar holds for the current request's URL.
solid answer
~40 sA run carries exactly one cookie jar. Responses write into it, later requests are filled from it, and that is why a collection can log in on request one and still be authenticated on request five without a script copying anything. Two surfaces reach it: `pm.cookies`, a read-only list of what the jar holds for the current request's URL, and `pm.cookies.jar()`, which returns the jar itself with `get`, `getAll`, `set`, `unset` and `clear`. Each of those takes a URL first, because entries are filed against a URL rather than kept in a flat map of names, and each is asynchronous with a callback. The store lives only as long as the run, unless Newman's `--cookie-jar` reads a serialised one in or `--export-cookie-jar` writes it out.
code
javascript · 9 linesconst jar = pm.cookies.jar();
jar.set('https://api.example.com', 'sid', 'abc123', function (err) {
if (err) { return console.error(err); }
jar.get('https://api.example.com', 'sid', function (err, value) {
console.log(value);
});
});go deeper
Be ready to say that a run has one cookie jar, that responses write into it and later requests read from it, and that this is what keeps a session alive across requests without any scripting.
Explain the two surfaces: pm.cookies is a read-only list for the current request's URL, while pm.cookies.jar() is the writable store whose get, getAll, set, unset and clear each take a URL and a callback.
Show that you reason about the store's lifetime: it dies with the run unless it is serialised in or out, and clearing is per URL, so cleanup between runs is a deliberate act rather than something that happens by default.
Own the question of whether runs should carry state at all. Argue when a shared jar is a feature and when seeding or exporting one couples runs together in ways that make failures hard to reproduce.
## One store for the whole run A **run** is one execution of a collection — started in the app or driven from a terminal — and it carries exactly **one** cookie jar. Every response that arrives during that run offers its cookies to the jar, and every request that goes out afterwards is filled from it. That single shared store is the answer to "what state survives between requests": a collection can sign in on its first request and call a protected endpoint on its fifth without a script copying anything, because the session cookie was written into the jar by the first response and selected back out of it by the fifth request. The jar belongs to the **run**, not to a request, a folder or the saved file. The collection document itself records no cookies at all; the store exists only for as long as the run does, unless the run was explicitly told to read one in or write one out. ## The two surfaces a script sees Scripts reach the store through two different things, and confusing them is the usual first mistake. - `pm.cookies` is a **read-only list** — the cookies the jar holds for the URL of the current request. It answers questions (`pm.cookies.has(name)`, `pm.cookies.get(name)`) and nothing more; assigning to it changes nothing that will be sent. - `pm.cookies.jar()` returns the **jar itself**. This is the writable surface, and it is where `get`, `getAll`, `set`, `unset` and `clear` live. ## The five operations Every one of them names a **URL** first, because the jar is not a flat map of names to values — an entry is filed against the URL it belongs to, so a bare name would be ambiguous. They are also **asynchronous**: each takes a Node-style callback that receives an error or a result, so code that reads a cookie immediately after writing one must nest the calls rather than assume the write has already landed. | Call | Given | Result | |---|---|---| | `get(url, name, cb)` | a URL and one cookie name | the value of that cookie, if the URL selects it | | `getAll(url, cb)` | a URL | every cookie the jar holds that the URL selects | | `set(url, name, value, cb)` | a URL and a cookie to store | writes the cookie into the jar as though it had arrived from that URL | | `unset(url, name, cb)` | a URL and one cookie name | removes that one entry | | `clear(url, cb)` | a URL | removes every entry that URL selects, and nothing else | `set` also accepts a cookie object or a cookie string in place of the separate name and value. ## What the jar is not - It is **not** the definition of cookie behaviour. What an attribute on a cookie *means*, and which hosts a cookie may travel to, is the HTTP cookie subject — the jar only holds entries and matches them against a URL you supply. - It is **not** a view of one response. Reading the jar tells you what the run currently holds, not what a particular response asked for. - It is **not** persistent by itself. When the run ends, the store goes with it. ## Carrying the store past the end of a run The jar has a serialised form, and Newman's command line moves it in both directions: `--cookie-jar` reads a jar file in before the run starts, so the run begins already holding state, and `--export-cookie-jar` writes the run's jar out when the run finishes. Those two flags belong to the CLI; what they carry is exactly this store. ## Where people go wrong 1. Treating `pm.cookies` as writable, then wondering why the next request is unauthenticated. Writes go through `pm.cookies.jar()`. 2. Calling something like `jar.get(name, cb)` with no URL. Every operation takes the URL first. 3. Reading straight after writing, on the assumption the calls are synchronous. 4. Expecting `clear` to empty the whole store; it clears only what the URL you passed selects. 5. Expecting cookies to reappear in the next run without having exported them and read them back in.
- Does clearing the jar for one URL empty the whole store?No. `clear(url, callback)` removes only the entries that URL selects; everything the run collected for other hosts stays exactly where it was. There is no single call that empties the run's store, so a teardown script that clears one host has not isolated the run.
- Two requests in one run hit different hosts. Do they share the jar, and can they see each other's cookies?They share the one jar, but they do not see each other's entries. Everything is filed against the URL it belongs to, so a request is only ever filled from the entries its own URL selects. One store, many independently scoped entries.
- How would you make one run start with the state another run ended with?Serialise it. Newman's command line writes the store out with `--export-cookie-jar` at the end of a run and reads one in with `--cookie-jar` at the start of the next, so the second run begins already holding what the first collected instead of starting empty.
One filing cabinet for the whole run with a drawer per URL, rather than a pocket each request keeps to itself.
saying these in an interview costs you the question
- Thinks each request in a run gets its own cookie store
- Treats pm.cookies as writable instead of using the jar
- Calls a jar operation with a cookie name and no URL
- Reads a cookie right after writing it, ignoring the callback
- Believes the saved collection file records cookies
- Assumes cookies survive into the next run automatically