@blamejs/blamejs-shop 0.4.76 → 0.4.77

package/CHANGELOG.md

@@ -8,6 +8,8 @@ upgrading across more than a few patches at a time.
 
 ## v0.4.x
 
+- v0.4.77 (2026-06-21) — **Exactly-once hardening for payment capture, auto-replenishment, gift redemption, and carrier-credential rotation.** Four correctness fixes that make money- and inventory-moving state transitions happen exactly once under concurrency or delayed settlement. A PayPal order is no longer marked paid when the capture itself is still pending — settlement is now read from the capture status, not the order envelope, so a delayed or under-review payment leaves the order pending until funds actually settle. Overlapping auto-replenishment ticks can no longer both fire the same policy: the cadence advance is now an atomic claim, so a vendor purchase order is composed and submitted once per window instead of being double-cut. Redeeming one gift-subscription link twice — two clicks racing within milliseconds — now mints exactly one subscription: the redemption claims the gift before creating the subscription, and rolls the claim back if the mint fails. And two carrier-credential rotations firing at once can no longer both commit; the rotation now compare-and-swaps on the observed key, so the loser is refused instead of clobbering the winner's fresh key and stranding the previous-key grace window. No configuration changes; upgrade to pick them up. **Fixed:** *A PayPal order is marked paid only when the capture itself completes* — Capturing a PayPal order now gates the paid transition on the per-capture status rather than the order envelope. The order-level status can read COMPLETED while the capture is still PENDING (a delayed-settlement or under-review payment), which previously marked the order paid before the money settled. Any non-completed capture now leaves the order pending and reports the capture as unhandled so the checkout surfaces the unsettled state. · *Overlapping auto-replenishment ticks no longer double-submit a purchase order* — The replenishment scheduler advances a policy's run cadence with a single conditional claim that is the serialization point: two ticks firing at once contend on the policy row, only one matches the due-window predicate, and the vendor purchase order is composed and submitted exactly once per window. Previously the cadence was an in-memory check followed by an unconditional stamp, so two overlapping ticks both passed the check and cut duplicate POs. · *Redeeming a gift-subscription link twice creates exactly one subscription* — Gift redemption now claims the gift's pending→redeemed transition before creating the recipient's subscription, and only the winner of that atomic claim mints. A leaked or double-clicked redemption link presented twice within milliseconds therefore creates one subscription, not two; if the subscription mint then fails, the claim is rolled back so the gift can be redeemed again rather than being stranded as redeemed-with-no-subscription. · *Concurrent carrier-credential rotations no longer over-issue or strand credentials* — Rotating a shipping-carrier account's API credentials now compare-and-swaps on the observed key and account state, so two rotations firing at once can't both commit. The loser is refused with a rotation-conflict error instead of overwriting the winner's freshly minted key and leaving the previous-key grace window pointing at a key no deployed worker holds.
+
 - v0.4.76 (2026-06-21) — **Account security hardening — revoking a passkey ends the account's other sessions, and registration no longer creates an account before the security key is enrolled.** Four hardenings on the customer account surface. Revoking a passkey now ends every other live session for the account — including pending magic-link sign-in tokens — while keeping the device that performed the revoke signed in; previously the credential was deleted but a sealed session cookie a lost or compromised authenticator had already established stayed valid for its full 14-day life. Signing out everywhere now also revokes any unredeemed magic-link token, so a link mailed before sign-out can no longer sign the account back in. Passkey registration no longer creates the customer record until the security-key ceremony actually completes: the pending sign-up is carried in the sealed challenge cookie and the account is created only on a verified finish, so an abandoned or scripted registration can no longer reserve an email address or leave empty accounts behind. And passkey sign-in performs the same credential lookup whether or not the address has an account, removing a response-time difference that could be used to test which emails are registered. No configuration changes; upgrade to pick them up. **Security:** *Revoking a passkey ends the account's other sessions and pending sign-in links* — Revoking a passkey is a response to a lost or compromised authenticator, so it now moves the account's server-side session-revocation boundary forward — invalidating every sealed auth cookie issued before the revoke, including one the compromised authenticator established — and revokes any pending customer-portal (magic-link) token. The browser that performed the revoke is re-issued a fresh cookie so it stays signed in; every other device is signed out on its next request. Previously only the credential row was deleted, leaving already-issued session cookies valid for their full 14-day life. · *Signing out everywhere also revokes pending magic-link tokens* — POST /account/logout already moved the session-revocation boundary forward to kill live sealed cookies; it now also revokes any unredeemed magic-link / customer-portal token for the account. An emailed sign-in link issued before the sign-out can no longer be redeemed to sign the account back in. · *Passkey registration creates the account only after the security key is enrolled* — The public passkey register-begin endpoint no longer writes a customer record before the WebAuthn ceremony completes. The pending sign-up (email + display name + challenge) is sealed into the tamper-proof challenge cookie, and the account is created only on a verified register-finish, where the duplicate-email check runs atomically to settle a begin/finish race. An abandoned or scripted register-begin can no longer reserve (squat) an email address or leave behind empty accounts. · *Passkey sign-in does not reveal whether an email is registered via timing* — Passkey login-begin now runs the same credential lookup on both paths — against the real account for a registered address, against a fixed non-matching id otherwise — so a registered address no longer takes measurably longer to respond. The challenge response shape was already identical on both paths; this closes the remaining response-time signal that could enumerate registered emails.
 
 - v0.4.75 (2026-06-21) — **Bundled framework refreshed to blamejs 0.15.15 — more authentication checks fail closed and a blocked-traffic memory leak is fixed.** Refreshes the vendored framework the store is built on from blamejs 0.15.14 to 0.15.15, a correctness-and-hardening release. The protections the store already composes now refuse more malformed or unbound credentials, and a request-pipeline leak under sustained blocked traffic is fixed. The most directly felt change for an operator: when the bot guard, rate limiter, or CSRF check halts a request by writing its response without continuing the chain, the pipeline now settles instead of holding the request closure open forever — under a flood of blocked requests that previously grew memory without bound. On the sign-in surface, the passkey, OAuth, and any token verifiers the store routes through inherit stricter checks: an OAuth ID-token nonce is no longer skipped when empty, an authenticator's current certification status is honored rather than the highest it ever held, a JWT issuer presented as an array no longer satisfies a single-issuer expectation, and a malformed JOSE header raises a typed error instead of crashing the verifier. The content-security-policy builder now refuses a source value containing whitespace or a semicolon (so a malformed provider host can't smuggle a second directive), the SQL builder refuses an always-false equality against NULL and validates every element of an IN-list, and the WebSocket client bounds a fragmented message as it arrives rather than only at the final frame. No store configuration changes; upgrade to pick up the refreshed framework. **Changed:** *Bundled framework updated to blamejs 0.15.15* — The vendored framework is refreshed from 0.15.14 to 0.15.15. The store carries zero runtime npm dependencies and builds entirely on this bundled framework, so its correctness and hardening improvements apply to the store on upgrade with no configuration change. **Security:** *A blocked request no longer leaks its closure for the life of the process* — When the bot guard, rate limiter, CSRF check, or any middleware halts a request by writing the response without advancing the chain — the intended way to block — the request pipeline now settles its promise instead of leaving it pending forever. Previously each blocked request retained its request/response closure, so sustained blocked traffic grew memory without bound. The store's request lifecycle composes this pipeline directly, so the fix applies to every blocked request. · *Sign-in credential verifiers fail closed on more malformed inputs* — The authentication primitives the store routes sign-in through now refuse more unbound or malformed credentials: an OAuth ID-token nonce check is no longer skipped when the supplied nonce is empty, an authenticator's current certification status is honored over the highest level it ever held, a JWT issuer presented as an array no longer satisfies a single-issuer expectation, and a JOSE header or payload that decodes to a non-object raises a typed authentication error instead of an uncaught crash. · *The content-security-policy builder refuses a directive-injecting source* — A CSP source is a single non-whitespace token; the builder now rejects a source containing whitespace or a semicolon. Because sources are space-joined and directives semicolon-joined, a malformed value could otherwise have injected a second, live directive. The store's provider hosts (payment, captcha) are already clean single tokens, so this is defense against a future misconfiguration. · *The SQL builder refuses an always-false NULL equality and validates IN-list elements* — An equality against NULL (always false in SQL; the IS NULL form is required) is now refused rather than silently matching nothing, and every element of an IN-list is validated across all database backends. This narrows the room for a query that quietly returns the wrong rows. · *WebSocket fragmented-message reassembly is bounded as it arrives* — A fragmented incoming message is now bounded by its running total on each frame instead of only when the final frame arrives, so a peer can no longer stream unbounded continuation frames to exhaust memory before the size limit is checked, and a frame arriving after close is ignored.

