skip to content

Why can a Postman script fail to read a cookie that the run's jar demonstrably holds?

level: seniorimportance: should knowfreq 30%

answer

  1. Using a cookie and reading it are different rights
  2. The decision is made per domain
  3. The jar itself can refuse a script
  4. An error in the callback, not an empty list

basics

~20 s

Because script access is a separate permission from transport use. A jar can carry an allowProgrammaticAccess(domain) check, and when it denies a domain the script's jar call fails with an error while requests keep sending that domain's cookies normally.

solid answer

~40 s

Storing and sending a cookie is one thing; letting script code look inside the store is another. The jar a run is given may implement `allowProgrammaticAccess(domain)`, and the store consults it before any script operation on that domain. A denial surfaces as an **error in the callback**, not as an empty result — `get`, `getAll`, `set`, `unset` and `clear` are all refused alike — while the request path is untouched, so the endpoint still returns 200 and the session is still carried. That combination is what makes the symptom confusing: the run works and only the assertion fails. Branch on the callback's error argument before you touch the value, allow the domain rather than rewriting the request, and never work around it by mirroring cookies into a variable the transport does not read.

code

javascript · 7 lines
javascript
pm.cookies.jar().get('https://api.example.com', 'sid', function (err, value) {
    if (err) {
        return console.error('jar refused:', err.message);
    }

    console.log('value:', value);
});

go deeper

for a junior

Always check the first argument of a jar callback. If it holds an error, the store refused the call, and that is a different situation from a lookup that simply found nothing.

for a middle

Explain that a jar can carry an allowProgrammaticAccess check consulted per domain, that it gates reads and writes alike, and that the request path is completely unaffected by a denial.

for a senior

Diagnose from the symptom shape: a working endpoint plus a failing cookie assertion points at access, not at the request. Fix by allowing the domain, never by keeping a parallel copy of the state.

for a principal

Own the tradeoff. Script access to a session store is a real capability, so decide which domains a shared collection may inspect and how a harness reports a refusal rather than silently degrading to a false negative.

## Two permissions, not one There are two entirely separate things a run does with a cookie: the **transport** stores and sends it, and a **script** reads or edits it. They are governed separately. A jar handed to the run may carry an `allowProgrammaticAccess(domain)` predicate, and the store consults it before it lets a script touch entries for that domain. When it says no, the script call is refused — the callback receives an error rather than a value — while the request path is entirely unaffected. That is why the symptom is so confusing in isolation: the request works, the endpoint returns 200, the session is obviously being carried, and yet a script that asks the jar about the very same domain fails. ## What is and is not blocked | Activity | When programmatic access is denied | |---|---| | A response storing a cookie for that domain | unaffected — the jar stores it | | The next request sending that cookie | unaffected — it is sent | | `jar.get` / `jar.getAll` for that domain from a script | refused; the callback receives an error | | `jar.set` / `jar.unset` / `jar.clear` for that domain | refused the same way | | Everything for a domain that *is* allowed | works normally | ## Reading the symptom correctly The tell is the shape of the failure, and it pays to know all three shapes apart: - **An error in the callback** — the store declined to answer for that domain. This is the access decision. - **No error and an empty result** — the store answered, and the URL you asked about genuinely selects nothing. That is a URL-scoping problem, not a permission one. - **No error and the wrong value** — the entry is real but stale, or a different entry with the same name was selected by the URL you passed. Collapsing these into "cookies don't work in scripts" is what turns a two-minute fix into an afternoon. Always print the error object rather than only the value; a callback that ignores its first argument hides the entire class of failure. ## What to do about it 1. **Check the error first.** Every jar call is `(err, value)`; branch on `err` before you touch `value`. 2. **Allow the domain** rather than rewriting the request. The request was never the problem — nothing about the send path changes when access is granted. 3. **Do not "fix" it with a parallel store.** Copying cookies into a variable so a script can see them creates a second source of truth that the transport ignores, and it will drift from the jar the moment a response updates the real entry. 4. **Fail loudly in shared setups.** If a collection is run by other people or on another machine, the jar it is handed may not be the one you tested with; a script that silently treats a refusal as "no cookie" will report a false negative there. ## Why the split exists at all The transport needs every cookie in order to behave like a client at all — a jar that hid entries from the send path would simply break the run. Script access is a different and more dangerous capability: it lets arbitrary code read a session out of the store and write it anywhere. Separating the two lets the run keep working end to end while still deciding, per domain, whether scripts may see the contents. As a mental model: the run may *use* the store for that domain, and separately may or may not be allowed to *look inside* it.

  • How do you tell a denied domain from a URL that simply selects nothing?
    By the callback's first argument. A denial produces an error; a URL that selects nothing produces no error and an empty result. Code that ignores the error argument collapses the two into one confusing symptom, which is why every jar call should branch on it before reading the value.
  • Does a denial break the requests themselves?
    No. The transport still stores cookies for that domain and still sends them on later requests, so the run behaves normally end to end. Only script access is refused, which is exactly why the failure looks so strange: the endpoint works while the assertion about the cookie fails.

saying these in an interview costs you the question

  • Concludes the request is not sending the cookie
  • Ignores the callback's error argument entirely
  • Treats a refusal as proof the cookie is absent
  • Mirrors cookies into a variable as a workaround
  • Assumes script access follows automatically from transport use