@blamejs/blamejs-shop 0.4.2 → 0.4.3

package/CHANGELOG.md

@@ -8,6 +8,8 @@ upgrading across more than a few patches at a time.
 
 ## v0.4.x
 
+- v0.4.3 (2026-06-05) — **Passkey sign-in works again: WebAuthn is permitted on the pages that host it.** The framework's deny-all Permissions-Policy disabled the browser's WebAuthn API everywhere — including the sign-in page's own top-level document — so attempting a passkey sign-in failed with the browser reporting that publickey-credentials-get is not enabled. The policy now permits exactly the WebAuthn capability each ceremony page needs: credential assertion on the sign-in page, credential creation on the registration and passkey-management pages, both scoped to the page's own origin. Every other page keeps the strict deny-all policy, and every other feature (camera, microphone, geolocation, payment outside the payment page) remains denied on the ceremony pages too. **Fixed:** *Passkey ceremonies are no longer blocked by Permissions-Policy* — Sign-in carries publickey-credentials-get=(self); registration and passkey management carry publickey-credentials-create=(self). The allowance is scoped per route following the same pattern the payment page uses, grants apply only to the page's own origin (no cross-origin delegation), and unrecognized feature requests relax nothing. Tests assert the exact header tokens per route and that unrelated pages still deny both WebAuthn features.
+
 - v0.4.2 (2026-06-05) — **Abandoned checkouts release their stock holds, and five more inventory and admin hardening fixes.** The inventory enforcement introduced in 0.4.0 placed a stock hold at checkout but had no path to free it when a buyer abandoned without paying or cancelling — each abandoned checkout permanently subtracted from sellable stock until an operator intervened. A scheduled reaper now cancels pending orders older than a configurable age (default two hours), cancelling the payment intent first so a late payment can never complete against a reaped order, and releasing the held stock through the existing cancellation path. Around it, five more fixes harden the same surface: settlement failures during payment confirmation no longer strand holds silently (each item settles independently and failures land in the operator error log with the exact item and quantity), a rollback path no longer releases holds belonging to an order that was successfully created, pre-order campaigns whose launch date has passed now enforce real stock limits instead of remaining exempt, the admin activity timeline rejects protocol-relative link targets, and activity reads are bounded instead of scanning a customer's full history per page view. **Fixed:** *Stock holds from abandoned checkouts are reclaimed* — A pending order that never completes payment now has its stock hold released automatically. The scheduled reaper cancels pending orders older than CHECKOUT_PENDING_TTL_MINUTES (default 120, minimum 5; invalid values refuse to boot). For card payments the payment intent is cancelled at the processor before the order is touched — if the processor reports the payment already succeeded, the order is left alone for the webhook to settle. Each sweep reports counts of reaped, skipped, and errored orders. · *Payment settlement is crash-safe per item* — When an order is marked paid, each line's stock decrement now settles independently: one item's database failure no longer blocks the others, no longer fails the payment webhook, and is captured to the operator error log naming the item, quantity, and order so the operator can reconcile stock from the existing adjustment screen. · *Checkout rollback no longer releases holds it does not own* — If checkout fails after the order record was created, the error path previously released all of the attempt's stock holds — which could free units belonging to the order itself or, on a shared item, a concurrent shopper's reservation. Holds are now released on failure only when no order was created; once an order exists it owns its holds, and cancellation or the reaper frees them. The same correction applies to the PayPal order-creation path. · *Pre-order campaigns enforce stock after their launch date* — An active pre-order campaign exempts its product from stock holds by design — pre-orders sell beyond the shelf. That exemption now ends when the campaign's launch date passes: a launched product sells from real inventory even if the campaign has not yet been moved out of its pre-order state in the console. · *Admin activity links and reads hardened* — The customer activity timeline's internal-link guard now rejects protocol-relative targets, and each activity source is read with a bound matching the requested page instead of scanning the customer's entire history. Pagination, ordering, and the summary counts are unchanged.
 
 - v0.4.1 (2026-06-05) — **Order notes and a customer activity timeline in the admin console.** Two operator surfaces land in the admin console. Every order detail screen gains a customer-service notes thread: operators record internal notes or customer-visible ones, pin the important thread to the top, and mark issues resolved or reopen them — with note bodies length-bounded, control-character-rejected, and escaped at render. Every customer detail screen gains a read-only activity timeline aggregating what that customer has done across the store — orders placed and their lifecycle transitions, loyalty points earned, wishlist additions, reviews submitted, and support tickets opened — read directly from the tables those features already populate, newest first. Both panels appear only when their backing modules are wired, and every note mutation is ownership-scoped to its order and audited. **Added:** *Customer-service notes on order detail* — The admin order screen shows a notes thread with pinned notes floated first and the rest newest-first. Operators add notes as internal (the default) or customer-visible, pin and unpin them, and resolve or reopen them with a short resolution summary; resolving a customer-visible note is refused so customer-facing context is never silently closed out. Bodies are validated server-side (8000-character cap, control characters rejected) and HTML-escaped at render. Each mutation verifies the note belongs to the order in the URL before acting, returns clean errors for unknown or malformed identifiers, and emits an audit event. The same surface is available as JSON under the admin bearer token. · *Customer activity timeline on customer detail* — The admin customer screen shows an aggregated, newest-first activity feed: order placements and status transitions, loyalty point movements, wishlist additions, review submissions, and support tickets. The timeline is a read-only view over the tables those features already write — no new tracking or recording was added anywhere in the request path. The panel shows the most recent fifty events, links each event to its admin screen where one exists, and renders an explicit empty state for customers with no history. The same feed is available as JSON under the admin bearer token.

