You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You can enable debugging and assign custom names to your storage instances for better visibility into token operations:
251
253
252
-
-**`debug`** — When set to `true`, logs detailed information about token operations (creation, retrieval, refresh, etc.).
254
+
-**`debug`** — Accepts a `DebugConfig` object with two options:
255
+
-`logLevel: "info"` — logs meaningful events only: cache misses, token refreshes, authorizations stored/removed, and errors. Routine cache hits are silent, so setups that call `getAuthorization()` on every API request don't flood the logs.
256
+
-`logLevel: "verbose"` — also logs steady-state operations (every storage read and cache hit).
257
+
-`maskToken` — whether to mask access tokens and refresh tokens in the log output (e.g. `eyJh...A9Xz`). Defaults to `true`. Set to `false` to see full tokens, e.g. for inspecting them at [jwt.io](https://jwt.io).
253
258
-**`name`** — A custom identifier for your storage instance, useful when using multiple storages or composite storage configurations. The `name` is an attribute of the storage itself (as shown in the [`memoryStorage` example above](#storage-strategy)).
254
259
260
+
The `createCompositeStorage` helper accepts its own `debug` option, following the same rule: a hit on the first (fastest) storage is steady state, while falling back to a slower storage is a meaningful event worth logging.
261
+
262
+
> [!WARNING]
263
+
> When `maskToken` is set to `false`, full access tokens and refresh tokens are logged to the console. Intended for local development only — in serverless/edge environments, logs may be forwarded to external log aggregation services.
0 commit comments