skip to content

What happens when a Postman collection's `auth.type` names a scheme no signing handler is registered for?

level: seniorimportance: must knowfreq 52%

answer

  1. The lookup misses and the step gives up
  2. A warning, not an error, and not a stop
  3. One string is rejected as a scheme name
  4. Casing is almost always the culprit
  5. The service reports the failure, not the tool

basics

~20 s

The request goes out unsigned. The SDK stores almost any scheme name, the runtime's handler lookup misses, a console warning naming the type is triggered, and the run continues as if no credential had been configured.

solid answer

~40 s

Nothing fails loudly. The SDK's `RequestAuth.isValidType` returns true for **any string except the literal `'type'`**, so a misspelt or mis-cased name such as `Bearer` or `apiKey` is accepted, stored as the selector, and round-trips through serialisation. At send time the runtime calls `AuthLoader.getHandler(authType)`, gets nothing back, triggers a console `warn` reading `runtime: could not find a handler for auth: <type>`, and calls its callback anyway. The request is dispatched **with no signing applied**. The post-send auth step bails the same way. The visible symptom is therefore a rejection from the service, not an error from the tool — you have to read the run's console warnings to see the real cause. Handler names are registered lower-case, so casing is the usual culprit.

code

json · 8 lines
json
{
  "auth": {
    "type": "Bearer",
    "Bearer": [
      { "key": "token", "value": "abc123" }
    ]
  }
}

go deeper

for a junior

Be ready to say that an unrecognised scheme name does not stop the run: the request is still sent, just without any credential attached.

for a middle

Explain the two steps involved — a permissive check when the document is loaded, and a plain registry lookup at send time that warns and continues on a miss.

for a senior

Walk the symptom chain from failing assertions back to a warning line, and name casing as the usual cause. Say what you would assert on to catch it earlier.

for a principal

Take a position on best-effort authentication as a design choice: what it costs in silent failures, and what guardrails you would mandate across an estate of collections.

## The SDK accepts almost any string The object model is deliberately permissive about scheme names. `RequestAuth.isValidType` is the whole check, and its rule is: the value must be a string, and it must not be the literal `'type'`. The single exclusion exists only to stop a scheme called `type` from colliding with the auth object's own selector key, since the settings for a scheme are stored under a property of the same name. Everything else passes. `Bearer`, `apiKey`, `oauth`, `hmac`, `not-a-scheme` — all of them are accepted by `use()`, all of them get a parameter list created under that name, and all of them serialise back out unchanged. The SDK has no knowledge of the format's `auth.type` enum and no knowledge of any runner's handler registry, so it cannot tell you that the name is wrong. **An `auth.type` that survives a load-and-save round trip is not evidence that anything will sign with it.** ## The runtime looks the name up and gives up quietly When a run reaches the authorization step for an item, it does this: 1. Bail out immediately if the resolved auth is absent or has no `type` — nothing to do. 2. Call `AuthLoader.getHandler(authType)`, a plain key read on the registry of handlers loaded from the `authorizer` directory. 3. If that returns nothing, trigger a console event at level `warn` with the message `runtime: could not find a handler for auth: <type>`, then call the step's callback with no error. 4. Continue to send the request. Step 3 is the whole failure handling. There is no exception, no non-zero result from the auth step, no annotation on the item. The request proceeds through the rest of the pre-send pipeline and is dispatched **unsigned** — no header added, no query parameter added, nothing. The post-send auth step performs the same lookup and bails identically, so nothing catches it on the way back either. | Entry point | Unknown `auth.type` behaviour | |---|---| | The run's pre-send auth step | console `warn`, then send the request unsigned | | The run's post-send auth step | console `warn`, then finish the item normally | | The runtime's `authorizeRequest` helper, used by its dry-run requester | returns an `Error` naming the unfound handler | That last row is worth knowing: the same runtime does have a path that reports an error, but it is not the path a normal run takes. ## What you actually observe Because the tool does not object, the failure surfaces as the **service's** rejection rather than the runner's. A candidate who has lived through this describes the symptom chain: - Tests that assert on an authenticated response start failing, all of them, all at once. - The request as sent carries no `Authorization` header and no auth query parameter, which is visible in the request dump. - A `warn`-level console line naming the offending type is present in the output, but it is one line among many and easy to scroll past. - Nothing in the auth configuration looks empty — the scheme array is fully populated, which is what makes it convincing. ## Diagnosing it - **Read the console warnings first.** The message names the exact string it failed to resolve, which usually identifies the typo immediately. - **Check the casing.** Handler names are registered lower-case. `Bearer`, `Basic` and `OAuth2` all miss, and the mismatch is invisible in a UI that renders a scheme's display name in title case. - **Check the selector against the array key.** A `type` of `bearer` with the settings stored under a `Bearer` array is a different bug with the same silent shape: the handler resolves but finds no parameters. - **Run the document through a schema validation.** The format's enum will catch every name outside the declared eleven — this is exactly the case where validation earns its keep, even though it also flags the two undeclared-but-implemented handlers. - **Assert on the outgoing request, not only on the response.** A test that checks a credential was actually attached turns a silent unsigned send into an explicit failure. The underlying design point is that authentication in this pipeline is **best-effort**: a handler that cannot validate its parameters, a handler that throws while signing, and a type with no handler at all are all treated the same way — warn the user, then send whatever you have.

  • Which scheme name does `RequestAuth.isValidType` actually reject, and why that one?
    Only the literal string `type`. A scheme's settings are stored under a property named for the scheme, so a scheme called `type` would collide with the auth object's own selector key. Every other string passes, including names the format's enum never declares and names no handler is registered under.
  • Is there any code path in the runtime that treats an unknown auth type as a hard error?
    Yes. The `authorizeRequest` helper, used by the runtime's dry-run requester, calls back with an `Error` naming the type it could not find a handler for. That is a different entry point from the run's pre-send auth step, which only warns. A normal collection run takes the warning path.
  • How would you stop a silent unsigned send from reaching production again?
    Assert on the outgoing request rather than only on the reply, so a missing credential fails a test rather than surfacing as a service rejection. Add a schema validation step over committed collections to catch scheme names outside the declared enum, and treat auth-related console warnings in a run as build-visible output.

saying these in an interview costs you the question

  • Says an unrecognised auth type aborts the run with an error
  • Assumes the SDK validates the scheme name against the format's enum
  • Thinks the runtime falls back to a close-matching handler name
  • Claims the item is marked failed or skipped by the auth step
  • Believes a populated scheme array proves the request was signed