package/lib/asset-manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "0.4.2",
+  "version": "0.4.3",
   "assets": {
     "css/admin.css": {
       "integrity": "sha384-6k53cvkRrxMgmeStLIoLjVXZQHqIJgTmv1Izd8TYhh1HOC4POgE6GCvx1bsalyEP",

package/lib/security-middleware.js

@@ -380,31 +380,42 @@ function scopedCsp(keys) {
   }).join("; ") + ";";
 }
 
-// ---- route-scoped Permissions-Policy (payment surface) ------------------
+// ---- route-scoped Permissions-Policy (payment + passkey surfaces) --------
 //
 // The app-level Permissions-Policy is the vendored strict denylist
-// (DEFAULT_PERMISSIONS) — every powerful API, including `payment=()`,
-// disabled in every document. That is correct everywhere EXCEPT the one
-// page whose entire job is taking a payment: GET /pay/:order_id mounts
-// Stripe's Express Checkout Element, whose Google Pay / Apple Pay buttons
-// drive the Payment Request API. Under `payment=()` the browser refuses
-// the API inside the cross-origin pay.google.com / Stripe wallet frames
-// ("Permissions policy violation: payment is not allowed in this
-// document"), so the wallet express buttons are degraded on the payment
-// page. The card form is unaffected (it doesn't use the Payment Request
-// API), which is why card captures complete while wallets don't.
+// (DEFAULT_PERMISSIONS) — every powerful API disabled in every document,
+// including `payment=()`, `publickey-credentials-get=()`, and
+// `publickey-credentials-create=()`. That is correct everywhere EXCEPT the
+// handful of pages whose whole job needs one of those features:
 //
