@blamejs/blamejs-shop 0.4.69 → 0.4.71

package/CHANGELOG.md

@@ -8,6 +8,10 @@ upgrading across more than a few patches at a time.
 
 ## v0.4.x
 
+- v0.4.71 (2026-06-21) — **SMS dispatch and shipping-insurance adjudication now claim their state transition atomically.** Two exactly-once state transitions advanced their row with a primary-key UPDATE that was not gated on the expected prior status, so two concurrent callers could both win the transition. The scheduled SMS dispatch tick flipped a queued message to sent without an `AND status = 'queued'` guard, so two overlapping ticks could both hand the same message to the provider send hook — a duplicate text and a duplicate carrier charge. The shipping-insurance claim adjudication flipped a filed claim to approved or denied the same way, so a double-submitted approval (or an approval racing a denial) could record two different payout amounts as THE payout, or let a denial clobber an approval. Both transitions now gate the UPDATE on the prior status and act only on the row the UPDATE actually claimed (rowCount === 1); the loser is skipped or refused, matching the atomic-claim shape already used by the push-notification dispatch tick and the affiliate-commission payout. **Fixed:** *SMS dispatch tick advances each message exactly once under concurrent ticks* — The queued→sent (and the no-provider queued→failed) transition in the SMS dispatch tick now gates its UPDATE on `AND status = 'queued'` and hands a message to the operator's send hook only when the UPDATE actually claimed the row. Two overlapping ticks can no longer both dispatch the same message, so a customer is never double-texted and the carrier is never billed twice for one message. · *Shipping-insurance claim adjudication records exactly one outcome under concurrent callers* — markClaimApproved and markClaimDenied now gate their transition on `AND status = 'filed'` and refuse the caller whose UPDATE claimed no row. A double-submitted approval can no longer record two different payout amounts as the approved payout, and an approval can no longer clobber a denial (or vice-versa) — exactly one adjudication outcome sticks.
+
+- v0.4.70 (2026-06-21) — **Bundled framework refreshed to blamejs 0.15.14, with the proxy-trust hardening wired through.** Refreshes the vendored blamejs to 0.15.14 — a broad security-hardening release that peer-gates every request-IP and protocol trust decision against the connecting socket, fails closed on a set of authentication and signature verifiers, bounds pre-authentication parsers against algorithmic-complexity denial of service, makes the framework's own file writes atomic and symlink-refusing, and adds a JSON serializer safe to embed in an inline script. The one behavior change that touches a deployment behind a TLS-terminating edge is how the client protocol is trusted: a bare trust-the-forwarded-header flag is no longer accepted for the HSTS and CSRF decisions, because a caller able to reach the origin socket could forge it. The storefront resolves the forwarded protocol through one owned model that the HSTS header, the CSRF origin check, and both session-cookie Secure decisions now share — so HSTS on container responses and authenticated forms behind the Cloudflare edge keep working with no operator action. **Changed:** *Bundled blamejs refreshed to 0.15.14* — Picks up the upstream security-hardening release: client-IP and protocol trust resolved by a peer-gated walk anchored at the connecting socket; SAML, electronic-signature, SD-JWT, DPoP, CIBA, mdoc, and COSE verifiers that could accept a malformed or unsigned credential now refuse it; pre-authentication parsers (CBOR, JSONPath, tar, gzip, YAML, ASN.1 DER) bounded against quadratic-time and frame-desync denial of service; allowlist and posture lookups keyed by untrusted input can no longer reach the prototype chain; the framework's predictable-temp and symlink-following writes go through atomic, symlink-refusing primitives; and several lost-update races (login lockout, bot-challenge, inline webhook delivery) are serialized. · *HSTS and CSRF protocol trust resolved through one owned model behind the edge* — The framework retired the bare forwarded-header trust flag for the decisions that depend on the client protocol (whether to emit HSTS, whether to set the Secure cookie attribute, and the CSRF origin pre-check), since a caller that can reach the origin socket could forge the header. The storefront now resolves the protocol through a single function shared by the security-headers middleware, the CSRF gate, and both the storefront and admin session-cookie paths. Behind the Cloudflare edge the resolver honours the worker-forwarded scheme; a direct connection with no forwarded header resolves to the socket scheme. HSTS on container-served responses and authenticated forms behind the CDN are unchanged; no configuration is required.
+
 - v0.4.69 (2026-06-20) — **A gift-card redemption that can't record its audit row no longer loses the balance.** Redeeming a gift card debits the card's balance in one atomic conditional update, then writes a redemption record in a separate statement. Because the bridge runs each statement on its own, a transient failure writing that record left the balance already debited with no redemption row — and the reversal path keys on that row, so the spent balance could never be returned. Redemption is now all-or-nothing: if the record can't be written, the card is re-credited for the amount (and moved back to active if the debit had zeroed it and closed it) before the error is surfaced, so a failed redemption never silently consumes a customer's balance. No API change. **Fixed:** *Redemption re-credits the card if its audit row can't be written* — After the atomic balance debit, the redemption record insert is wrapped so a transient write failure re-credits the card by the redeemed amount and restores it to active if that debit had zeroed and closed it. The customer keeps the balance and the card stays usable, instead of losing the spend to a redemption that left no row for the reversal path to act on.
 
 - v0.4.68 (2026-06-20) — **Redeeming a loyalty reward no longer burns points on a failed mint or exceeds the per-customer cap under load.** Redeeming a reward for points debited the customer's balance, then checked the per-customer redemption cap with a separate count and minted the reward coupon as separate steps. Two problems followed. The cap was a read-then-act check: two redemptions arriving together both read a count under the cap and both succeeded, so a customer could exceed a lifetime cap (for example mint two of a once-ever coupon). And if the coupon mint failed after the points were debited — the coupons primitive erroring, or a transient fault — the points were gone with no redemption row recorded, so no refund path could return them; the customer was charged for a reward they never received. Redemption now claims the cap slot in a single conditional insert that recomputes the live count, so concurrent redemptions can't both exceed the cap, and it reverses the points debit (and removes the claimed row) if the coupon can't be minted, so a failed redemption always leaves the balance whole. No API change. **Fixed:** *Per-customer redemption cap is enforced atomically* — The redemption row is now inserted only if the customer's live active/consumed count for that reward is still under the cap, recomputed inside the insert. Two redemptions racing the last slot resolve to a single winner; the loser is refused with the same cap error and its points are returned. The cheap pre-check is kept as a fast path but is no longer the thing that enforces the limit. · *A failed coupon mint returns the points and leaves no row* — If the coupon can't be minted after the points were debited and the slot claimed, both are rolled back — the points debit is reversed and the claimed redemption row is removed — so the customer's balance is whole and no redemption is left recorded for a reward that was never issued. The points reversal rides the same idempotent restore the checkout path uses, so a retry credits exactly once.

