@rebasepro/server 0.19.1 → 0.19.2-canary.g08eed46

package/dist/storage/index.d.ts

@@ -21,6 +21,8 @@ export * from "./storage-registry.js";
 export { parseTransformOptions, transformImage, isTransformableImage, TransformCache } from "./image-transform.js";
 export type { ImageTransformOptions } from "./image-transform.js";
 export { TusHandler } from "./tus-handler.js";
+export { createUploadConstraintResolver, assertUploadWithinPropertyLimits, isAcceptedFile, readUploadPropertyContext, UPLOAD_COLLECTION_FIELD, UPLOAD_PROPERTY_FIELD } from "./property-limits.js";
+export type { UploadConstraints, ResolveUploadConstraints } from "./property-limits.js";
 import { BackendStorageConfig, StorageController } from "./types.js";
 /**
  * Create a storage controller from a config object.

package/dist/storage/property-limits.d.ts

@@ -0,0 +1,77 @@
+import type { CollectionConfig } from "@rebasepro/types";
+/**
+ * Server-side enforcement of a storage property's own `maxSize` and
+ * `acceptedFiles`.
+ *
+ * Both were declared per property, published in the generated types, rendered
+ * by the panel's file picker — and enforced by exactly one thing: the browser.
+ * `packages/server/src/storage/routes.ts` knew a single global `maxFileSize`
+ * and nothing about the property a file was destined for, so
+ * `storage: { maxSize: 200_000, acceptedFiles: ["image/*"] }` on an avatar was
+ * a suggestion. `curl -F file=@payload.exe` past the picker put a 40 MB
+ * executable in the avatar bucket, and the config that said otherwise was never
+ * consulted.
+ *
+ * The limits are per *property*, so enforcing them needs to know which property
+ * a request is for. Uploads carry that as context (a form field on `POST
+ * /upload`, `Upload-Metadata` on the resumable path); when it is absent the
+ * global cap is still the ceiling, exactly as before. That is the honest
+ * fallback: an upload that names no property has no property limit to check,
+ * and refusing every context-less upload would break every existing client.
+ */
+/** What a property says a file may be. */
+export interface UploadConstraints {
+    /** Bytes. From `StorageConfig.maxSize`. */
+    maxSize?: number;
+    /** MIME types or extensions. From `StorageConfig.acceptedFiles`. */
+    acceptedFiles?: readonly string[];
+    /** `posts.coverImage` — for the message, so the answer names the rule. */
+    source: string;
+}
+/** Look up the constraints for a collection slug and a property path. */
+export type ResolveUploadConstraints = (collectionSlug: string, propertyPath: string) => UploadConstraints | undefined;
+/**
+ * A resolver over the collections this backend serves.
+ *
+ * Built from the registry rather than from the request, deliberately: the
+ * limits have to be the server's, resolved by slug, or a caller could send
+ * their own generous `maxSize` alongside the file and the check would be theirs
+ * to choose.
+ */
+export declare function createUploadConstraintResolver(collections: readonly CollectionConfig[]): ResolveUploadConstraints;
+/** Is this file one the property accepts? */
+export declare function isAcceptedFile(accepted: readonly string[] | undefined, contentType: string | undefined, fileName: string | undefined): boolean;
+/**
+ * Refuse an upload the destination property does not accept.
+ *
+ * `413` for size and `400` for type, which is the distinction HTTP already
+ * draws: one is "too big for this endpoint", the other is "this is not the
+ * thing being asked for". Both name the property, because "file too large" with
+ * no limit and no field is a message a developer cannot act on.
+ */
+export declare function assertUploadWithinPropertyLimits(constraints: UploadConstraints | undefined, file: {
+    size?: number;
+    type?: string;
+    name?: string;
+}): void;
+/**
+ * The property an upload names, from a request's own fields.
+ *
+ * Two keys, not one: the collection is resolved against the registry, so a
+ * caller cannot invent a limit — the worst they can do is name a property whose
+ * rules are *stricter*, or none at all, which leaves the global cap.
+ */
+export declare function readUploadPropertyContext(source: Record<string, unknown> | undefined): {
+    collection: string;
+    property: string;
+} | undefined;
+/**
+ * The names the context travels under.
+ *
+ * Shared constants rather than three string literals, because the client
+ * writes them and two servers read them (the multipart route and the TUS
+ * metadata parser), and a typo in any one of the three fails silently as "no
+ * context, use the global cap".
+ */
+export declare const UPLOAD_COLLECTION_FIELD = "collection";
+export declare const UPLOAD_PROPERTY_FIELD = "property";

package/dist/storage/routes.d.ts