-// `scopedPermissionsPolicy()` returns a Permissions-Policy string for
-// `res.setHeader("permissions-policy", ...)` on the /pay route's response:
-// byte-identical to the vendored default EXCEPT the `payment=()` entry,
-// which becomes `payment=(self "https://js.stripe.com" "https://pay.google.com")`
-// — granting the feature ONLY to the same origin + the Stripe SDK frame +
-// the Google Pay frame, ONLY on that one response. setHeader OVERWRITES, so
-// the app-level strict header still governs every OTHER route. Every other
-// feature in the denylist stays `()`. Derived from the vendored
-// DEFAULT_PERMISSIONS array (the single source the app-level header is also
-// built from in `securityHeadersOpts` → the vendored default), never a
-// hand-forked copy of the list.
+//   - GET /pay/:order_id mounts Stripe's Express Checkout Element, whose
+//     Google Pay / Apple Pay buttons drive the Payment Request API. Under
+//     `payment=()` the browser refuses the API inside the cross-origin
+//     pay.google.com / Stripe wallet frames, degrading the wallet express
+//     buttons (the card form is unaffected, which is why card captures
+//     complete while wallets don't).
+//
+//   - The passkey (WebAuthn) ceremonies. `navigator.credentials.get()`
+//     (assertion / sign-in) is gated by `publickey-credentials-get`;
+//     `navigator.credentials.create()` (registration / enrollment) by
+//     `publickey-credentials-create`. Under the deny-all default the browser
+//     refuses the API in the TOP-LEVEL document with "The
+//     'publickey-credentials-get' feature is not enabled in this document"
+//     (resp. -create), so sign-in / enrollment fail outright. These run on
+//     container-served routes:
+//       publickey-credentials-get    — GET /account/login (passkey-login.js)
+//       publickey-credentials-create — GET /account/register (passkey-register.js)
+//                                       GET /account/passkeys (passkey-add.js)
+//
+// `scopedPermissionsPolicy(opts)` returns a Permissions-Policy string for
+// `res.setHeader("permissions-policy", ...)` on the route's response:
+// byte-identical to the vendored default EXCEPT the named feature(s), each
+// re-enabled for ONLY the allowlist that feature needs, ONLY on that one
+// response. setHeader OVERWRITES, so the app-level strict header still
+// governs every OTHER route. Every other feature in the denylist stays `()`.
+// Derived from the vendored DEFAULT_PERMISSIONS array (the single source the
+// app-level header is also built from in `securityHeadersOpts` → the vendored
+// default), never a hand-forked copy of the list.
 
 // The allowlist that replaces `payment=()` on the pay surface: same origin
 // (the pay page's own form), the Stripe SDK frame, and the Google Pay frame
