@rebasepro/server-postgres 0.13.0 → 0.13.1-canary.g1822133

package/dist/PostgresBackendDriver.d.ts

@@ -3,7 +3,7 @@ import { BranchService } from "./services/BranchService";
 import { RealtimeService } from "./services/realtimeService";
 import { DatabasePoolManager } from "./databasePoolManager";
 import { DrizzleClient } from "./interfaces";
-import { DatabaseAdmin, DataDriver, DeleteProps, CollectionConfig, FetchCollectionProps, FetchOneProps, ListenCollectionProps, ListenOneProps, RebaseClient, RebaseSdkData, RestFetchService, SaveManyProps, SaveProps, TableMetadata, User } from "@rebasepro/types";
+import { DatabaseAdmin, DataDriver, DeleteProps, CollectionConfig, FetchCollectionProps, FetchOneProps, ListenCollectionProps, ListenOneProps, RebaseClient, RebaseSdkData, RestFetchService, SaveManyProps, SaveProps, UpdateManyProps, DeleteManyProps, TableMetadata, User } from "@rebasepro/types";
 import { PostgresCollectionRegistry } from "./collections/PostgresCollectionRegistry";
 import { HistoryService } from "./history/HistoryService";
 export declare class PostgresBackendDriver implements DataDriver {
@@ -62,6 +62,25 @@ export declare class PostgresBackendDriver implements DataDriver {
      * REST/SDK read leaks unmasked data (see {@link applyAfterReadForRest}).
      */
     get restFetchService(): RestFetchService;
+    /**
+     * Build the context handed to every collection callback.
+     *
+     * Note `data: this.data` — `this` is whichever driver is running the
+     * operation, so the callback's data plane inherits that driver's privilege.
+     * On a user request `AuthenticatedPostgresBackendDriver.withTransaction`
+     * constructs a fresh base driver bound to the RLS-scoped transaction and
+     * runs the operation on it, so `this.data` speaks through that connection
+     * and policies apply. On server-context work `this` is the base driver on
+     * the owner connection, and they do not. Pinned by the
+     * `"scopes context.data to the caller"` case in the `rls-enforcement` e2e
+     * suite, because it is the kind of property that is easy to break from a
+     * distance and impossible to notice.
+     *
+     * Previously returned through `as unknown as RebaseCallContext`, which
+     * disabled checking for the whole object and let `driver` — documented in
+     * the callbacks guide — sit on the runtime context while absent from the
+     * contract. Both are declared now, so this is a plain typed return.
+     */
     private buildCallContext;
     private resolveCollectionCallbacks;
     /**
@@ -102,6 +121,34 @@ export declare class PostgresBackendDriver implements DataDriver {
      * with the last write winning, exactly as separate calls would.
      */
     saveMany<M extends Record<string, unknown>>({ path, rows, collection, upsert }: SaveManyProps<M>): Promise<Record<string, unknown>[]>;
+    /**
+     * Update many rows through the same pipeline as {@link save}, in one
+     * transaction.
+     *
+     * Structurally the mirror of {@link saveMany} — same tx-bound sub-driver,
+     * same deferred notifications, same per-row error labelling — but it calls
+     * `save` with an explicit `id` and `status: "existing"`, which is precisely
+     * what `saveMany` cannot do: that one passes `status: "new"` and keeps the
+     * key inside `values`, so it inserts or upserts and can never target a
+     * particular row.
+     *
+     * All-or-nothing, so an id matching no row aborts the batch. A partial
+     * update is the outcome with no good recovery: the caller cannot tell which
+     * half landed without re-reading everything.
+     */
+    updateMany<M extends Record<string, unknown>>({ path, updates, collection }: UpdateManyProps<M>): Promise<Record<string, unknown>[]>;
+    /**
+     * Delete many rows in one transaction, running the full delete pipeline —
+     * `beforeDelete`, the delete, `afterDelete` — for each.
+     *
+     * Looping the single-row {@link delete} rather than emitting one
+     * `DELETE ... WHERE id = ANY($1)` is the deliberate choice: a single
+     * statement would be faster and would skip every callback, so a collection
+     * relying on `beforeDelete` to veto or on `afterDelete` to clean up
+     * dependents would behave differently depending on how many rows the caller
+     * happened to delete at once. Same pipeline, one transaction.
+     */
+    deleteMany<M extends Record<string, unknown>>({ path, ids, collection }: DeleteManyProps<M>): Promise<void>;
     delete<M extends Record<string, unknown>>({ row, collection }: DeleteProps<M>): Promise<void>;
     deleteAll(path: string): Promise<void>;
     checkUniqueField(path: string, name: string, value: unknown, id?: string, collection?: CollectionConfig): Promise<boolean>;

package/dist/PostgresBootstrapper.d.ts

@@ -89,6 +89,32 @@ export interface PostgresDriverInternals {
  * and this is the part that was wrong.
  */
 export declare function resolveDriftCheckName(col: CollectionConfig, registeredTableNames: string[]): string;
+/**
+ * Is this the local database `rebase init` scaffolds — i.e. the one case where
+ * "you are connected as a superuser" is not news?
+ *
+ * The scaffold's own `docker-compose.yml` sets `POSTGRES_USER: rebase_app`,
+ * which makes that role the cluster superuser, so the superuser advisory below
+ * was the only WARN a brand-new project ever saw and it was about a decision
+ * the tool had made for the developer.
+ *
+ * Of the two available fixes — provision a non-superuser table-owner role in
+ * the scaffold, or recognise the local shape and stay quiet — this is the
+ * second, because the first breaks the scaffold it is meant to improve: a
+ * non-superuser owner cannot `CREATE EXTENSION` (search collections need
+ * `pg_trgm`/`unaccent`, applied by `rebase db push` and again by the boot
+ * schema-ensure), so the very first `pnpm run db:push` on a scaffolded project
+ * with a search block would fail. Trading a working first run for a quieter log
+ * line is the wrong trade.
+ *
+ * The condition is deliberately narrow — a *non-production* process talking to
+ * a database on the loopback interface. A genuine production superuser
+ * connection still warns, and so does a non-production process pointed at a
+ * remote database (the usual "my dev machine writes to staging" mistake, where
+ * the advisory is exactly right). NODE_ENV alone would not do: the scaffold
+ * ships `NODE_ENV=development` and some deployments inherit it.
+ */
+export declare function isScaffoldedLocalDatabase(connectionString: string | undefined): boolean;
 /**
  * Default PostgreSQL bootstrapper.
  *

package/dist/auth/services.d.ts

@@ -287,6 +287,7 @@ export declare class PostgresAuthRepository implements AuthRepository {
         secretEncrypted: string;
     }) | null>;
     verifyMfaFactor(factorId: string): Promise<void>;
+    updateMfaFactorSecret(factorId: string, secretEncrypted: string): Promise<void>;
     deleteMfaFactor(factorId: string, uid: string): Promise<void>;
     createMfaChallenge(factorId: string, ipAddress?: string): Promise<MfaChallengeInfo>;
     getMfaChallengeById(challengeId: string): Promise<MfaChallengeInfo | null>;
@@ -296,6 +297,8 @@ export declare class PostgresAuthRepository implements AuthRepository {
     getUnusedRecoveryCodeCount(uid: string): Promise<number>;
     deleteAllRecoveryCodes(uid: string): Promise<void>;
     hasVerifiedMfaFactors(uid: string): Promise<boolean>;
+    claimMfaFactorCounter(factorId: string, counter: number): Promise<boolean>;
+    recordMfaChallengeAttempt(challengeId: string): Promise<number>;
 }
 /**
  * PostgreSQL implementation of MfaRepository.
@@ -311,10 +314,28 @@ export declare class MfaService implements MfaRepository {
     getMfaFactorById(factorId: string): Promise<(MfaFactor & {
         secretEncrypted: string;
     }) | null>;
+    /**
+     * Spend a TOTP time step, once and only once.
+     *
+     * One statement: the `WHERE` is the check, the `UPDATE` is the act, and
+     * `RETURNING` reports which of two concurrent requests carrying the same
+     * six digits won. Reading the counter and then writing it would let both
+     * pass — the exact replay this closes.
+     */
+    claimMfaFactorCounter(factorId: string, counter: number): Promise<boolean>;
     verifyMfaFactor(factorId: string): Promise<void>;
+    updateMfaFactorSecret(factorId: string, secretEncrypted: string): Promise<void>;
     deleteMfaFactor(factorId: string, uid: string): Promise<void>;
     createMfaChallenge(factorId: string, ipAddress?: string): Promise<MfaChallengeInfo>;
     getMfaChallengeById(challengeId: string): Promise<MfaChallengeInfo | null>;
+    /**
+     * Count one failed guess against a challenge and report the new total.
+     *
+     * Incremented in the database rather than in the route so that guesses
+     * arriving in parallel — the shape any real brute-force takes — cannot
+     * share a single increment.
+     */
+    recordMfaChallengeAttempt(challengeId: string): Promise<number>;
     verifyMfaChallenge(challengeId: string): Promise<void>;
     createRecoveryCodes(uid: string, codeHashes: string[]): Promise<void>;
     useRecoveryCode(uid: string, codeHash: string): Promise<boolean>;