package/lib/admin.js

@@ -41,6 +41,7 @@ var trustBadgesModule = require("./trust-badges");
 var cartModule = require("./cart");   // ABANDONED_* window/limit constants for the /admin/carts console
 var inventoryWriteoffsModule = require("./inventory-writeoffs");   // WRITEOFF_REASONS enum for the /admin/inventory/writeoffs console
 var textGuard = require("./text-guard");
+var securityMiddleware = require("./security-middleware");   // resolveProtocol — shared proxy-trust model for the Secure-cookie decision
 var { AsyncLocalStorage } = require("node:async_hooks");   // allow:non-shop-require — Node-core per-request context (no npm dep); the framework itself composes it in db-role-context / log. No b.* request-context primitive exists to wrap it.
 
 var b = require("./vendor/blamejs");
@@ -510,13 +511,14 @@ function _adminJar() {
 
 // Whether THIS request's PUBLIC connection is https — drives both the
 // Secure attribute and the prefix choice for the admin session cookie.
-// Same rule as the storefront: trust the Worker-set `x-forwarded-proto`
-// (the container socket may be plain http behind the TLS-terminating
-// Worker), and treat a direct dev/e2e connection (no forwarded header,
-// non-encrypted socket) as http so the bare-named, non-Secure cookie is
-// emitted and a real browser stores it.
+// Same rule as the storefront: resolve the Worker-set `x-forwarded-proto`
+// through the shared securityMiddleware.resolveProtocol (the container
+// socket may be plain http behind the TLS-terminating Worker), and treat a
+// direct dev/e2e connection (no forwarded header, non-encrypted socket) as
+// http so the bare-named, non-Secure cookie is emitted and a real browser
+// stores it. One proxy-trust model across HSTS, csrf, and both cookie paths.
 function _secureForReq(req) {
-  return b.requestHelpers.requestProtocol(req, { trustProxy: true }) === "https";
+  return securityMiddleware.resolveProtocol(req) === "https";
 }
 function _adminCookieName(secure) { return secure ? ADMIN_COOKIE_NAME_SECURE : ADMIN_COOKIE_NAME; }
 

package/lib/asset-manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "0.4.69",
+  "version": "0.4.71",
   "assets": {
     "css/admin.css": {
       "integrity": "sha384-imfe0otYErcB8rr2h6KLSGTtStirysptpXETSPY4zLv3bZoIT75Lo1dOvkOav+xL",

package/lib/security-middleware.js

@@ -293,6 +293,42 @@ function clientKey(req) {
   return sock || "unknown";
 }
 
+/**
+ * Own the HTTPS decision for every proxy-trust consumer in one place — the
+ * single trust model the security middleware (HSTS via securityHeaders, the
+ * Secure-cookie + Origin pre-check via csrfProtect) and the storefront/admin
+ * session-cookie Secure flag all resolve protocol through.
+ *
+ * Topology: the Node container has NO public ingress. It is reachable only
+ * through the Cloudflare Worker over the service binding, and the edge always
+ * terminates TLS, so the real client scheme rides in the Worker-set
+ * `x-forwarded-proto` (always `https` for a real visitor). Because no internet
+ * caller can reach the container socket, that header cannot be forged from
+ * outside — so honoring it is correct here. blamejs 0.15.14 stopped trusting a
+ * bare `trustProxy` (a forgeable X-Forwarded-Proto from a *directly reachable*
+ * socket); it hands the decision to an operator-supplied `protocolResolver`
+ * when the operator can attest the header's provenance, which this deployment
+ * can. A direct dev / e2e connection carries no forwarded header and a plain
+ * socket, so it resolves to `http` (and the bare-named, non-Secure cookie a
+ * browser will actually store over loopback is emitted).
+ *
+ * Request-shape reader — returns "http"|"https" for any input, never throws.
+ */
+function resolveProtocol(req) {
+  var headers = (req && req.headers) || {};
+  var xfp = headers["x-forwarded-proto"];
+  if (typeof xfp === "string" && xfp.length > 0) {
+    // Leftmost hop is the original client scheme (the Worker sets a single
+    // `https` token). Normalize and accept only the two valid schemes.
+    var first = xfp.split(",")[0].trim().toLowerCase();
+    if (first === "https" || first === "http") return first;
+  }
+  // No forwarded header → direct connection. Delegate the socket-scheme
+  // derivation to the vendored primitive (trustProxy:false = socket-only) so
+  // that fallback stays single-sourced in the framework.
+  return b.requestHelpers.requestProtocol(req, { trustProxy: false });
+}
+
 /**
  * Build the security-headers options for createApp's
  * `middleware.securityHeaders`. The vendored blamejs default emits a
@@ -333,25 +369,28 @@ function clientKey(req) {
  * so both substrates stay header-consistent.
  */
 function securityHeadersOpts() {
-  // `trustProxy: true` is what lets the vendored HSTS header actually
+  // `protocolResolver` is what lets the vendored HSTS header actually
   // ship from the container. The vendored securityHeaders middleware
   // emits Strict-Transport-Security ONLY when the request protocol
   // resolves to https (RFC 6797 §7.2: HSTS over plain HTTP is ignored by
   // UAs, so the middleware suppresses it on non-TLS requests). Behind the
   // Cloudflare Worker the container socket is plain http and the real
-  // scheme rides in the Worker-set `x-forwarded-proto: https` — without
-  // trustProxy the middleware reads `http`, decides the request isn't
-  // TLS, and drops HSTS on EVERY container-served response. The edge
-  // Worker sets its own HSTS on edge-rendered pages, but a direct-to-
-  // container request (edge render off, or an internal hop that returns
-  // HTML) then carries no HSTS at all. Opting into the forwarded-proto
-  // header — the same stance the csrf gate already takes (mountRouteGuards
-  // passes trustProxy:true) and the storefront session-cookie path takes
-  // (`_secureForReq`) — restores the header on container responses. HSTS
-  // stays OWNED by the vendored middleware (we set no header ourselves),
-  // so there is no double-set: on an edge-rendered page only the Worker's
-  // header is present; on a container-served page only this one is.
-  return { documentPolicy: false, referrerPolicy: "same-origin", trustProxy: true };
+  // scheme rides in the Worker-set `x-forwarded-proto: https` — left to
+  // its default (socket only) the middleware reads `http`, decides the
+  // request isn't TLS, and drops HSTS on EVERY container-served response.
+  // The edge Worker sets its own HSTS on edge-rendered pages, but a
+  // direct-to-container request (edge render off, or an internal hop that
+  // returns HTML) then carries no HSTS at all. blamejs 0.15.14 refuses a
+  // bare `trustProxy` for this decision (an attacker who can reach the
+  // socket could forge X-Forwarded-Proto to suppress HSTS), so we own the
+  // decision via `resolveProtocol` — sound here because the container has
+  // no public ingress (see resolveProtocol). The csrf gate and the
+  // storefront/admin session-cookie path resolve protocol the same way
+  // (one trust model). HSTS stays OWNED by the vendored middleware (we set
+  // no header ourselves), so there is no double-set: on an edge-rendered
+  // page only the Worker's header is present; on a container-served page
+  // only this one is.
+  return { documentPolicy: false, referrerPolicy: "same-origin", protocolResolver: resolveProtocol };
 }
 
 // ---- route-scoped CSP (payment processors + CAPTCHA providers) ----------
@@ -730,16 +769,18 @@ function mountRouteGuards(r) {
     cookie:        true,
     skipStateless: true,
     // Behind the Cloudflare Worker the container connection is plain http
-    // while the visitor is on https; trustProxy opts in the Worker-set
-    // `x-forwarded-proto` so the origin pre-check derives the real public
-    // origin (and the token cookie carries the `__Host-csrf` prefix),
+    // while the visitor is on https; `protocolResolver` owns the Worker-set
+    // `x-forwarded-proto` read so the origin pre-check derives the real
+    // public origin (and the token cookie carries the `__Host-csrf` prefix),
     // matching the session-cookie stance (storefront `_secureForReq`).
-    // allowedOrigins is the explicit public-host allowlist so a legitimate
-    // same-origin POST is never refused as cross-origin on a proxy
-    // scheme/host mismatch — the regression that breaks sign-in + every
-    // authenticated form behind the CDN.
-    trustProxy:     true,
-    allowedOrigins: PUBLIC_ORIGINS,
+    // blamejs 0.15.14 refuses a bare `trustProxy` here (forgeable from a
+    // directly-reachable socket); the resolver is sound because the
+    // container has no public ingress (see resolveProtocol). allowedOrigins
+    // is the explicit public-host allowlist so a legitimate same-origin POST
+    // is never refused as cross-origin on a proxy scheme/host mismatch — the
+    // regression that breaks sign-in + every authenticated form behind the CDN.
+    protocolResolver: resolveProtocol,
+    allowedOrigins:   PUBLIC_ORIGINS,
   });
   r.use(function csrfGuard(req, res, next) {
     var pathname = req.pathname || req.url || "/";
@@ -844,6 +885,7 @@ function mountRouteGuards(r) {
 
 module.exports = {
   clientKey:            clientKey,
+  resolveProtocol:      resolveProtocol,
   securityHeadersOpts:  securityHeadersOpts,
   globalRateLimitOpts:  globalRateLimitOpts,
   botGuardOpts:         botGuardOpts,

package/lib/shipping-insurance.js

@@ -603,11 +603,26 @@ function create(opts) {
         ins.declared_value_minor + " on the parent insurance");
     }
     var now = _now();
-    await query(
+    // Atomic claim: the `AND status = 'filed'` predicate is the
+    // serialization point. The JS check above only refuses a SEQUENTIAL
+    // re-adjudication; two concurrent approve calls (a double-clicked
+    // operator action, a retried insurer callback) would both read
+    // 'filed' and both stamp a payout last-write-wins — two different
+    // payout_minor amounts could each be recorded as THE approved payout,
+    // or an approve could clobber a deny. Gating the UPDATE on the status
+    // means exactly one caller transitions the row; the loser sees zero
+    // rows and is refused, so one adjudication outcome sticks.
+    var approvedUpd = await query(
       "UPDATE insurance_claims SET status = 'approved', payout_minor = ?1, " +
-      "resolved_at = ?2, updated_at = ?2 WHERE id = ?3",
+      "resolved_at = ?2, updated_at = ?2 WHERE id = ?3 AND status = 'filed'",
       [input.payout_minor, now, claimId],
     );
+    if (Number(approvedUpd.rowCount || 0) !== 1) {
+      var racedApprove = await _getClaimRow(claimId);
+      throw new TypeError("shippingInsurance.markClaimApproved: claim " + claimId +
+        " is " + (racedApprove ? racedApprove.status : "gone") +
+        ", only filed claims can move to approved");
+    }
     return _hydrateClaim(await _getClaimRow(claimId));
   }
 
@@ -630,11 +645,21 @@ function create(opts) {
         " is " + claim.status + ", only filed claims can move to denied");
     }
     var now = _now();
-    await query(
+    // Atomic claim — same race, same guard as markClaimApproved: the
+    // `AND status = 'filed'` predicate serializes the two concurrent
+    // callers so exactly one adjudication outcome (approve XOR deny)
+    // transitions the row; the loser is refused.
+    var deniedUpd = await query(
       "UPDATE insurance_claims SET status = 'denied', denial_reason = ?1, " +
-      "resolved_at = ?2, updated_at = ?2 WHERE id = ?3",
+      "resolved_at = ?2, updated_at = ?2 WHERE id = ?3 AND status = 'filed'",
       [denialReason, now, claimId],
     );
+    if (Number(deniedUpd.rowCount || 0) !== 1) {
+      var racedDeny = await _getClaimRow(claimId);
+      throw new TypeError("shippingInsurance.markClaimDenied: claim " + claimId +
+        " is " + (racedDeny ? racedDeny.status : "gone") +
+        ", only filed claims can move to denied");
+    }
     return _hydrateClaim(await _getClaimRow(claimId));
   }
 

package/lib/sms-dispatcher.js

@@ -867,19 +867,32 @@ function create(opts) {
           if (resolved) providerSlug = resolved.slug;
         }
         if (!providerSlug) {
-          await query(
+          // Atomic claim. The snapshot SELECT above is read without a
+          // lock, so two concurrent ticks can both pull this same
+          // `queued` row. The `AND status = 'queued'` guard makes the
+          // transition the claim: SQLite/D1 serialises writers, so
+          // exactly one tick's UPDATE matches the row (rowCount === 1)
+          // and the other sees rowCount === 0. Only the winner hands the
+          // row to the operator's send hook (via `advanced`), so the
+          // terminal failure is recorded — and surfaced — exactly once.
+          var lostFail = await query(
             "UPDATE sms_messages SET status = 'failed', failure_reason = ?1, " +
-            "failed_at = ?2 WHERE id = ?3",
+            "failed_at = ?2 WHERE id = ?3 AND status = 'queued'",
             ["no_provider_at_dispatch", now, row.id],
           );
+          if (Number(lostFail.rowCount || 0) !== 1) continue;
           advanced.push(await _getMessage(row.id));
           continue;
         }
-        await query(
+        // Atomic claim on the advance to `sent` — same race, same guard.
+        // The loser skips so the operator's send hook (the real provider
+        // POST) fires once per row, never twice for one message.
+        var claimed = await query(
           "UPDATE sms_messages SET status = 'sent', provider_slug = ?1, " +
-          "sent_at = ?2 WHERE id = ?3",
+          "sent_at = ?2 WHERE id = ?3 AND status = 'queued'",
           [providerSlug, now, row.id],
         );
+        if (Number(claimed.rowCount || 0) !== 1) continue;
         advanced.push(await _getMessage(row.id));
       }
       return advanced;

package/lib/storefront.js

@@ -9600,14 +9600,17 @@ function _readCookie(req, name) {
 // of truth for both the Secure attribute and the cookie-prefix choice.
 // The container socket behind the Cloudflare Worker may be plain http even
 // when the visitor's connection is https, so the decision rides on the
-// forwarded protocol the Worker sets (`x-forwarded-proto`); `trustProxy`
-// opts that header in (the framework refuses the attacker-forgeable header
-// otherwise). Direct dev / e2e connections have no forwarded header and a
-// non-encrypted socket, so this returns false there and the bare-named,
-// non-Secure cookie is emitted (a real browser drops a Secure cookie over
-// http, so the bare name is what keeps dev/e2e sessions working).
+// forwarded protocol the Worker sets (`x-forwarded-proto`). Resolution is
+// delegated to the shared securityMiddleware.resolveProtocol so this Secure-
+// cookie decision uses the SAME proxy-trust model as the HSTS + csrf gates
+// (blamejs 0.15.14 refuses a bare `trustProxy`; the resolver owns the
+// header read, sound because the container has no public ingress). Direct
+// dev / e2e connections have no forwarded header and a non-encrypted socket,
+// so this returns false there and the bare-named, non-Secure cookie is
+// emitted (a real browser drops a Secure cookie over http, so the bare name
+// is what keeps dev/e2e sessions working).
 function _secureForReq(req) {
-  return b.requestHelpers.requestProtocol(req, { trustProxy: true }) === "https";
+  return securityMiddleware.resolveProtocol(req) === "https";
 }
 
 // Resolve the on-wire name for one of the prefix-hardened cookies. Secure