@@ -415,21 +426,61 @@ function scopedCsp(keys) {
 // it here.
 var _PAYMENT_ALLOWLIST = 'payment=(self "https://js.stripe.com" "https://pay.google.com")';
 
+// WebAuthn assertion / attestation run in the page's OWN top-level document
+// (the islands call navigator.credentials.get / .create directly, never from
+// a cross-origin child frame), so `self` is the entire allowlist — no third-
+// party origin is delegated. Keeping the grant to `self` is the tightest
+// value that unblocks the ceremony: a cross-origin iframe on the same page
+// still cannot drive WebAuthn. Single source — every passkey page names the
+// feature → allowlist mapping here.
+var _PASSKEY_FEATURE_ALLOWLIST = {
+  "publickey-credentials-get":    "publickey-credentials-get=(self)",
+  "publickey-credentials-create": "publickey-credentials-create=(self)",
+};
+
+// Feature name → its scoped allowlist token. The pay surface relaxes
+// `payment`; the passkey surfaces relax the two WebAuthn features. A caller
+// names which feature(s) to relax; every feature NOT named stays at the
+// vendored `()` deny. This is the single registry of "which feature may be
+// re-enabled, and to exactly what" — nothing outside it can be loosened.
+var _SCOPED_FEATURE_OVERRIDES = Object.assign(
+  { payment: _PAYMENT_ALLOWLIST },
+  _PASSKEY_FEATURE_ALLOWLIST
+);
+
 /**
  * Build a route-scoped Permissions-Policy string from the vendored strict
- * denylist with the `payment` feature re-enabled for the same origin + the
- * Stripe / Google Pay wallet frames. Every other feature is carried through
- * verbatim as `feature=()`. Returns the string for the pay route's
+ * denylist with one or more features re-enabled to their scoped allowlist.
+ * `opts.features` is an array of feature names to relax (each must appear in
+ * `_SCOPED_FEATURE_OVERRIDES`); every other feature is carried through
+ * verbatim as `feature=()`. With no argument it defaults to relaxing
+ * `payment` — the established pay-surface behavior — so existing callers are
+ * unchanged. Returns the string for the route's
  * `res.setHeader("permissions-policy", ...)`; the app-level strict header is
  * unchanged on every other route (setHeader overwrites this one response).
  *
- * Called per-response on the pay render path, so it never throws — it maps
- * over the vendored default array and swaps the one entry, failing safe (a
- * missing `payment` entry simply yields the strict default for that feature).
+ * Called per-response on a render path, so it never throws — it maps over the
+ * vendored default array and swaps only the named entries, failing safe (an
+ * unknown feature name simply leaves that feature at the strict deny, and a
+ * feature the default does not list is never invented).
  */
-function scopedPermissionsPolicy() {
+function scopedPermissionsPolicy(opts) {
+  var features = (opts && Array.isArray(opts.features) && opts.features.length)
+    ? opts.features
+    : ["payment"];
+  // Map requested feature names → their override token, ignoring any name not
+  // in the registry (fail-safe: an unknown key relaxes nothing).
+  var overrides = {};
+  features.forEach(function (name) {
+    if (Object.prototype.hasOwnProperty.call(_SCOPED_FEATURE_OVERRIDES, name)) {
+      overrides[name] = _SCOPED_FEATURE_OVERRIDES[name];
+    }
+  });
   return _vendoredSecurityHeaders.DEFAULT_PERMISSIONS.map(function (entry) {
-    return entry.indexOf("payment=") === 0 ? _PAYMENT_ALLOWLIST : entry;
+    var feature = entry.split("=")[0];
+    return Object.prototype.hasOwnProperty.call(overrides, feature)
+      ? overrides[feature]
+      : entry;
   }).join(", ");
 }
 

package/lib/storefront.js

@@ -13447,6 +13447,13 @@ function mount(router, deps) {
       // Login captcha is opt-in (CAPTCHA_GATE_LOGIN). The widget + the scoped
       // CSP that admits the provider host render only when login is opted in.
       _setAuthCaptchaCsp(res, "login");
+      // Passkey sign-in (passkey-login.js) calls navigator.credentials.get(),
+      // which the app-level Permissions-Policy denies via
+      // publickey-credentials-get=(). Re-enable it for self on THIS response
+      // only so the assertion runs in the top-level document; every other
+      // feature stays denied and every other route keeps the strict default.
+      res.setHeader && res.setHeader("permissions-policy",
+        securityMiddleware.scopedPermissionsPolicy({ features: ["publickey-credentials-get"] }));
       _send(res, 200, renderAccountLogin({
         shop_name:      shopName,
         cart_count:     cartCount,
@@ -13464,6 +13471,12 @@ function mount(router, deps) {
       // Signup captcha renders whenever a provider is active; the scoped CSP
       // admits the provider host only then (no setHeader otherwise).
       _setAuthCaptchaCsp(res, "signup");
+      // Passkey enrollment (passkey-register.js) calls
+      // navigator.credentials.create(), denied by the app-level
+      // publickey-credentials-create=(). Re-enable it for self on THIS
+      // response only so registration runs in the top-level document.
+      res.setHeader && res.setHeader("permissions-policy",
+        securityMiddleware.scopedPermissionsPolicy({ features: ["publickey-credentials-create"] }));
       _send(res, 200, renderAccountRegister({
         shop_name: shopName,
         cart_count: cartCount,
@@ -13982,6 +13995,12 @@ function mount(router, deps) {
       var cartCount = await _cartCountForReq(req);
       var url = req.url ? new URL(req.url, "http://localhost") : null;
       var okKind = url ? url.searchParams.get("ok") : null;
+      // The "Add a passkey" island (passkey-add.js) calls
+      // navigator.credentials.create(), denied by the app-level
+      // publickey-credentials-create=(). Re-enable it for self on THIS
+      // response only so enrollment runs in the top-level document.
+      res.setHeader && res.setHeader("permissions-policy",
+        securityMiddleware.scopedPermissionsPolicy({ features: ["publickey-credentials-create"] }));
       _send(res, code || 200, renderPasskeys({
         passkeys:   pks,
         has_oauth:  hasOAuth,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blamejs/blamejs-shop",
-  "version": "0.4.2",
+  "version": "0.4.3",
   "description": "Open-source framework built on blamejs. Vendored stack, zero npm runtime deps, PQC-first crypto, security-on by default.",
   "main": "lib/index.js",
   "scripts": {