package/lib/asset-manifest.json

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

package/lib/auto-replenish.js

@@ -757,9 +757,20 @@ function create(opts) {
       for (var i = 0; i < rows.length; i += 1) {
         var policy = _shapePolicy(rows[i]);
         var interval = SCHEDULE_INTERVAL_MS[policy.schedule];
-        if (policy.last_run_at != null && (now - policy.last_run_at) < interval) {
-          continue;
-        }
+        // Atomic cadence claim — the serialization point. Advancing
+        // last_run_at in a single conditional UPDATE (rather than an
+        // in-memory comparison followed by an unconditional stamp) means two
+        // overlapping ticks contend on the same row: only one UPDATE matches
+        // the "due" predicate, the loser changes zero rows and skips the
+        // policy, so the vendor PO is composed and submitted exactly once per
+        // cadence window. A null last_run_at fires immediately.
+        var claim = await query(
+          "UPDATE auto_replenish_policies SET last_run_at = ?1, updated_at = ?1 " +
+          "WHERE slug = ?2 AND archived_at IS NULL " +
+          "AND (last_run_at IS NULL OR last_run_at <= ?3)",
+          [now, policy.slug, now - interval],
+        );
+        if (Number(claim.rowCount || 0) !== 1) continue;   // lost the claim / not yet due
         var runRow = await _runPolicyOnce(policy, now);
         summaries.push(_shapeRun(runRow));
       }

package/lib/carrier-accounts.js

@@ -577,13 +577,31 @@ function create(opts) {
       var prevHash  = current.api_key_hash;
       var now       = _now();
 
-      await query(
+      // Atomic compare-and-swap on the OBSERVED key + state. The JS guard
+      // above is a fast-fail; this predicate is the authoritative gate, so two
+      // concurrent rotations can't both commit. The loser observed the same
+      // api_key_hash but its UPDATE no longer matches (the winner already moved
+      // the key), changes zero rows, and refuses — preventing an over-issue
+      // where the second rotation clobbers the winner's fresh key and strands
+      // api_key_previous_hash pointing at a key no deployed worker holds.
+      var claim = await query(
         "UPDATE carrier_accounts SET api_key_hash = ?1, " +
         "api_key_previous_hash = ?2, api_secret_hash = ?3, " +
         "status = 'rotating', rotated_at = ?4, updated_at = ?5 " +
-        "WHERE id = ?6",
-        [hashKey, prevHash, hashSec, now, now, id],
+        "WHERE id = ?6 AND status IN ('active','rotating') AND api_key_hash = ?7",
+        [hashKey, prevHash, hashSec, now, now, id, prevHash],
       );
+      if (Number(claim.rowCount || 0) !== 1) {
+        var lost = await _getRaw(id);
+        var conflict = new Error(
+          (lost && lost.status === "disabled")
+            ? "carrier-accounts.rotateCredentials: refused — account is disabled"
+            : "carrier-accounts.rotateCredentials: refused — a concurrent rotation won the claim"
+        );
+        conflict.code = (lost && lost.status === "disabled")
+          ? "CARRIER_ACCOUNT_DISABLED" : "CARRIER_ACCOUNT_ROTATION_CONFLICT";
+        throw conflict;
+      }
 
       var projected = _project(await _getRaw(id));
       projected.plaintext = {

package/lib/checkout.js

@@ -1976,8 +1976,16 @@ function create(deps) {
       var cap = await paypal.captureOrder(paypalOrderId);
       var captureId = null;
       try { captureId = cap.purchase_units[0].payments.captures[0].id; } catch (_e) { captureId = null; }
-      var completed = cap && (cap.status === "COMPLETED" ||
-        (captureId && cap.purchase_units[0].payments.captures[0].status === "COMPLETED"));
+      // Settlement is a property of the CAPTURE, not the order envelope. The
+      // order-level `cap.status` can read COMPLETED while the capture itself is
+      // still PENDING (e.g. an under-review / delayed-settlement payment), so
+      // gating on the order status would mark the order paid before funds
+      // settle. Gate solely on the per-capture status; any non-COMPLETED
+      // capture (PENDING / DECLINED / FAILED) leaves the order `pending` and
+      // returns handled:false so the route can surface the unsettled state.
+      var captureStatus = null;
+      try { captureStatus = cap.purchase_units[0].payments.captures[0].status; } catch (_e3) { captureStatus = null; }
+      var completed = captureStatus === "COMPLETED";
       if (completed && o.status === "pending") {
         // Persist the capture id on the order row — refunds dial
         // /v2/payments/captures/<capture-id>/refund, NOT the PayPal order id

package/lib/subscription-gifts.js

@@ -455,23 +455,20 @@ function create(opts) {
         gifted_by:            existing.giver_customer_id,
       },
     };
-    var created = await subscriptionsHandle.create(createInput);
-    if (!created || typeof created !== "object" || typeof created.id !== "string" || !created.id.length) {
-      throw new Error("subscriptionGifts.redeemGift: subscriptions.create must return an object with a string id");
-    }
-    var subscriptionId = created.id;
-
-    // FSM transition: pending|delivered -> redeemed. Guarded by the
-    // current status so a concurrent redeem (token leaked + presented
-    // twice within ms) refuses cleanly.
-    var r = await query(
-      "UPDATE subscription_gifts SET status = 'redeemed', redeemed_at = ?1, redeemed_subscription_id = ?2 " +
-      "WHERE id = ?3 AND status IN ('pending','delivered')",
-      [now, subscriptionId, existing.id],
+    // FSM transition FIRST — the atomic claim must gate the irreversible
+    // subscription mint, not trail it. Claim pending|delivered -> redeemed in
+    // one conditional UPDATE; only the winner (rowCount===1) goes on to mint.
+    // A concurrent redeem of the same token loses the claim, mints nothing,
+    // and refuses cleanly — so a leaked link presented twice can never
+    // double-create subscriptions. The subscription id is backfilled after the
+    // mint succeeds.
+    var claim = await query(
+      "UPDATE subscription_gifts SET status = 'redeemed', redeemed_at = ?1, redeemed_subscription_id = NULL " +
+      "WHERE id = ?2 AND status IN ('pending','delivered')",
+      [now, existing.id],
     );
-    if (Number(r.rowCount || 0) === 0) {
-      // Lost the race — re-read so we surface the actual post-race
-      // status to the caller.
+    if (Number(claim.rowCount || 0) !== 1) {
+      // Lost the race — re-read so we surface the actual post-race status.
       var after = await _getRaw(existing.id);
       var raceErr = new Error(
         "subscriptionGifts.redeemGift: gift status changed to '" +
@@ -480,6 +477,36 @@ function create(opts) {
       raceErr.code = "SUBSCRIPTION_GIFT_ALREADY_REDEEMED";
       throw raceErr;
     }
+
+    // Winner-only mint. If create() fails (or returns a bad shape), revert the
+    // claim so the gift can be redeemed again — nothing was minted, and the
+    // gift must not be stranded in 'redeemed' with no subscription.
+    function _revertClaim() {
+      return query(
+        "UPDATE subscription_gifts SET status = ?1, redeemed_at = NULL, redeemed_subscription_id = NULL " +
+        "WHERE id = ?2 AND status = 'redeemed' AND redeemed_subscription_id IS NULL",
+        [status, existing.id],
+      );
+    }
+    var created;
+    try {
+      created = await subscriptionsHandle.create(createInput);
+    } catch (e) {
+      await _revertClaim();
+      throw e;
+    }
+    if (!created || typeof created !== "object" || typeof created.id !== "string" || !created.id.length) {
+      await _revertClaim();
+      throw new Error("subscriptionGifts.redeemGift: subscriptions.create must return an object with a string id");
+    }
+    var subscriptionId = created.id;
+
+    // Backfill the minted subscription id onto the already-claimed row.
+    await query(
+      "UPDATE subscription_gifts SET redeemed_subscription_id = ?1 " +
+      "WHERE id = ?2 AND status = 'redeemed' AND redeemed_subscription_id IS NULL",
+      [subscriptionId, existing.id],
+    );
     return {
       gift:            _hydrateGift(await _getRaw(existing.id)),
       subscription_id: subscriptionId,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blamejs/blamejs-shop",
-  "version": "0.4.76",
+  "version": "0.4.77",
   "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": {