@@ -10,6 +10,7 @@ import { Hono } from "hono";
 import { StorageController, type StorageAuthorize, type StorageAuthorizeData } from "./types.js";
 import { type StorageRegistry } from "./storage-registry.js";
 import { type StorageSourceDefinition, type AuthAdapter } from "@rebasepro/types";
+import { type ResolveUploadConstraints } from "./property-limits.js";
 import { HonoEnv } from "../api/types.js";
 import { type StorageTrigger } from "./triggers.js";
 import { type RenditionCacheConfig } from "./rendition-cache.js";
@@ -60,6 +61,18 @@ export interface StorageRoutesConfig {
      * controller's check runs at finalize, after every byte is on disk.
      */
     maxFileSize?: number;
+    /**
+     * Per-property upload limits, looked up by collection slug and property
+     * path — `StorageConfig.maxSize` and `StorageConfig.acceptedFiles`.
+     *
+     * The global `maxFileSize` above is a ceiling for the *endpoint*; these are
+     * the rules a particular property declared, and until now the only thing
+     * enforcing them was the browser's file picker. See `property-limits.ts`.
+     *
+     * Omitted, or handed a request with no property context, uploads fall back
+     * to the global cap exactly as before.
+     */
+    uploadConstraints?: ResolveUploadConstraints;
     /**
      * When provided, storage routes delegate auth to this adapter instead
      * of the built-in JWT module. This mirrors how data routes use

package/dist/storage/tus-handler.d.ts

@@ -10,6 +10,7 @@
 import type { Context } from "hono";
 import type { StorageController } from "./types.js";
 import { type StorageRegistry } from "./storage-registry.js";
+import { type ResolveUploadConstraints } from "./property-limits.js";
 /**
  * TUS resumable upload handler.
  *
@@ -54,6 +55,16 @@ export declare class TusHandler {
      * instead of an hour of the customer's bandwidth.
      */
     private maxFileSize?;
+    /**
+     * The destination property's own `maxSize` / `acceptedFiles`.
+     *
+     * Read from `Upload-Metadata` (`collection` and `property`), which is
+     * where a resumable upload carries everything else about its
+     * destination. Checked at `create`, from the declared `Upload-Length`
+     * and the metadata's content type, so a file the property will not
+     * accept is refused before the first chunk rather than after the last.
+     */
+    private uploadConstraints?;
     private uploads;
     private tusDir;
     private cleanupTimer?;
@@ -102,7 +113,17 @@ export declare class TusHandler {
      * and written to disk. Told up front, the refusal costs one request
      * instead of an hour of the customer's bandwidth.
      */
-    maxFileSize?: number | undefined);
+    maxFileSize?: number | undefined, 
+    /**
+     * The destination property's own `maxSize` / `acceptedFiles`.
+     *
+     * Read from `Upload-Metadata` (`collection` and `property`), which is
+     * where a resumable upload carries everything else about its
+     * destination. Checked at `create`, from the declared `Upload-Length`
+     * and the metadata's content type, so a file the property will not
+     * accept is refused before the first chunk rather than after the last.
+     */
+    uploadConstraints?: ResolveUploadConstraints | undefined);
     /** Ensure the temp directory exists. */
     private ensureDir;
     /** Start periodic cleanup of stale uploads. */

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rebasepro/server",
-  "version": "0.19.1",
+  "version": "0.19.2-canary.g08eed46",
   "description": "Database-Agnostic Backend Core for Rebase",
   "keywords": [
     "rebase",
@@ -54,10 +54,10 @@
     "jsonwebtoken": "^9.0.3",
     "ws": "^8.21.1",
     "zod": "^4.4.3",
-    "@rebasepro/client": "0.19.1",
-    "@rebasepro/types": "0.19.1",
-    "@rebasepro/utils": "0.19.1",
-    "@rebasepro/common": "0.19.1"
+    "@rebasepro/client": "0.19.2-canary.g08eed46",
+    "@rebasepro/common": "0.19.2-canary.g08eed46",
+    "@rebasepro/types": "0.19.2-canary.g08eed46",
+    "@rebasepro/utils": "0.19.2-canary.g08eed46"
   },
   "devDependencies": {
     "@jest/globals": "^30.4.1",
@@ -72,7 +72,8 @@
     "jest": "^30.4.2",
     "ts-jest": "29.4.12",
     "typescript": "^6.0.3",
-    "vite": "^8.1.5"
+    "vite": "^8.1.5",
+    "zod-4-5": "npm:zod@4.5.4"
   },
   "peerDependencies": {
     "@aws-sdk/client-s3": "^3.1068.0",