@stonyx/orm 0.3.2-alpha.67 → 0.3.2-alpha.69

package/README.md

@@ -350,66 +350,73 @@ Access classes define models and provide custom filtering/authorization logic.
 export default class GlobalAccess {
   models = ['owner', 'animal'];
 
-  access(request, { model, operation }) {
+  access(request, { model, operation, recordId }) {
     // `model` is the model this route was mounted for. It is assigned once, at
     // mount time, and no request can influence it — not a mount prefix, not a
     // query string, not a case-varied path, not an absolute-form request
-    // target. Nothing below parses anything, so variants 1, 2, 4 and 5 are not
-    // constructible against this predicate any more — they are history, not
-    // rules to follow. VARIANT 3 IS THE EXCEPTION AND THE CLAIM IS NARROWER
-    // THAN IT WAS: a matcher stricter than the router can still be stepped
-    // around, because the sub-path rule below is still a string comparison.
-    // Case is handled; percent-encoding is not — abofs/stonyx-orm#228.
+    // target. `recordId` is the record this route was ADDRESSED TO, decoded by
+    // the router and coerced to the key the store lookup uses. Nothing below
+    // parses anything, and since abofs/stonyx-orm#236 nothing below reads
+    // argument one AT ALL. Variants 1, 2, 4 and 5 were already unconstructible;
+    // the sub-path STRING COMPARISON that variant 3 lived in is gone too,
+    // replaced by a comparison against the decoded id. Retiring the "variant 3
+    // survives" wording at the four sites that still carry it — with the
+    // measurement that retires it, rather than by deletion — is
+    // abofs/stonyx-orm#238.
     //
     // `operation` is destructured to name the whole contract at the point of
-    // use. This sample's rules are per-model and per-sub-path rather than
+    // use. This sample's rules are per-model and per-record rather than
     // per-verb, so it does not branch on it; the permission array at the bottom
     // is where the verb is answered.
 
-    // FAIL CLOSED ON ARGUMENT TWO. `model` is absent for any caller that
-    // resolved this predicate without supplying the context, and a request this
-    // function cannot identify DENIES rather than falling through to the CRUD
-    // grant at the bottom. An unidentifiable input must never be the permissive
-    // path. Argument ONE is guarded at its own read, below — this guard does
-    // not cover it.
+    // FAIL CLOSED ON AN UNIDENTIFIABLE MODEL. `model` is absent for any caller
+    // that resolved this predicate without supplying the context, and a request
+    // this function cannot identify DENIES rather than falling through to the
+    // CRUD grant at the bottom. An unidentifiable input must never be the
+    // permissive path.
     if (typeof model !== 'string' || model === '') return false;
 
     if (model === 'owner') {
-      // The context names WHICH MODEL and WHICH VERB — not which route. Six
-      // distinct owner surfaces produce one identical context, so a rule that
-      // depends on the SUB-PATH still needs argument one. `request.path` is
-      // mount-relative and query-free, and it is the one read of the raw
-      // request the README sanctions. false → 403 for the whole request.
+      // FAIL CLOSED ON AN ABSENT `recordId` TOO, AND `undefined` IS THE ONLY
+      // SPELLING OF ABSENT. `auth()` ALWAYS sets the key — `null` on a
+      // collection route, which is addressed to no record — so `undefined`
+      // means the context did not come from `auth()`: it was hand-assembled by
+      // a caller resolving this predicate through the documented
+      // `Orm.instance.getAccess()` path. Letting that through would fall
+      // straight to the per-record filter below, which is a DENY becoming an
+      // ALLOW. This is the same rule the old guard on `request.path` enforced,
+      // moved to the argument this predicate now actually reads.
+      if (recordId === undefined) return false;
+
+      // THE `/archived` DENY, EXPRESSED AGAINST THE DECODED ID. It used to be
+      // `request.path.toLowerCase()` compared against `'/archived'`, and that
+      // was wrong in both directions at once.
+      //
+      // TOO PERMISSIVE: express sets `request.path` from the RAW pathname while
+      // the router DECODES `:id`, so `GET /owners/%61rchived` reached the
+      // comparison as `/%61rchived`, walked past the deny and was dispatched as
+      // the record `archived` — 200 with the record in full, and DELETE
+      // answered 204 with the record DESTROYED, unauthenticated. 255
+      // non-canonical spellings of that 8-character id decode to the same key,
+      // so no deny-list of spellings was ever going to close it.
       //
-      // THIS DENY CANNOT BE EXPRESSED FROM THE CONTEXT ALONE. Migrating it away
-      // does not remove a rule, it turns a deny into an ALLOW, silently.
+      // TOO STRICT: a record id is a VALUE, not a literal route segment, and
+      // express's `case sensitive routing` governs literal segments only. With
+      // a distinct owner seeded at `ARCHIVED`, the `.toLowerCase()` 403'd
+      // `GET /owners/ARCHIVED` — the wrong record — while still admitting
+      // `GET /owners/%41RCHIVED`, the same record encoded.
       //
-      // FAIL CLOSED ON ARGUMENT ONE TOO. The guard above covers the context;
-      // this one covers the request, and since #202 they are two different
-      // objects. A caller that resolves this predicate through the documented
-      // `Orm.instance.getAccess()` path and hand-assembles a request can supply
-      // a perfectly valid context with no usable `path` — and
-      // `String(request.path ?? '')` is then `''`, which matches no sub-path
-      // rule and falls straight through to the per-record filter below. That is
-      // a DENY becoming an ALLOW. An input this function cannot identify DENIES,
-      // whichever ARGUMENT it arrived on — which is also why the `?? ''` this
-      // file's header condemns does not appear below.
-      if (typeof request?.path !== 'string' || request.path === '') return false;
-
-      // Lower-cased because the router matched case-insensitively, so a
-      // case-sensitive rule here would be stricter than the router and could be
-      // stepped around.
+      // SO DO NOT NORMALISE `recordId`. It is already decoded, exactly ONCE,
+      // which is what a route parameter means: `/owners/%2561rchived` is the
+      // legitimate id `%61rchived`, and decoding until stable would deny it. Do
+      // not case-fold it. Do not rebuild it from `request.path` — decoding the
+      // whole path decodes THEN splits while the router splits THEN decodes,
+      // which over-denies the distinct record at `/owners/archived%2fx`.
       //
-      // CASE-FOLDING ALONE IS NOT A SUFFICIENT NORMALISATION, and this line is
-      // not a recipe for one. Express sets `request.path` from the RAW pathname
-      // while the router DECODES `:id`, so `GET /owners/%61rchived` reaches this
-      // comparison as `/%61rchived`, walks past the deny, and is dispatched as
-      // the record `archived` — abofs/stonyx-orm#228. A matcher must normalise
-      // the way the router that dispatched the request does. Record ids are
-      // case-sensitive and must be compared at their real case.
-      const path = request.path.toLowerCase();
-
-      if (path === '/archived' || path.startsWith('/archived/')) return false;
+      // THE DENY IS NOW EXPRESSIBLE FROM THE CONTEXT ALONE, which is exactly
+      // what `recordId` bought — and it still must not be dropped. Deleting it
+      // does not remove a rule loudly, it turns a deny into an ALLOW, silently.
+      if (recordId === 'archived') return false;
 
       // Returning a function plugs it in as a per-record filter, and it is
       // enforced on every surface addressed to one of these records:

package/dist/orm-request.js

@@ -1269,10 +1269,53 @@ export default class OrmRequest extends Request {
         // src/types/orm-types.ts. Nothing is fetched at this point and adding a
         // lookup here would put a store read in the middle of an authorization
         // path. The function return shape below IS the per-record hook.
+        //
+        // -------------------------------------------------------------------------
+        // #236 -- `recordId`, the DECODED route-parameter id, for the same reason.
+        //
+        // WHICH RECORD is the third structural fact the framework already holds and
+        // the consumer was left to re-derive, and re-deriving it failed OPEN. The
+        // documented sample compared `request.path` -- the RAW, undecoded pathname
+        // -- against a literal `/archived`, while the router DECODES `:id`. So
+        // `GET /owners/%61rchived` walked past the deny and was dispatched as the
+        // record `archived`: 200 with the record in full, and DELETE answered 204
+        // with the record destroyed, unauthenticated. Four spellings measured, all
+        // four through; 255 non-canonical spellings of that 8-character id decode
+        // to the same key, so this was never a deny-list of one.
+        //
+        // TWO CONSUMER-SIDE NORMALISATIONS WERE MEASURED WRONG IN OPPOSITE
+        // DIRECTIONS, which is the argument for doing it once, here.
+        // `.toLowerCase()` case-folds a route-parameter VALUE on the axis that
+        // governs literal SEGMENTS: with a distinct owner seeded at `ARCHIVED`,
+        // `GET /owners/ARCHIVED` was a false DENY on the wrong record and
+        // `GET /owners/%41RCHIVED` a false ALLOW on that same one.
+        // `decodeURIComponent(request.path)` decodes THEN splits while the router
+        // splits THEN decodes, so it over-denied `/owners/archived%2fx` -- 403 for
+        // a genuinely distinct record. Failing closed there was luck, not design.
+        //
+        // `getId(request.params)` AND NOT `request.params.id`, for exactly the
+        // reason `operation` is a `methodAccessMap` lookup: it is the SAME single
+        // coercion the store lookup one layer down performs, so the predicate and
+        // the dispatch cannot disagree about which record a request addresses.
+        // The raw string would reintroduce that divergence on hex-shaped ids --
+        // `GET /animals/0x2391` looks up record `9105`.
+        //
+        // NOTHING HERE PARSES THE REQUEST TARGET EITHER. `request.params` is what
+        // the router matched, so a mount prefix, an absolute-form target, a query
+        // string or a case-varied mount cannot move this value -- the same
+        // guarantee `model` carries, by the same means.
+        //
+        // `null` and not `undefined` on a collection route, so the KEY IS ALWAYS
+        // PRESENT -- the rule `operation`'s own docblock already establishes. A
+        // context reaching a predicate WITHOUT the key therefore did not come from
+        // here; it was hand-assembled by a caller resolving the predicate through
+        // `Orm.instance.getAccess()`, and that absence stays deniable only because
+        // `auth()` never produces it.
         // -------------------------------------------------------------------------
         const context = {
             model: this.model,
             operation: methodAccessMap[request.method],
+            recordId: request.params && 'id' in request.params ? getId(request.params) : null,
         };
         let access;
         try {

package/dist/types/orm-types.d.ts

@@ -242,6 +242,72 @@ export interface AccessContext {
      * from one that classified the request and found nothing.
      */
     operation: AccessOperation | undefined;
+    /**
+     * The record this route was addressed to, as the store key -- or `null` on a
+     * collection route, which is addressed to no record (abofs/stonyx-orm#236).
+     *
+     * IT IS ALREADY DECODED, AND THAT IS THE WHOLE POINT. Express decodes route
+     * PARAMETERS while leaving `request.path` raw, so a consumer comparing
+     * `request.path` against a literal compares an undecoded string against a
+     * decoded dispatch. `GET /owners/%61rchived` reached such a comparison as
+     * `/%61rchived`, walked past a `/archived` deny, and was dispatched as the
+     * record `archived` -- 200 with the record in full, and `DELETE` destroyed
+     * it, unauthenticated. 255 non-canonical spellings of an 8-character id
+     * decode to the same key, so a deny-list of spellings is the wrong shape.
+     *
+     * SO DO NOT NORMALISE THIS, AND DO NOT NORMALISE ANYTHING ELSE INSTEAD:
+     *
+     * - Do NOT decode it. Express decodes exactly ONCE, which is what a route
+     *   parameter means. `GET /owners/%2561rchived` is the legitimate id
+     *   `%61rchived`, not a second-order spelling of `archived`; a predicate that
+     *   decoded until stable would deny a record it was never asked about.
+     * - Do NOT case-fold it. A record id is a VALUE, not a literal route segment,
+     *   and express's `case sensitive routing` governs literal segments only.
+     *   With a distinct owner seeded at `ARCHIVED`, `.toLowerCase()` was measured
+     *   wrong in BOTH directions at once: `GET /owners/ARCHIVED` 403 (a false
+     *   deny, on the wrong record) and `GET /owners/%41RCHIVED` 200 (a false
+     *   allow, on that same record).
+     * - Do NOT derive it from `request.path` or the request target. Decoding the
+     *   whole path decodes THEN splits, while the router splits THEN decodes, so
+     *   `/owners/archived%2fx` -- a genuinely distinct record whose id is
+     *   `archived/x` -- was measured over-denied 403.
+     *
+     * IT IS `getId(request.params)`, BYTE FOR BYTE -- the same single coercion
+     * the store lookup uses, exactly as `operation` is the same `methodAccessMap`
+     * lookup the permission-array branch uses. The predicate and the dispatch
+     * therefore cannot disagree about which record a request addresses. Handing
+     * over the raw `request.params.id` instead would reintroduce that divergence
+     * on hex-shaped ids: `GET /animals/0x2391` looks up record `9105`.
+     *
+     * It inherits abofs/stonyx-orm#209 along with that coercion -- on a model
+     * declaring `id = attr('string')`, `'9107'` arrives here as the number
+     * `9107`. That is consistency WITH THE LOOKUP, which is the property this key
+     * exists to buy; it is not a defect to repair here.
+     *
+     * `null`, not `undefined`, on a collection route -- and the KEY IS ALWAYS
+     * PRESENT, the same rule `operation` states above. `auth()` always sets it,
+     * so a context arriving WITHOUT the key did not come from `auth()`: it was
+     * hand-assembled by a caller resolving the predicate through
+     * `Orm.instance.getAccess()`. That absence stays a distinguishable, deniable
+     * signal only because the framework never produces it.
+     *
+     * IT IS THE ONE KEY THE HOOK VOCABULARY DOES *NOT* DISAGREE WITH.
+     * `HookContext.recordId` (`src/hooks.ts`) is an identically-named key on an
+     * identically-shaped context object, which is the exact configuration that
+     * makes `operation` fail-open shaped -- a hook sees `'get'` where `access()`
+     * sees `'read'`. Here they AGREE, and not by coincidence: `_withHooks` sets
+     * `context.recordId = getId(request.params)`, the same single coercion this
+     * key is built from. They differ in ONE way and it is the absence spelling --
+     * `HookContext.recordId` is optional and `undefined` when unset, while this
+     * key is always present and `null` on a collection route. A predicate must
+     * not read `undefined` here as "collection".
+     *
+     * IT NAMES WHICH RECORD, NOT WHICH SURFACE. `GET /owners/gina`,
+     * `GET /owners/gina/pets` and `GET /owners/gina/relationships/pets` all
+     * carry `recordId: 'gina'`; the related-resource gap is abofs/stonyx-orm#196
+     * and is untouched by this key.
+     */
+    recordId: string | number | null;
 }
 /**
  * A consumer `access()` predicate.

package/package.json

@@ -4,7 +4,7 @@
     "stonyx-async",
     "stonyx-module"
   ],
-  "version": "0.3.2-alpha.67",
+  "version": "0.3.2-alpha.69",
   "description": "",
   "main": "dist/index.js",
   "type": "module",

package/src/orm-request.ts

@@ -1389,10 +1389,53 @@ export default class OrmRequest extends Request {
     // src/types/orm-types.ts. Nothing is fetched at this point and adding a
     // lookup here would put a store read in the middle of an authorization
     // path. The function return shape below IS the per-record hook.
+    //
+    // -------------------------------------------------------------------------
+    // #236 -- `recordId`, the DECODED route-parameter id, for the same reason.
+    //
+    // WHICH RECORD is the third structural fact the framework already holds and
+    // the consumer was left to re-derive, and re-deriving it failed OPEN. The
+    // documented sample compared `request.path` -- the RAW, undecoded pathname
+    // -- against a literal `/archived`, while the router DECODES `:id`. So
+    // `GET /owners/%61rchived` walked past the deny and was dispatched as the
+    // record `archived`: 200 with the record in full, and DELETE answered 204
+    // with the record destroyed, unauthenticated. Four spellings measured, all
+    // four through; 255 non-canonical spellings of that 8-character id decode
+    // to the same key, so this was never a deny-list of one.
+    //
+    // TWO CONSUMER-SIDE NORMALISATIONS WERE MEASURED WRONG IN OPPOSITE
+    // DIRECTIONS, which is the argument for doing it once, here.
+    // `.toLowerCase()` case-folds a route-parameter VALUE on the axis that
+    // governs literal SEGMENTS: with a distinct owner seeded at `ARCHIVED`,
+    // `GET /owners/ARCHIVED` was a false DENY on the wrong record and
+    // `GET /owners/%41RCHIVED` a false ALLOW on that same one.
+    // `decodeURIComponent(request.path)` decodes THEN splits while the router
+    // splits THEN decodes, so it over-denied `/owners/archived%2fx` -- 403 for
+    // a genuinely distinct record. Failing closed there was luck, not design.
+    //
+    // `getId(request.params)` AND NOT `request.params.id`, for exactly the
+    // reason `operation` is a `methodAccessMap` lookup: it is the SAME single
+    // coercion the store lookup one layer down performs, so the predicate and
+    // the dispatch cannot disagree about which record a request addresses.
+    // The raw string would reintroduce that divergence on hex-shaped ids --
+    // `GET /animals/0x2391` looks up record `9105`.
+    //
+    // NOTHING HERE PARSES THE REQUEST TARGET EITHER. `request.params` is what
+    // the router matched, so a mount prefix, an absolute-form target, a query
+    // string or a case-varied mount cannot move this value -- the same
+    // guarantee `model` carries, by the same means.
+    //
+    // `null` and not `undefined` on a collection route, so the KEY IS ALWAYS
+    // PRESENT -- the rule `operation`'s own docblock already establishes. A
+    // context reaching a predicate WITHOUT the key therefore did not come from
+    // here; it was hand-assembled by a caller resolving the predicate through
+    // `Orm.instance.getAccess()`, and that absence stays deniable only because
+    // `auth()` never produces it.
     // -------------------------------------------------------------------------
     const context: AccessContext = {
       model: this.model,
       operation: methodAccessMap[request.method],
+      recordId: request.params && 'id' in request.params ? getId(request.params) : null,
     };
 
     let access: AccessMethod;

package/src/types/orm-types.ts

@@ -252,6 +252,73 @@ export interface AccessContext {
    * from one that classified the request and found nothing.
    */
   operation: AccessOperation | undefined;
+
+  /**
+   * The record this route was addressed to, as the store key -- or `null` on a
+   * collection route, which is addressed to no record (abofs/stonyx-orm#236).
+   *
+   * IT IS ALREADY DECODED, AND THAT IS THE WHOLE POINT. Express decodes route
+   * PARAMETERS while leaving `request.path` raw, so a consumer comparing
+   * `request.path` against a literal compares an undecoded string against a
+   * decoded dispatch. `GET /owners/%61rchived` reached such a comparison as
+   * `/%61rchived`, walked past a `/archived` deny, and was dispatched as the
+   * record `archived` -- 200 with the record in full, and `DELETE` destroyed
+   * it, unauthenticated. 255 non-canonical spellings of an 8-character id
+   * decode to the same key, so a deny-list of spellings is the wrong shape.
+   *
+   * SO DO NOT NORMALISE THIS, AND DO NOT NORMALISE ANYTHING ELSE INSTEAD:
+   *
+   * - Do NOT decode it. Express decodes exactly ONCE, which is what a route
+   *   parameter means. `GET /owners/%2561rchived` is the legitimate id
+   *   `%61rchived`, not a second-order spelling of `archived`; a predicate that
+   *   decoded until stable would deny a record it was never asked about.
+   * - Do NOT case-fold it. A record id is a VALUE, not a literal route segment,
+   *   and express's `case sensitive routing` governs literal segments only.
+   *   With a distinct owner seeded at `ARCHIVED`, `.toLowerCase()` was measured
+   *   wrong in BOTH directions at once: `GET /owners/ARCHIVED` 403 (a false
+   *   deny, on the wrong record) and `GET /owners/%41RCHIVED` 200 (a false
+   *   allow, on that same record).
+   * - Do NOT derive it from `request.path` or the request target. Decoding the
+   *   whole path decodes THEN splits, while the router splits THEN decodes, so
+   *   `/owners/archived%2fx` -- a genuinely distinct record whose id is
+   *   `archived/x` -- was measured over-denied 403.
+   *
+   * IT IS `getId(request.params)`, BYTE FOR BYTE -- the same single coercion
+   * the store lookup uses, exactly as `operation` is the same `methodAccessMap`
+   * lookup the permission-array branch uses. The predicate and the dispatch
+   * therefore cannot disagree about which record a request addresses. Handing
+   * over the raw `request.params.id` instead would reintroduce that divergence
+   * on hex-shaped ids: `GET /animals/0x2391` looks up record `9105`.
+   *
+   * It inherits abofs/stonyx-orm#209 along with that coercion -- on a model
+   * declaring `id = attr('string')`, `'9107'` arrives here as the number
+   * `9107`. That is consistency WITH THE LOOKUP, which is the property this key
+   * exists to buy; it is not a defect to repair here.
+   *
+   * `null`, not `undefined`, on a collection route -- and the KEY IS ALWAYS
+   * PRESENT, the same rule `operation` states above. `auth()` always sets it,
+   * so a context arriving WITHOUT the key did not come from `auth()`: it was
+   * hand-assembled by a caller resolving the predicate through
+   * `Orm.instance.getAccess()`. That absence stays a distinguishable, deniable
+   * signal only because the framework never produces it.
+   *
+   * IT IS THE ONE KEY THE HOOK VOCABULARY DOES *NOT* DISAGREE WITH.
+   * `HookContext.recordId` (`src/hooks.ts`) is an identically-named key on an
+   * identically-shaped context object, which is the exact configuration that
+   * makes `operation` fail-open shaped -- a hook sees `'get'` where `access()`
+   * sees `'read'`. Here they AGREE, and not by coincidence: `_withHooks` sets
+   * `context.recordId = getId(request.params)`, the same single coercion this
+   * key is built from. They differ in ONE way and it is the absence spelling --
+   * `HookContext.recordId` is optional and `undefined` when unset, while this
+   * key is always present and `null` on a collection route. A predicate must
+   * not read `undefined` here as "collection".
+   *
+   * IT NAMES WHICH RECORD, NOT WHICH SURFACE. `GET /owners/gina`,
+   * `GET /owners/gina/pets` and `GET /owners/gina/relationships/pets` all
+   * carry `recordId: 'gina'`; the related-resource gap is abofs/stonyx-orm#196
+   * and is untouched by this key.
+   */
+  recordId: string | number | null;
 }
 
 /**