@rebasepro/types 0.10.1-canary.14e53ae → 0.10.1-canary.262a5be

package/dist/types/storage_authorize.d.ts

@@ -24,38 +24,6 @@ export interface StorageAuthorizeContext {
     user: StorageAuthorizeUser | null;
     /** Named backend the request targeted, when one was given. */
     storageId?: string;
-    /**
-     * Trusted, RLS-bypassing data access, so the hook can answer the question it
-     * actually has to answer: *who owns this object?*
-     *
-     * Without it the hook can only do prefix arithmetic on the key, which
-     * expresses no real multi-tenant rule — ownership lives in a row, not in a
-     * string. And it cannot simply import the server to get one: a project
-     * declares this hook from its **config** package, which depends on
-     * `@rebasepro/types` alone and cannot resolve `@rebasepro/server` at
-     * runtime. So the accessor is handed in.
-     *
-     * It bypasses row-level security on purpose. The hook IS the authorization
-     * decision; asking it to make that decision through a reader that has
-     * already been narrowed by the caller's own permissions is circular.
-     */
-    data?: StorageAuthorizeData;
-}
-/**
- * The slice of the data API a storage hook needs: read a collection, in the
- * trusted server context.
- *
- * Deliberately read-only and deliberately tiny. A hook that can write is a hook
- * that can be tricked into writing, and an authorization check has no business
- * mutating anything.
- */
-export interface StorageAuthorizeData {
-    collection(slug: string): {
-        find(query?: Record<string, unknown>): Promise<{
-            data: Record<string, unknown>[];
-        }>;
-        findById(id: string): Promise<Record<string, unknown> | null>;
-    };
 }
 /**
  * Per-object access control for storage, the analogue of an RLS policy on a

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@rebasepro/types",
   "type": "module",
-  "version": "0.10.1-canary.14e53ae",
+  "version": "0.10.1-canary.262a5be",
   "description": "Rebase type definitions — shared interfaces and controller types",
   "funding": {
     "url": "https://github.com/sponsors/rebaseco"

package/src/types/storage_authorize.ts

@@ -27,37 +27,6 @@ export interface StorageAuthorizeContext {
     user: StorageAuthorizeUser | null;
     /** Named backend the request targeted, when one was given. */
     storageId?: string;
-    /**
-     * Trusted, RLS-bypassing data access, so the hook can answer the question it
-     * actually has to answer: *who owns this object?*
-     *
-     * Without it the hook can only do prefix arithmetic on the key, which
-     * expresses no real multi-tenant rule — ownership lives in a row, not in a
-     * string. And it cannot simply import the server to get one: a project
-     * declares this hook from its **config** package, which depends on
-     * `@rebasepro/types` alone and cannot resolve `@rebasepro/server` at
-     * runtime. So the accessor is handed in.
-     *
-     * It bypasses row-level security on purpose. The hook IS the authorization
-     * decision; asking it to make that decision through a reader that has
-     * already been narrowed by the caller's own permissions is circular.
-     */
-    data?: StorageAuthorizeData;
-}
-
-/**
- * The slice of the data API a storage hook needs: read a collection, in the
- * trusted server context.
- *
- * Deliberately read-only and deliberately tiny. A hook that can write is a hook
- * that can be tricked into writing, and an authorization check has no business
- * mutating anything.
- */
-export interface StorageAuthorizeData {
-    collection(slug: string): {
-        find(query?: Record<string, unknown>): Promise<{ data: Record<string, unknown>[] }>;
-        findById(id: string): Promise<Record<string, unknown> | null>;
-    };
 }
 
 /**