@o3co/auth.policy-verifier.cedar-wasm 0.14.0 → 0.16.0

package/README.md

@@ -1,6 +1,6 @@
 # @o3co/auth.policy-verifier.cedar-wasm
 
-Last updated: 2026-09-23
+Last updated: 2026-09-26
 
 The in-process Cedar engine for
 [`@o3co/auth.policy-verifier.cedar`](../cedar/README.md): the official
@@ -37,8 +37,13 @@ deployment imports it.
 
 **Owns** ([`src/wasmEngine.mts`](src/wasmEngine.mts)):
 
-- Parse-checking each policy file at boot, so a syntax error names its file,
-  and compiling the set once into wasm memory under an id minted per load.
+- Parsing each policy file at boot, so a syntax error names its file;
+  naming each policy for its file (cedar's `namePolicies`, #199), so Cedar's
+  `diagnostics.reason` — and a decision's `determiningPolicies` — say
+  `30-forbid-contractors` or `20-rules#2` rather than a positional `policy7`;
+  refusing a set where two policies would share an id, a policy in a file
+  named only `.cedar`, or a template, which nothing here would link; and
+  compiling the set once into wasm memory under an id minted per load.
 - Evaluating each request against that compiled set, synchronously, and
   rendering the bindings' answer as a `CedarDecision`.
 - Naming the revision of the source it compiled on every answer.
@@ -77,3 +82,38 @@ a dependency change, not a config change.
 `@cedar-policy/cedar-wasm` is pinned exactly: Cedar minor releases can carry
 policy-language changes, so upgrades should be deliberate and re-validated,
 not fall out of a range resolution.
+
+The re-validation is a suite (#198):
+[`cedar-cli-equivalence.test.mts`](../../tests/integration/src/cedar-cli-equivalence.test.mts)
+holds this engine, behind `CedarPolicyRuleCollector`, to the official `cedar`
+CLI at the pinned version.
+- **What it compares.** For every request of a fixture corpus, the CLI is
+  asked exactly the request the collector built, and both evaluators must agree
+  on the decision, on the policies that determined it, and on which policies
+  raised errors. The request itself must be the one the case records, so a
+  change to how requests are built shows as a diff. The corpus covers the cases
+  the entity synthesis decides:
+  - group membership, direct and transitive;
+  - entity references;
+  - a missing attribute;
+  - `forbid` over `permit`;
+  - the context allowlist;
+  - `resource.idWhenAbsent`.
+- **Policy names.** Each fixture policy carries `@id` with the id its file
+  gives it. The CLI names a policy by `@id`, and otherwise by its position, so
+  this is how it answers in this engine's names.
+- **How the versions stay together.** CI installs `cedar-policy-cli` at the
+  version read from this package's `package.json`, so bumping the pin moves the
+  CLI with it. A CLI at any other version fails the suite's version check.
+- **Running it locally.** Install the CLI at the pinned version, then build
+  and run the suite. Without a CLI this engine's half is skipped, with a
+  notice. The suite's other half measures the `http` engine against a real
+  cedar-agent (#284, see the cedar package's README).
+
+  ```sh
+  cargo install cedar-policy-cli --locked --version \
+    "$(node -p 'require("./packages/cedar-wasm/package.json").dependencies["@cedar-policy/cedar-wasm"]')"
+  pnpm run build
+  CEDAR_CLI="$(command -v cedar)" pnpm --filter @o3co/auth.policy-verifier.integration-tests \
+    exec vitest run cedar-cli-
+  ```

package/dist/wasmEngine.d.mts

@@ -10,24 +10,28 @@ export interface CedarWasmEngine extends CedarEngine {
  * The in-process Cedar engine: the official `@cedar-policy/cedar-wasm`
  * bindings behind the `CedarEngine` port.
  *
- * `load` parse-checks every file individually — so a syntax error names the
- * file that contains it — then compiles the concatenated set once, at boot,
- * into wasm memory under a per-load id. `isAuthorized` references that id per
- * request and re-parses nothing; the call is synchronous, deterministic, and a
- * few tens of microseconds, so the policy set answers as a plain `Rule`.
+ * `load` parses every file on its own — so a syntax error names the file that
+ * contains it — splits it into its policies, and names each for its file
+ * (`namePolicies`): the file's name for a file that holds one, numbered `#1`,
+ * `#2`… for one that holds several. Those are the ids Cedar answers with in
+ * `diagnostics.reason` and names in `errors`, and the ids the http engine
+ * gives cedar-agent, so a corpus laid out one policy per file reads the same
+ * under both. Refused at load: two policies that would share an id (`a.cedar`
+ * holding two, beside `a#1.cedar`), a policy in a file named only `.cedar`,
+ * and a template. The set is then compiled once, at boot, into wasm memory
+ * under a per-load id. `isAuthorized` references that id per request and
+ * re-parses nothing; the call is synchronous, deterministic, and a few tens of
+ * microseconds, so the policy set answers as a plain `Rule`.
  *
- * What this engine costs is paid at import: the wasm module (about 12 MB on
- * disk) is instantiated when the bindings load. That is why it lives in its
- * own package — a deployment that evaluates out of process never carries it.
+ * The wasm module (about 12 MB on disk) is instantiated when the bindings
+ * load, which is why this engine lives in its own package: a deployment that
+ * evaluates out of process never carries it.
  *
- * It vouches for the revision it evaluated (`confirmsRevision`, #244), and can:
- * the set is compiled here, from the source `load` was handed, under an id
- * minted here and known to nothing else. An answer through that id cannot have
- * come from any other policies, so every answer names the revision of that
- * source — read once, at `load`, beside the compile. `PolicySource` is a plain
- * object the caller still holds; reading `source.revision` when answering would
- * be reading "the current revision", which is a claim about the object and not
- * about the policies that were compiled.
+ * It vouches for the revision it evaluated (`confirmsRevision`): the set is
+ * compiled here, under an id known to nothing else, so an answer through that
+ * id comes from the source `load` was handed and names that source's revision,
+ * read once at `load`. Reading `source.revision` when answering would describe
+ * the caller's object as it is now, not the policies that were compiled.
  */
 export declare const cedarWasmEngine: CedarWasmEngine;
 //# sourceMappingURL=wasmEngine.d.mts.map

package/dist/wasmEngine.d.mts.map

@@ -1 +1 @@
-{"version":3,"file":"wasmEngine.d.mts","sourceRoot":"","sources":["../src/wasmEngine.mts"],"names":[],"mappings":"AAeA,OAAO,EAEN,KAAK,WAAW,EAGhB,KAAK,YAAY,EACjB,KAAK,kBAAkB,EACvB,MAAM,kCAAkC,CAAC;AAE1C,kFAAkF;AAClF,eAAO,MAAM,sBAAsB,EAAG,MAAe,CAAC;AAEtD,oFAAoF;AACpF,MAAM,WAAW,eAAgB,SAAQ,WAAW;IACnD,QAAQ,CAAC,IAAI,EAAE,OAAO,sBAAsB,CAAC;IAC7C,IAAI,CAAC,MAAM,EAAE,YAAY,GAAG,kBAAkB,CAAC;CAC/C;AAKD;;;;;;;;;;;;;;;;;;;;;;GAsBG;AACH,eAAO,MAAM,eAAe,EAAE,eA0C7B,CAAC"}
+{"version":3,"file":"wasmEngine.d.mts","sourceRoot":"","sources":["../src/wasmEngine.mts"],"names":[],"mappings":"AAeA,OAAO,EAEN,KAAK,WAAW,EAKhB,KAAK,YAAY,EACjB,KAAK,kBAAkB,EACvB,MAAM,kCAAkC,CAAC;AAE1C,kFAAkF;AAClF,eAAO,MAAM,sBAAsB,EAAG,MAAe,CAAC;AAEtD,oFAAoF;AACpF,MAAM,WAAW,eAAgB,SAAQ,WAAW;IACnD,QAAQ,CAAC,IAAI,EAAE,OAAO,sBAAsB,CAAC;IAC7C,IAAI,CAAC,MAAM,EAAE,YAAY,GAAG,kBAAkB,CAAC;CAC/C;AAKD;;;;;;;;;;;;;;;;;;;;;;;;;;GA0BG;AACH,eAAO,MAAM,eAAe,EAAE,eAuC7B,CAAC"}

package/dist/wasmEngine.mjs

@@ -5,8 +5,8 @@
  * `@cedar-policy/cedar-wasm` bindings, compiling it once at load and answering
  * synchronously. The package index registers it.
  */
-import { checkParsePolicySet, preparsePolicySet, statefulIsAuthorized, } from "@cedar-policy/cedar-wasm/nodejs";
-import { CedarEngineError, } from "@o3co/auth.policy-verifier.cedar";
+import { policySetTextToParts, preparsePolicySet, statefulIsAuthorized, } from "@cedar-policy/cedar-wasm/nodejs";
+import { CedarEngineError, namePolicies, } from "@o3co/auth.policy-verifier.cedar";
 /** The name this engine registers under, and the config value that selects it. */
 export const CEDAR_WASM_ENGINE_NAME = "wasm";
 /** Distinguishes concurrently-loaded policy sets inside the one wasm instance. */
@@ -15,40 +15,41 @@ let policySetCounter = 0;
  * The in-process Cedar engine: the official `@cedar-policy/cedar-wasm`
  * bindings behind the `CedarEngine` port.
  *
- * `load` parse-checks every file individually — so a syntax error names the
- * file that contains it — then compiles the concatenated set once, at boot,
- * into wasm memory under a per-load id. `isAuthorized` references that id per
- * request and re-parses nothing; the call is synchronous, deterministic, and a
- * few tens of microseconds, so the policy set answers as a plain `Rule`.
+ * `load` parses every file on its own — so a syntax error names the file that
+ * contains it — splits it into its policies, and names each for its file
+ * (`namePolicies`): the file's name for a file that holds one, numbered `#1`,
+ * `#2`… for one that holds several. Those are the ids Cedar answers with in
+ * `diagnostics.reason` and names in `errors`, and the ids the http engine
+ * gives cedar-agent, so a corpus laid out one policy per file reads the same
+ * under both. Refused at load: two policies that would share an id (`a.cedar`
+ * holding two, beside `a#1.cedar`), a policy in a file named only `.cedar`,
+ * and a template. The set is then compiled once, at boot, into wasm memory
+ * under a per-load id. `isAuthorized` references that id per request and
+ * re-parses nothing; the call is synchronous, deterministic, and a few tens of
+ * microseconds, so the policy set answers as a plain `Rule`.
  *
- * What this engine costs is paid at import: the wasm module (about 12 MB on
- * disk) is instantiated when the bindings load. That is why it lives in its
- * own package — a deployment that evaluates out of process never carries it.
+ * The wasm module (about 12 MB on disk) is instantiated when the bindings
+ * load, which is why this engine lives in its own package: a deployment that
+ * evaluates out of process never carries it.
  *
- * It vouches for the revision it evaluated (`confirmsRevision`, #244), and can:
- * the set is compiled here, from the source `load` was handed, under an id
- * minted here and known to nothing else. An answer through that id cannot have
- * come from any other policies, so every answer names the revision of that
- * source — read once, at `load`, beside the compile. `PolicySource` is a plain
- * object the caller still holds; reading `source.revision` when answering would
- * be reading "the current revision", which is a claim about the object and not
- * about the policies that were compiled.
+ * It vouches for the revision it evaluated (`confirmsRevision`): the set is
+ * compiled here, under an id known to nothing else, so an answer through that
+ * id comes from the source `load` was handed and names that source's revision,
+ * read once at `load`. Reading `source.revision` when answering would describe
+ * the caller's object as it is now, not the policies that were compiled.
  */
 export const cedarWasmEngine = {
     name: CEDAR_WASM_ENGINE_NAME,
     async: false,
     confirmsRevision: true,
     load(source) {
-        for (const file of source.files) {
-            const answer = checkParsePolicySet({ staticPolicies: file.text });
-            if (answer.type === "failure") {
-                throw new CedarEngineError(`${file.source} failed to parse: ${details(answer.errors)}`);
-            }
-        }
+        const policies = namePolicies(source.files, policiesOf);
         // Captured with the compile below, not read per answer — see the doc comment.
         const { revision } = source;
         const policySetId = `auth.policy-verifier.cedar-wasm:${policySetCounter++}`;
-        const compiled = preparsePolicySet(policySetId, { staticPolicies: source.text });
+        const compiled = preparsePolicySet(policySetId, {
+            staticPolicies: Object.fromEntries(policies.map((policy) => [policy.id, policy.text])),
+        });
         if (compiled.type === "failure") {
             throw new CedarEngineError(`policy set from ${source.description} failed to compile: ${details(compiled.errors)}`);
         }
@@ -70,6 +71,30 @@ export const cedarWasmEngine = {
         };
     },
 };
+/**
+ * The policies of one file, as text, in the file's order. Cedar splits a file
+ * under positional ids — `policy0`, `policy1`… — and hands the parts back
+ * sorted by those ids as strings, so `policy10` comes before `policy2`; the
+ * order is undone here by sorting the same ids the same way. That sort is the
+ * pinned `@cedar-policy/cedar-wasm`'s (see package.json); the test of a file
+ * holding a dozen policies fails on a release that sorts otherwise.
+ */
+function policiesOf(file) {
+    const parts = policySetTextToParts(file.text);
+    if (parts.type === "failure") {
+        throw new CedarEngineError(`${file.source} failed to parse: ${details(parts.errors)}`);
+    }
+    if (parts.policy_templates.length > 0) {
+        // An unlinked template never applies, and this engine links none.
+        throw new CedarEngineError(`${file.source} holds a template — a policy with ?principal or ?resource never applies here, because nothing links it`);
+    }
+    const sorted = parts.policies.map((_, position) => `policy${position}`).sort();
+    const inFileOrder = new Array(parts.policies.length);
+    for (const [at, id] of sorted.entries()) {
+        inFileOrder[Number(id.slice("policy".length))] = parts.policies[at];
+    }
+    return inFileOrder;
+}
 function details(errors) {
     return errors.map((error) => error.message).join("; ");
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@o3co/auth.policy-verifier.cedar-wasm",
-  "version": "0.14.0",
+  "version": "0.16.0",
   "license": "Apache-2.0",
   "type": "module",
   "engines": {
@@ -26,13 +26,13 @@
   },
   "dependencies": {
     "@cedar-policy/cedar-wasm": "4.13.0",
-    "@o3co/auth.policy-verifier.cedar": "0.14.0"
+    "@o3co/auth.policy-verifier.cedar": "0.16.0"
   },
   "devDependencies": {
-    "@types/node": "^26.6.2",
-    "@vitest/coverage-v8": "^5.0.1",
-    "vitest": "^5.0.1",
-    "@o3co/auth.policy-verifier.core": "0.14.0"
+    "@types/node": "^26.6.3",
+    "@vitest/coverage-v8": "^5.0.2",
+    "vitest": "^5.0.2",
+    "@o3co/auth.policy-verifier.core": "0.16.0"
   },
   "scripts": {
     "prebuild": "rimraf dist",