@blamejs/blamejs-shop 0.4.75 → 0.4.77

package/CHANGELOG.md

@@ -8,6 +8,10 @@ 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.
 
 - v0.4.74 (2026-06-21) — **Sign-in links are built from the configured origin, and signing out invalidates every device's session.** Two account-security hardenings. The passwordless sign-in (magic) link was assembled from the request's Host header, so a request that reached the app carrying a forged Host could produce a link pointing at another domain while still carrying the customer's single-use sign-in token. The link is now built from the operator-configured trusted origin — the same source the referral links, back-in-stock links, and the OAuth redirect already use — so the link always points at the real storefront regardless of the request Host. Separately, signing out cleared the session cookie only in the responding browser; because the sealed auth cookie is stateless for its full lifetime, a copy captured before sign-out stayed valid until it naturally expired. Explicit sign-out now moves the account's server-side session-revocation boundary forward, so every live session cookie for the account is invalidated at once. **Fixed:** *Magic-link sign-in URLs are built from the configured origin, not the request Host* — The passwordless sign-in link and the post-checkout account-claim link now derive their origin from the operator's configured trusted origin first, falling back to the request origin only when none is configured (single-host dev). A forged Host header can no longer redirect a credential-bearing sign-in link to another domain. Both email-link sends share one origin resolver, matching the referral, back-in-stock, and OAuth-redirect discipline. · *Signing out invalidates every live session, not just the current browser* — POST /account/logout now moves the customer's server-side session-revocation boundary forward before clearing the cookie, so every sealed auth cookie issued for the account — including a copy captured on another device or before sign-out — fails its next request and signs out. Previously the stateless cookie was only cleared in the responding browser and remained valid elsewhere for its full lifetime.

package/lib/asset-manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "0.4.75",
+  "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/customers.js

@@ -228,6 +228,36 @@ function create(opts) {
       };
     },
 
