@rebasepro/types 0.13.0 → 0.13.1-canary.g06dbe5b

package/dist/call_context.d.ts

@@ -1,3 +1,4 @@
+import type { DataDriver } from "./controllers/data_driver";
 import type { StorageSource } from "./controllers/storage";
 import type { RebaseClient } from "./controllers/client";
 import type { RebaseSdkData } from "./controllers/data";
@@ -19,7 +20,16 @@ export type RebaseCallContext<USER extends User = User> = {
      * The Rebase client instance.
      * Available in all entity callbacks (beforeSave, afterSave, afterRead,
      * beforeDelete, afterDelete) and in CollectionActionsProps via context.
-     * Use it to call backend functions, access data, storage, etc.
+     * Use it to call backend functions, access storage, send email, etc.
+     *
+     * ⚠️ **Not the same trust level as {@link data}.** Server-side this is the
+     * app singleton, so `client.dataAsAdmin` is **always** the admin-scoped
+     * plane — scoped as `{ uid: "service", roles: ["admin"] }`, so policies are
+     * evaluated against that identity rather than skipped — while {@link data},
+     * one property over, follows whoever triggered the callback. On a user
+     * request, reaching for `context.client.dataAsAdmin` silently escalates a
+     * user-scoped operation to admin. For queries in a callback use
+     * {@link data}; come here for functions, storage and email.
      *
      * @example
      * // In a beforeSave callback:
@@ -35,11 +45,67 @@ export type RebaseCallContext<USER extends User = User> = {
      * Unified data access — `context.data.products.create(...)`.
      * Access any collection as a dynamic property.
      *
-     * Returns flat rows (`{ id, ...columns }`), identical to the frontend SDK
-     * client — so `context.data` in a backend callback and `client.data` in the
-     * frontend behave the same way (`row.title`, never `row.values.title`).
+     * **Inherits the privilege of whatever triggered the callback.** This is not
+     * a fixed trust level, and it is the one thing to know about this accessor:
+     *
+     * - Triggered by a **user request** (REST, realtime, an admin-panel edit):
+     *   user-scoped. The callback runs on the RLS-bound transaction opened for
+     *   that request, so policies apply to reads *and* writes — a callback
+     *   cannot see a row its caller could not.
+     * - Triggered by **`rebase.dataAsAdmin` or a cron** (the same singleton):
+     *   admin-scoped, not unscoped. That driver is scoped as
+     *   `{ uid: "service", roles: ["admin"] }`, so the callback still runs on an
+     *   RLS-bound transaction — policies are evaluated against that identity.
+     * - Triggered by **the base driver** (auth flows, migrations): unscoped, on
+     *   the owner connection, bypassing RLS.
+     *
+     * So a callback that reads a sibling row will find it when an admin task
+     * saves and may find nothing when an end user saves — without an error,
+     * because RLS filters rather than raises. Write callbacks that tolerate
+     * that, or reach for {@link client}`.dataAsAdmin` deliberately when the
+     * callback genuinely has to see what an admin may see. Note what that does
+     * *not* buy you: `policy.serverContext()` (`auth.uid() IS NULL`) is false
+     * for the service identity, so a collection whose only rule is
+     * `serverContext()` stays closed to it.
+     *
+     * Verified end-to-end against Postgres rather than asserted — see
+     * `"scopes context.data to the caller when a callback runs on a user
+     * request"` in `server-postgres`' `rls-enforcement` e2e suite. The
+     * documentation previously claimed the opposite (that callbacks always have
+     * full access), which is the unsafe direction to be wrong in.
+     *
+     * Returns flat rows (`{ id, ...columns }`), identical in *shape* to the
+     * frontend SDK client — so `context.data` in a backend callback and
+     * `client.data` in the frontend are accessed the same way (`row.title`,
+     * never `row.values.title`). Shape only: privilege differs as above.
      */
     data: RebaseSdkData;
+    /**
+     * The driver executing the operation this callback is attached to.
+     *
+     * Present server-side only. Declared here because it is already public in
+     * practice — the backend has always passed it, and the callbacks guide
+     * documented `context.driver.withAuth(user)` in all six locales. The
+     * contract simply did not name it, so `buildCallContext` was cast through
+     * `as unknown as RebaseCallContext` and nothing about the object was
+     * type-checked at all.
+     *
+     * The guide no longer recommends `withAuth` — {@link data} is already
+     * user-scoped on a user request, so the manual re-scoping it described was
+     * answering a problem that did not exist. The field stays declared rather
+     * than removed: it is on the runtime object, dropping it would break anyone
+     * who found it, and a named optional is better than a silent extra.
+     *
+     * `withAuth` is not on {@link DataDriver} because not every engine supports
+     * RLS scoping; it is narrowed here, and left optional so a driver without it
+     * is a compile-time absence rather than a runtime surprise.
+     */
+    driver?: DataDriver & {
+        withAuth?(user: {
+            uid: string;
+            roles?: string[];
+        }): Promise<DataDriver>;
+    };
     /**
      * Used storage implementation
      */

package/dist/controllers/client.d.ts

@@ -296,18 +296,31 @@ export interface RebaseClient<DB = unknown> {
     /** Unified Data access layer */
     data: RebaseSdkData<DB>;
     /**
-     * Admin-scoped, **RLS-bypassing** data accessor.
+     * Admin-scoped data accessor — **not** an RLS bypass.
      *
      * Present on the **server** singleton only (see {@link RebaseServerClient}).
-     * It runs with `{ uid: "service", roles: ["admin"] }` — every read and write
-     * bypasses row-level-security policies. This is the correct tool for trusted
-     * background work (cron jobs, migrations, service-to-service tasks).
+     * It runs as the service identity `{ uid: "service", roles: ["admin"] }`,
+     * and the driver is scoped with `withAuth()` at boot, so every read and
+     * write runs in a transaction that has switched to the restricted
+     * `rebase_user` role with `app.uid = 'service'`: policies are evaluated,
+     * against that identity. This is the correct tool for trusted background
+     * work (cron jobs, migrations, service-to-service tasks).
+     *
+     * Two consequences the name does not suggest:
+     *
+     * - `policy.serverContext()` compiles to `auth.uid() IS NULL` and is
+     *   therefore **false** here. A collection with `disableDefaultPolicies:
+     *   true` whose only rule is `serverContext()` refuses these writes
+     *   (`42501`) and returns zero rows — HTTP 200, empty — for these reads.
+     * - Its reach equals an `admin`-roled application user's reach. It is not a
+     *   private channel. The true bypass is {@link sql}, which runs on the
+     *   owner connection and never goes through `withAuth`.
      *
      * ⚠️ **Do NOT use it to serve user-facing data.** Inside a request handler,
      * user-scoped queries must go through the request-scoped driver
-     * (`c.var.driver`), which carries the caller's identity so RLS applies.
-     * Reaching for `dataAsAdmin` (or its alias {@link data}) in a request handler
-     * silently exposes every row to every caller.
+     * (`c.var.driver`), which carries the caller's identity. Reaching for
+     * `dataAsAdmin` (or its alias {@link data}) in a request handler serves
+     * every caller whatever an admin may see.
      *
      * Undefined in the browser SDK.
      */
@@ -371,7 +384,22 @@ export interface RebaseClient<DB = unknown> {
     setOnUnauthorized?(handler: () => Promise<boolean>): void;
     /** Resolve the current auth token */
     resolveToken?(): Promise<string | null>;
-    /** Make a raw HTTP call to the backend */
+    /**
+     * POST to an arbitrary path on the backend — the escape hatch, not the way
+     * to call a function.
+     *
+     * For a custom function use {@link functions}`.invoke(name, payload)`: it
+     * targets `/functions/<name>`, takes a method and sub-path, and returns the
+     * response body as sent. This posts wherever you point it and **unwraps**:
+     * it returns `res.data` when the response has a `data` property and the
+     * whole envelope otherwise — so an endpoint that legitimately answers
+     * `{ data: null }` hands back the envelope rather than `null`. Two ways to
+     * reach a function with two different response contracts is a trap; this is
+     * the one that exists for paths `invoke` cannot express.
+     *
+     * @internal Prefer `functions.invoke()`. Kept public because a backend can
+     * mount routes outside `/functions`, and nothing else reaches those.
+     */
     call?<T = unknown>(endpoint: string, payload?: unknown): Promise<T>;
     /**
      * Execute raw SQL against the database.
@@ -390,17 +418,20 @@ export interface RebaseClient<DB = unknown> {
  * the admin-scoped {@link dataAsAdmin} accessor, raw {@link sql}, and the
  * {@link email} service are all present (non-optional).
  *
- * **Trust levels.** {@link dataAsAdmin} is the admin-scoped, **RLS-bypassing**
- * driver, and it is the only name for it here — the `data` alias that used to
- * sit beside it is deliberately `Omit`ted from {@link RebaseClient} so the
- * privilege has to be spelled out at every call site. For user-scoped queries
- * inside a request handler use the request-scoped driver (`c.var.driver`)
- * instead — never `dataAsAdmin`.
+ * **Trust levels.** {@link dataAsAdmin} is the admin-scoped driver — scoped as
+ * `{ uid: "service", roles: ["admin"] }`, so policies are still evaluated
+ * against that identity rather than skipped — and it is the only name for it
+ * here: the `data` alias that used to sit beside it is deliberately `Omit`ted
+ * from {@link RebaseClient} so the privilege has to be spelled out at every
+ * call site. {@link sql} is the unconditional bypass: raw SQL on the owner
+ * connection, no policies. For user-scoped queries inside a request handler use
+ * the request-scoped driver (`c.var.driver`) instead — never `dataAsAdmin`.
  */
 export interface RebaseServerClient<DB = unknown> extends Omit<RebaseClient<DB>, "data"> {
     /**
-     * Admin-scoped, **RLS-bypassing** data accessor. Always present server-side.
-     * See {@link RebaseClient.dataAsAdmin} for the full safety contract.
+     * Admin-scoped data accessor (RLS is evaluated as the service identity, not
+     * skipped). Always present server-side. See {@link RebaseClient.dataAsAdmin}
+     * for the full safety contract.
      */
     dataAsAdmin: RebaseSdkData<DB>;
     /**
@@ -419,64 +450,6 @@ export interface RebaseServerClient<DB = unknown> extends Omit<RebaseClient<DB>,
         params?: unknown[];
     }): Promise<Record<string, unknown>[]>;
 }
-/**
- * The browser-side Rebase surface — the shape produced by
- * `createRebaseClient()` in `@rebasepro/client`.
- *
- * Its {@link data} accessor is **user-scoped**: every call carries the signed-in
- * user's token, so backend RLS policies apply. It deliberately omits the
- * server-only members — there is no `sql`, no `email`, and no
- * `dataAsAdmin`, so the RLS-bypassing accessor can never be reached from
- * browser code.
- */
-export interface RebaseBrowserClient<DB = unknown> {
-    /** User-scoped data access layer (carries the signed-in user's token). */
-    data: RebaseSdkData<DB>;
-    /** Unified Authentication layer */
-    auth: AuthClient;
-    /** Unified Storage layer (default storage source, backward-compatible) */
-    storage?: StorageSource;
-    /** Registry of all named storage sources for multi-backend support */
-    storageRegistry?: StorageSourceRegistry;
-    /** Build a server-backed {@link StorageSource} for a named storage source. */
-    createStorageSource?(storageId: string): StorageSource;
-    /** Discover the storage sources declared on the backend. */
-    fetchStorageSources?(): Promise<StorageSourceDefinition[]>;
-    /** Admin API for user management */
-    admin?: AdminAPI;
-    /** Cron job management API */
-    cron?: CronAPI;
-    /** Database backup management API */
-    backups?: BackupsAPI;
-    /** Custom backend functions API */
-    functions?: FunctionsAPI;
-    /** Service API keys management API */
-    apiKeys?: ApiKeysAPI;
-    /** Base HTTP URL of the backend server */
-    baseUrl?: string;
-    /**
-     * The path every API route is mounted under, appended to {@link baseUrl}.
-     *
-     * `"/api"` unless the backend was configured with a different `basePath`
-     * and the client told to match. Exposed because code that builds a URL by
-     * hand — rather than going through the client's own methods — otherwise has
-     * to guess, and guessing `/api` is wrong for exactly the projects that set
-     * the option.
-     */
-    apiPath?: string;
-    /** WebSocket client for realtime subscriptions */
-    ws?: RebaseWebSocket;
-    /** Set the auth token for subsequent requests */
-    setToken?(token: string | null): void;
-    /** Set a function that lazily resolves the auth token */
-    setAuthTokenGetter?(getter: () => Promise<string | null>): void;
-    /** Set handler called when a request returns 401 */
-    setOnUnauthorized?(handler: () => Promise<boolean>): void;
-    /** Resolve the current auth token */
-    resolveToken?(): Promise<string | null>;
-    /** Make a raw HTTP call to the backend */
-    call?<T = unknown>(endpoint: string, payload?: unknown): Promise<T>;
-}
 /**
  * Client-side registry for managing multiple storage sources.
  *