feat: JWT auth token for the Upload API (#1083) * feat: authenticate uploads with an auth token `authToken` takes a plain token or a function returning one, and is sent as `Authorization: Bearer`. It takes precedence over `secureSignature`, `secureExpire` and `secureUploadsSignatureResolver`, which are dropped when it is set. It can be given as an attribute or as a DOM property, though only the property form can carry a function. `@uploadcare/upload-client` calls a token function before every request, so the uploader keeps an `AuthTokenCache` per context rather than passing the configured function straight through, which would hit your token endpoint once per request. `getUploadClientOptions()` is called per file, so that cache is a shared instance: a per-block one would multiply the fetches by the number of files. Assigning a different function swaps it into the cache instead of rebuilding, so the token survives the new closure a React render hands over. Two methods come with it. `getAuthToken()` returns one long-lived function that reads the configured token when called, so a plugin can hold it across config changes; the AI image editor uses it to share this cache. `invalidateAuthToken()` drops the cached token, which assigning a new function deliberately does not, and is the hook for a sign-out. `complexConfigKeys` — "keys that can't be passed as an attribute" — conflated two independent questions, which is why `authToken` could not have been an attribute under it. It is replaced by a descriptor with a field for each, mirroring the `CustomConfigDefinition.attribute` that plugin-registered configs already have, and every key list and config type derives from it. `ConfigPlainType` and `ConfigComplexType` are in the published types, so they remain as deprecated aliases of `AttributeConfigType` and `PropertyOnlyConfigType`, with a tsd case asserting each still equals its replacement. Co-Authored-By: Claude Opus 5 (1M context) * feat: report a failing auth token function as AUTH_TOKEN_ERROR A throw from your own `authToken` function is the one auth failure that never reaches Upload API, and the one an integrator can act on: it means the token endpoint is unreachable or the user's session is gone, not that Uploadcare refused the upload. It used to arrive as `UNKNOWN_ERROR` carrying `Error('Something went wrong')`, with the real failure two `cause` levels down, because `AuthTokenResolverError` extends `Error` rather than `UploadcareError` (`@uploadcare/signed-uploads` has no dependencies) and fell through the classifier. The entry now reports its own error type, with the error itself on `payload.error` so `cause` stays reachable. This adds a member to `OutputFileErrorType`, so an exhaustive switch over that union needs a new branch. Co-Authored-By: Claude Opus 5 (1M context) * chore: require the published 6.22.0 clients `AuthTokenResolverError` and the `/client` subpath landed in 6.22.0, which is what CI was failing on: the lockfile pinned 6.21.0, and the declared range for upload-client (^6.19.0) would have resolved to it. Co-Authored-By: Claude Opus 5 (1M context) * fix: keep upload credentials out of debug output With `debug` on, assigning `secureSignature` printed it to the console, and every upload printed the options it was sent with, signature included. Both are now redacted, as is `authToken`, which would otherwise have joined them. The telemetry payload carries the whole config, so it redacts the same two keys before sending. Nothing was observed leaving that way — a configured `authToken` never appeared in a payload I could capture — but a credential does not belong in it either way. Co-Authored-By: Claude Opus 5 (1M context) * fix: report a failed group creation instead of losing it `_createGroup` was called without being awaited or caught, so anything that went wrong while creating the group — a network failure, an expired credential — became an unhandled rejection. The collection reported success, with no group and no error to explain why. It now surfaces as `GROUP_ERROR` on the collection, carrying the failure on `payload.error`, and clears when the collection changes. This adds a member to `OutputCollectionErrorType`, so an exhaustive switch over that union needs a new branch. Co-Authored-By: Claude Opus 5 (1M context) * test: upload with a real auth token, against the real API Everything about `authToken` was asserted against a stubbed `uploadFile`, which can show that a value is passed along and nothing about whether Upload API accepts it. These upload for real under a project with Signed Uploads enabled: a minted token uploads, no token is refused, a token function is asked once for the whole upload, and an expired, scoped or wrongly signed token each arrive as the code the API sent. A token function that throws becomes `AUTH_TOKEN_ERROR` without a request. Tokens are minted by a browser command, in Node, because the project secret key must never reach the page. They run on `UPLOAD_CLIENT_SECURE_UPLOADS_PUBLIC_KEY` and `_SECRET_KEY` and skip where those are absent, so CI needs both to run them. Also covers the two things true of a credential rather than an option: it is never reflected into the DOM, and it never reaches the debug log. Co-Authored-By: Claude Opus 5 (1M context) * test: pin the GROUP_ERROR payload in the published types The type test covered narrowing a file error but not a collection one, so nothing held `payload.error` to a shape in `dist/index.d.ts`. Co-Authored-By: Claude Opus 5 (1M context) * fix: send the config a change-config event announces The event was sent before the new value was recorded, so its payload described the state before the change. That was invisible while the payload was the manager's own config object — it filled in afterwards, and whoever read it later saw the new value — and became visible as soon as the payload was a snapshot, which redacting credentials made it. Recording first also fixes the payload for anything that serializes when it is sent rather than when it is queued. Co-Authored-By: Claude Opus 5 (1M context) * fix: ignore a group request the collection has moved on from A group request cannot be cancelled once the API has it, and both of its outcomes were mishandled when files were added or removed while it was in flight. On success the guard compared `*collectionState` identity, which cannot see the change it guards against: that state is republished on a flush, not on every collection change, so it is still the same object when the response lands. The group built from the old file set was published as the collection's group, with `uc-group-created` fired for it. On failure there was no guard at all, so a late rejection reported `GROUP_ERROR` against a collection the request was never about — right after the collection update had cleared the previous one. Both are now dropped on arrival by the same generation, bumped wherever the collection changes, and `_createGroup` reports its own outcome instead of handing a rejection back to a caller that does not await it. The `AbortController` went with them: its only `abort()` ran after the request had resolved, so it cancelled nothing. Co-Authored-By: Claude Opus 5 (1M context) * refactor: pin the redacted keys to the types they redact `SECRET_KEYS` was a bare list of strings that happened to match both `ConfigType` and upload-client's options. A rename on either side would have stopped redacting silently, which is the worst way for this particular list to fail. `satisfies` makes it a compile error. Co-Authored-By: Claude Opus 5 (1M context) --------- Co-authored-by: nd0ut Co-authored-by: Claude Opus 5 (1M context)