+    // Create an account AND enroll its first passkey as one logical unit.
+    // The passwordless register-finish flow defers account creation to a
+    // verified WebAuthn ceremony; creating the customer and the credential
+    // must not split, or a passkey-insert failure (transient write error, a
+    // duplicate credential id) would leave an empty, credential-less account
+    // behind — re-creating the very email-squat the deferred flow prevents.
+    // D1 has no interactive transaction, so this composes register +
+    // addPasskey and COMPENSATES by deleting the just-created row when the
+    // enroll fails. The new row has no related data yet (no passkey, oauth,
+    // cart, or order), so the delete is clean and frees the email again.
+    registerWithPasskey: async function (input) {
+      if (!input || typeof input !== "object") {
+        throw new TypeError("customers.registerWithPasskey: input object required");
+      }
+      if (!input.passkey || typeof input.passkey !== "object") {
+        throw new TypeError("customers.registerWithPasskey: passkey object required");
+      }
+      var customer = await api.register({ email: input.email, display_name: input.display_name });
+      var passkey;
+      try {
+        passkey = await api.addPasskey(customer.id, input.passkey);
+      } catch (e) {
+        try {
+          await query("DELETE FROM customers WHERE id = ?1", [customer.id]);
+        } catch (_eDel) { /* best-effort compensation — rethrow the real cause below */ }
+        throw e;
+      }
+      return { customer: customer, passkey: passkey };
+    },
+
     get: async function (id) {
       _uuid(id, "customer id");
       var r = await query("SELECT * FROM customers WHERE id = ?1", [id]);

package/lib/storefront.js

@@ -9682,6 +9682,14 @@ var _NOOP_BINDING_STORE = {
   set: function () { return undefined; },
   del: function () { return undefined; },
 };
+// Fixed decoy customer id for passkey login-begin timing parity. A valid v4
+// UUID (passes guardUuid strict) whose 122 random bits are fixed to a value
+// that can never collide with a real randomly-generated customer id, so a
+// listPasskeys lookup against it always returns empty while costing the same
+// query a real account's lookup costs — closing the account-existence timing
+// oracle on /account/passkey/login-begin.
+var _LOGIN_ENUM_DECOY_ID = "5ec0de00-0000-4000-8000-deadbeef0000";
+
 var _deviceBinding = null;
 function _deviceBindingInstance() {
   if (!_deviceBinding) {
@@ -16215,9 +16223,10 @@ function mount(router, deps) {
         // sign-in. An owner adding another passkey uses the session-gated
         // /account/passkey/add-* flow; a passwordless owner — or one whose
         // first ceremony was interrupted — signs in with the magic-link.
-        var existing = await deps.customers.byEmailHash(
-          deps.customers.hashEmail(body.email),
-        );
+        // Validate + hash the address (a malformed email throws TypeError →
+        // 400 via the outer catch) and refuse any existing account up front.
+        var regEmailHash = deps.customers.hashEmail(body.email);
+        var existing = await deps.customers.byEmailHash(regEmailHash);
         if (existing) {
           res.status(409);
           res.setHeader && res.setHeader("content-type", "application/json");
@@ -16227,31 +16236,31 @@ function mount(router, deps) {
           });
           return res.end ? res.end(dupMsg) : res.send(dupMsg);
         }
-        var customer = await deps.customers.register({
-          email:        body.email,
-          display_name: body.display_name,
-        });
+        // SECURITY: do NOT persist a customer row here. Creating the account
+        // before the WebAuthn ceremony completes let an abandoned begin — or a
+        // scripted begin flood — squat an email (the 409 above then blocks the
+        // real owner's registration) and mint junk customer rows. The pending
+        // signup rides in the sealed, tamper-proof challenge cookie instead;
+        // the row is created only on a verified register-finish, where
+        // customers.register re-checks the duplicate atomically to close the
+        // begin→finish race. userDisplayName is the cosmetic authenticator
+        // label only — register() is the authoritative display_name validator.
         var startOpts = await b.auth.passkey.startRegistration({
           rpName:           rpName,
           rpId:             rpId,
-          userName:         customer.email_hash.slice(0, 16),
-          userDisplayName:  customer.display_name,
+          userName:         regEmailHash.slice(0, 16),
+          userDisplayName:  (typeof body.display_name === "string" ? body.display_name : ""),
           attestationType:  "none",
         });
-        // Seal the ceremony state (challenge + customer_id) into the
-        // shop_auth_chal cookie so register-finish verifies against
-        // the same challenge without server-side state.
+        // Seal the pending signup (challenge + email + display name) into the
+        // shop_auth_chal cookie so register-finish verifies against the same
+        // challenge and creates the account without server-side state.
         _setChallengeCookie(res, {
-          kind:           "register",
-          customer_id:    customer.id,
-          challenge:      startOpts.challenge,
-          created_at:     Date.now(),
-          // Whether THIS begin created the customer (vs reused an existing
-          // row for a known email). register-finish gates referral
-          // attribution on it — an existing customer re-enrolling a passkey
-          // through a referral link must not be attributed to a referrer
-          // (it isn't a new signup), mirroring the OIDC `rv.created` gate.
-          is_new:         !existing,
+          kind:              "register",
+          reg_email:         body.email,
+          reg_display_name:  body.display_name,
+          challenge:         startOpts.challenge,
+          created_at:        Date.now(),
         });
         res.status(200);
         res.setHeader && res.setHeader("content-type", "application/json");
@@ -16292,28 +16301,82 @@ function mount(router, deps) {
         if (att.response && Array.isArray(att.response.transports)) {
           transports = att.response.transports.filter(function (t) { return /^[a-z]+$/.test(t); }).join(",");
         }
-        await deps.customers.addPasskey(env.customer_id, {
+        var passkeyInput = {
           credential_id: credentialId,
           public_key:    publicKey,
           counter:       info.counter || 0,
           transports:    transports,
-        });
-        _clearChallengeCookie(res);
-        _setAuthCookie(req, res, {
-          customer_id: env.customer_id,
-          exp:         Date.now() + b.constants.TIME.days(14),
-        });
-        // Attribute this signup to a referrer if the visitor arrived
-        // through a /r/<code> link — ONLY for a genuinely new account
-        // (env.is_new, stamped in register-begin). An existing customer
-        // re-enrolling a passkey is not a new signup and must never be
-        // attributed (that would let an existing user mint referral
-        // credit by following their own/a friend's link), matching the
-        // OIDC `rv.created` gate. Best-effort; never blocks the ceremony.
-        if (env.is_new === true) {
-          await _attributeReferral(req, res, env.customer_id);
+        };
+        var customerId;
+        if (env.reg_email) {
+          // New deferred flow: create the account AND enroll the credential as
+          // one unit — registerWithPasskey rolls the new row back if the
+          // enroll fails, so a transient write error can't leave an empty,
+          // squattable account behind. register() validates the email +
+          // display name and atomically refuses a duplicate, so a racing
+          // second ceremony (or an account created between this begin and
+          // finish) loses here rather than double-creating. Creating the row
+          // only after a verified attestation is what stops an abandoned or
+          // scripted register-begin from squatting an email.
+          var created;
+          try {
+            created = await deps.customers.registerWithPasskey({
+              email:        env.reg_email,
+              display_name: env.reg_display_name,
+              passkey:      passkeyInput,
+            });
+          } catch (e) {
+            if (e && e.code === "CUSTOMER_DUPLICATE") {
+              _clearChallengeCookie(res);
+              res.status(409);
+              res.setHeader && res.setHeader("content-type", "application/json");
+              var dupFin = JSON.stringify({
+                error:   "account_exists",
+                message: "An account with this email already exists. Sign in instead.",
+              });
+              return res.end ? res.end(dupFin) : res.send(dupFin);
+            }
+            if (e instanceof TypeError) {
+              _clearChallengeCookie(res);
+              res.status(400);
+              return res.end ? res.end((e && e.message) || "registration refused") : res.send((e && e.message) || "registration refused");
+            }
+            throw e;
+          }
+          customerId = created.customer.id;
+          _clearChallengeCookie(res);
+          _setAuthCookie(req, res, {
+            customer_id: customerId,
+            exp:         Date.now() + b.constants.TIME.days(14),
+          });
+          // A verified deferred register-finish always lands a genuinely new
+          // account, so attribute the signup to a referrer when the visitor
+          // arrived through a /r/<code> link. Best-effort; never blocks.
+          await _attributeReferral(req, res, customerId);
+        } else if (env.customer_id) {
+          // Legacy challenge cookie minted by the previous (pre-defer)
+          // register-begin, still in flight across a rolling deploy: that
+          // begin already created the customer row, so enroll the credential
+          // onto it (the prior finish behavior) and gate referral attribution
+          // on the begin-stamped is_new exactly as before. This branch only
+          // matches cookies issued before this version shipped; it ages out
+          // with the challenge cookie's TTL.
+          await deps.customers.addPasskey(env.customer_id, passkeyInput);
+          customerId = env.customer_id;
+          _clearChallengeCookie(res);
+          _setAuthCookie(req, res, {
+            customer_id: customerId,
+            exp:         Date.now() + b.constants.TIME.days(14),
+          });
+          if (env.is_new === true) {
+            await _attributeReferral(req, res, customerId);
+          } else {
+            try { _clearReferralCookie(res); } catch (_e) { /* best-effort */ }
+          }
         } else {
-          try { _clearReferralCookie(res); } catch (_e) { /* best-effort */ }
+          _clearChallengeCookie(res);
+          res.status(400);
+          return res.end ? res.end("bad challenge") : res.send("bad challenge");
         }
         res.status(200);
         return res.end ? res.end("ok") : res.send("ok");
@@ -16345,9 +16408,17 @@ function mount(router, deps) {
         // challenge with an empty allowCredentials list — the client
         // can't distinguish "no such address" from "wrong passkey",
         // protecting against email-enumeration.
+        //
+        // Timing parity: a real account ran a second query (listPasskeys)
+        // that a non-existent address skipped, leaving a measurable
+        // response-time delta that re-introduced an account-existence
+        // oracle. Run the same lookup on both paths — against the real id
+        // for an existing account, against a fixed non-matching decoy id
+        // (a valid v4 UUID that can never collide with a random customer
+        // id) otherwise — so the work, and the timing, match.
         var allow = [];
+        var pks = await deps.customers.listPasskeys(customer ? customer.id : _LOGIN_ENUM_DECOY_ID);
         if (customer) {
-          var pks = await deps.customers.listPasskeys(customer.id);
           allow = pks.map(function (p) {
             return {
               id:         p.credential_id,
@@ -16720,6 +16791,16 @@ function mount(router, deps) {
         if (auth && auth.customer_id && deps.customers &&
             typeof deps.customers.revokeSessionsForCustomer === "function") {
           await deps.customers.revokeSessionsForCustomer(auth.customer_id);
+          // Also revoke any pending customer-portal token (an unredeemed
+          // magic link issued before sign-out). Bumping the cookie boundary
+          // kills live sealed cookies, but a pending portal token is a
+          // separate credential that would otherwise still redeem after a
+          // sign-out-everywhere. Best-effort + drop-silent.
+          try {
+            if (deps.customerPortal && typeof deps.customerPortal.revokeAllForCustomer === "function") {
+              await deps.customerPortal.revokeAllForCustomer(auth.customer_id, "sign-out");
+            }
+          } catch (_ePortal) { /* drop-silent — best-effort pending-token teardown */ }
         }
       } catch (_eRev) { /* drop-silent — the cookie clear below still signs out this browser */ }
       // Wipe the browser's client-side state for the origin on sign-out
@@ -16868,6 +16949,35 @@ function mount(router, deps) {
         if (e instanceof TypeError) return _renderPasskeysPage(req, res, auth, (e && e.message) || "Could not revoke that passkey.", 400);
         throw e;
       }
+      // Revoking a passkey is a security action — the authenticator may be
+      // lost or compromised. Deleting the credential stops it minting a NEW
+      // session, but the sealed auth cookie is stateless for its 14-day TTL,
+      // so a copy captured before the revoke (e.g. a session the compromised
+      // authenticator established) stays live unless we move the server-side
+      // revocation boundary forward now. We then RE-MINT this browser's auth
+      // cookie with an `iat` at the new boundary, so the trusted device
+      // actively performing the revoke stays signed in while every OTHER live
+      // cookie — older `iat`, behind the boundary — dies on its next request
+      // ("sign out other sessions"). Also revoke every pending customer-portal
+      // token (an unredeemed magic link issued before the revoke) so the
+      // compromise can't be re-entered through a still-valid link.
+      // Best-effort + drop-silent: a failed teardown must not leave the
+      // customer staring at a 500 after the credential is already gone.
+      try {
+        var rev = await deps.customers.revokeSessionsForCustomer(auth.customer_id);
+        var boundary = (rev && rev.sessions_valid_from) || Date.now();
+        // Keep the current (trusted) session alive across the boundary bump.
+        _setAuthCookie(req, res, {
+          customer_id: auth.customer_id,
+          iat:         boundary,
+          exp:         Date.now() + b.constants.TIME.days(14),
+        });
+      } catch (_eRev) { /* drop-silent — credential is gone; boundary bump is defense-in-depth */ }
+      try {
+        if (deps.customerPortal && typeof deps.customerPortal.revokeAllForCustomer === "function") {
+          await deps.customerPortal.revokeAllForCustomer(auth.customer_id, "passkey-revoke");
+        }
+      } catch (_ePortal) { /* drop-silent — best-effort pending-token teardown */ }
       res.status(303); res.setHeader && res.setHeader("location", "/account/passkeys?ok=revoked");
       return res.end ? res.end() : res.send("");
     });

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.75",
+  "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": {