@blamejs/blamejs-shop 0.4.75 → 0.4.76

package/CHANGELOG.md

@@ -8,6 +8,8 @@ upgrading across more than a few patches at a time.
 
 ## v0.4.x
 
+- 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.76",
   "assets": {
     "css/admin.css": {
       "integrity": "sha384-imfe0otYErcB8rr2h6KLSGTtStirysptpXETSPY4zLv3bZoIT75Lo1dOvkOav+xL",

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/package.json

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