@blamejs/blamejs-shop 0.4.126 → 0.4.128

package/CHANGELOG.md

@@ -8,6 +8,10 @@ upgrading across more than a few patches at a time.
 
 ## v0.4.x
 
+- v0.4.128 (2026-06-27) — **Email sign-in links are now rate-limited per recipient, bounding inbox-flood and token-minting abuse.** The email magic-link sign-in — the no-passkey backup on the login screen — minted a new single-use sign-in token and sent an email on every POST for a registered address, bounded only by the per-IP request limiter. An attacker submitting a victim's address from many IP addresses could therefore flood that inbox with sign-in links and mint an unbounded number of valid single-use tokens. The route now applies a per-recipient cooldown: at most one sign-in link (and one minted token) per registered address per minute. The cooldown runs after the unchanged, enumeration-safe confirmation response, so a registered and an unregistered address stay indistinguishable by the reply; a transient lookup failure falls through to sending, keeping availability ahead of the rate cap. **Fixed:** *Email sign-in links are rate-limited per recipient* — Requesting an email sign-in link minted a single-use portal token and sent a message every time it was submitted for a registered address, with only the per-IP limiter in front of it — which a distributed sender (many IPs, one victim address) sails past. The request now checks whether a sign-in link was already minted for that account within the last minute and, if so, sends nothing further. The check runs on the request's background path, after the identical confirmation response is returned, so it does not reintroduce an account-existence oracle (a registered and an unregistered address still get the same reply at the same speed); an address with no account still triggers no mint or send at all. A transient failure of the cooldown lookup falls through to sending, so a degraded datastore can't lock legitimate shoppers out of signing in.
+
+- v0.4.127 (2026-06-27) — **Customer-segment-restricted automatic discounts now work instead of breaking the discount quote for signed-in shoppers.** An automatic-discount rule limited to a customer segment (for example a members-only offer) never functioned: the discount engine was constructed without the customer-segments handle it needs to test membership, so the moment any segment-restricted rule existed, computing the cart and checkout discount threw an error for every signed-in shopper — breaking the discount quote for authenticated customers — while the discount applied to no one. Guests were unaffected because a segment rule is skipped for a shopper with no account. The engine is now wired with the segments handle, so a segment-restricted rule correctly applies to shoppers who are in the segment, is skipped for shoppers who are not, and is skipped for guests; rules that are not segment-restricted are entirely unaffected. **Fixed:** *Customer-segment-restricted automatic discounts apply correctly and no longer break the quote* — The automatic-discount engine is now created with the customer-segments handle. Previously the storefront and checkout wired the engine without it, so evaluating a rule carrying a customer-segment restriction threw the moment a signed-in shopper reached the cart or checkout — the discount engine requires the handle to answer "is this customer in the segment?" and had none. The result was that a segment-restricted offer applied to nobody and broke the discount calculation for every authenticated shopper whenever such a rule was active. With the handle wired, a segment-restricted rule applies to shoppers in the segment, is cleanly skipped for shoppers outside it and for guests, and rules without a segment restriction behave exactly as before.
+
 - v0.4.126 (2026-06-27) — **Storefront error responses no longer echo internal error detail, and order/account pages render images from the configured asset prefix.** Two storefront correctness fixes. First, around fifteen storefront routes (cart line edit/remove, product compare, saved-for-later, account actions and more) returned the raw error message to the client on an unexpected server error — a string that can carry an internal database column, a vault/crypto detail, or other implementation internals. Those routes now distinguish a client-shape validation error (a 400 that still shows its operator-authored message) from an unexpected server error (a 500 that logs the real error server-side, correlated by the request id, and returns only a generic message plus that id) — the same redaction the WebAuthn ceremony routes already used. Second, the order-detail and account-dashboard pages were rendering product thumbnails from the default "/assets/" path instead of the operator's configured asset prefix, so on a deployment that serves assets from a CDN or object-store prefix those two pages showed broken images; both pages now pass the configured prefix like every other page. **Fixed:** *Storefront routes no longer echo the internal error message on a 500* — About fifteen storefront routes — cart line update/remove, product-compare add/clear, saved-for-later move/remove, and several account actions — handled a caught error with `status(TypeError ? 400 : 500)` and then returned the raw error message for both cases, so an unexpected (non-validation) server error sent its internal message string to the client. These routes now return that message only for a client-shape validation error (a 400); any other error is a 500 that records the real error server-side against the request id and returns a generic "Something went wrong" message plus that id for support correlation. This matches the redaction the WebAuthn register/login routes already applied. · *Order-detail and account pages render images from the configured asset prefix* — The order-detail (`/orders/:id`) and account-dashboard (`/account`) renderers were not passed the configured asset prefix, so they fell back to the default `/assets/` path for product thumbnails while every other page used the operator's prefix. On a deployment that serves static assets from a CDN or object-store prefix, those two pages showed broken images. Both now pass the configured prefix, so their images load from the same place as the rest of the storefront.
 
 - v0.4.125 (2026-06-27) — **Vendored framework refreshed to 0.15.34 — RSA OpenPGP signatures with a high zero byte now verify reliably.** Updates the vendored blamejs framework to 0.15.34. The upstream release fixes the framework's OpenPGP verification: an RSA signature whose value began with one or more zero bytes — about 1 in 256 of all signatures, for any key — was rejected as invalid even though it was correct, because the OpenPGP wire format strips those leading zero bytes and the verifier handed the shortened signature straight to RSA verification (which requires the signature to be exactly the key's modulus length). The signature is now left-padded back to the modulus width before verification, so every valid RSA signature verifies reliably, including signatures produced by other OpenPGP implementations. The release also carries internal test-suite tooling with no runtime effect. **Changed:** *Vendored framework refreshed to 0.15.34 (reliable RSA OpenPGP signature verification)* — Refreshes the vendored blamejs framework to 0.15.34. The upstream fix left-pads an RSA OpenPGP signature back to the key's modulus byte length before verifying it, so a valid signature whose value carried one or more leading zero bytes (~1 in 256, for any key) is no longer intermittently rejected — matching the padding the Ed25519 verification path already applied. Any code path that verifies OpenPGP RSA signatures through the framework now accepts every correct signature. The rest of the release is internal test-suite tooling with no runtime, public-API, or wire-format change.

package/lib/asset-manifest.json

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

package/lib/customer-portal.js

@@ -191,14 +191,44 @@ function create(opts) {
       var now       = _now();
       var expiresAt = now + (ttl * 1000); // allow:raw-time-literal — ttl is a runtime seconds value; *1000 converts to ms
 
-      await query(
-        "INSERT INTO customer_portal_sessions " +
-        "(id, customer_id, token_hash, scope, status, " +
-        " consumed_at, revoked_at, revoke_reason, ip_hash, ua_class, " +
-        " created_at, expires_at) " +
-        "VALUES (?1, ?2, ?3, ?4, 'issued', NULL, NULL, NULL, ?5, ?6, ?7, ?8)",
-        [id, customerId, tokenHash, scope, ipHash, uaClass, now, expiresAt],
-      );
+      // Optional per-customer mint throttle. When `min_interval_seconds` is set,
+      // the session is minted ONLY if no session was created for this customer
+      // within that interval — enforced as ONE conditional statement
+      // (INSERT ... SELECT ... WHERE NOT EXISTS), so concurrent callers can't
+      // each read an empty window before any of them inserts. The public email
+      // sign-in-link route passes this to bound inbox-flood / token-mint abuse
+      // of a registered address; a rowCount of 0 means a recent session already
+      // exists, so this call mints nothing and returns `{ throttled: true }`
+      // (no token). Callers that omit the option mint unconditionally as before.
+      var minInterval = input.min_interval_seconds;
+      if (minInterval != null && (typeof minInterval !== "number" || !isFinite(minInterval) || minInterval < 0)) {
+        throw new TypeError("customer-portal.createSession: min_interval_seconds must be a non-negative number");
+      }
+      if (minInterval) {
+        var sinceMs = now - Math.floor(minInterval * 1000); // allow:raw-time-literal — minInterval is a runtime seconds value; *1000 converts to ms
+        var ins = await query(
+          "INSERT INTO customer_portal_sessions " +
+          "(id, customer_id, token_hash, scope, status, " +
+          " consumed_at, revoked_at, revoke_reason, ip_hash, ua_class, " +
+          " created_at, expires_at) " +
+          "SELECT ?1, ?2, ?3, ?4, 'issued', NULL, NULL, NULL, ?5, ?6, ?7, ?8 " +
+          "WHERE NOT EXISTS (SELECT 1 FROM customer_portal_sessions " +
+          "WHERE customer_id = ?2 AND created_at >= ?9)",
+          [id, customerId, tokenHash, scope, ipHash, uaClass, now, expiresAt, sinceMs],
+        );
+        if (Number(ins.rowCount || 0) === 0) {
+          return { throttled: true };
+        }
+      } else {
+        await query(
+          "INSERT INTO customer_portal_sessions " +
+          "(id, customer_id, token_hash, scope, status, " +
+          " consumed_at, revoked_at, revoke_reason, ip_hash, ua_class, " +
+          " created_at, expires_at) " +
+          "VALUES (?1, ?2, ?3, ?4, 'issued', NULL, NULL, NULL, ?5, ?6, ?7, ?8)",
+          [id, customerId, tokenHash, scope, ipHash, uaClass, now, expiresAt],
+        );
+      }
 
       // The plaintext leaves this function exactly once. The row
       // above is the only durable handle to the session; the hash

package/lib/customer-segments.js

@@ -825,6 +825,25 @@ function create(opts) {
       return out;
     },
 
+    // Membership predicate: is this customer in the named (non-archived)
+    // segment? A single existence check over the same membership join
+    // `segmentsForCustomer` reads — so a caller gating one rule on one segment
+    // doesn't load the customer's whole segment list. This is the handle shape
+    // the autoDiscount engine's `customer_segment_in` gate composes
+    // (`isMember(customer_id, segment_slug) -> Promise<bool>`); a slug that
+    // names no segment (or an archived one) is simply not a member.
+    isMember: async function (customerId, segmentSlug) {
+      _uuid(customerId, "customer_id");
+      var slug = _slug(segmentSlug);
+      var r = await query(
+        "SELECT 1 FROM customer_segment_membership csm " +
+        "JOIN customer_segments cs ON cs.id = csm.segment_id " +
+        "WHERE csm.customer_id = ?1 AND cs.slug = ?2 AND cs.archived_at IS NULL LIMIT 1",
+        [customerId, slug],
+      );
+      return r.rows.length > 0;
+    },
+
     listSegments: async function (listOpts) {
       listOpts = listOpts || {};
       var includeArchived = !!listOpts.include_archived;

package/lib/storefront.js

@@ -10212,6 +10212,14 @@ var ACCOUNT_LOGIN_PAGE =
   "  RAW_LOGIN_SCRIPT\n" +
   "</section>\n";
 
+// Per-recipient cooldown for the email magic-link: at most one sign-in link
+// (and one minted single-use token) per registered address per window. The
+// per-IP limiter doesn't bound a DISTRIBUTED attacker POSTing a victim's
+// address from many IPs, so without this each POST mints a token + sends a
+// mail — an inbox-flood + unbounded-token-mint vector. Enforced AFTER the
+// enumeration-safe 303, so it never changes the response.
+var MAGIC_LINK_RESEND_COOLDOWN_MS = b.constants.TIME.minutes(1);
+
 // The inline email magic-link path on the unified login screen. A distinct
 // server-rendered <form> (its own email field) that POSTs to
 // /account/login/link with no JavaScript — the `_injectCsrfFields` wrap
@@ -16145,10 +16153,22 @@ function mount(router, deps) {
 
         if (customerId) {
           Promise.resolve().then(async function () {
+            // Per-recipient cooldown enforced ATOMICALLY in the mint itself
+            // (createSession with min_interval_seconds is a single conditional
+            // INSERT): at most one sign-in link + one minted token per registered
+            // address per window, even when a distributed attacker fires many
+            // POSTs for the same address concurrently (the per-IP limiter can't
+            // bound that, and a separate read-then-insert check would let the
+            // concurrent burst all pass before any insert). Runs off the
+            // response's critical path, so it never restores the account-
+            // existence oracle. A throttled call mints nothing and returns no
+            // token → no link is sent this window.
             var minted = await deps.customerPortal.createSession({
-              customer_id: customerId,
-              scope:       "full",
+              customer_id:          customerId,
+              scope:                "full",
+              min_interval_seconds: MAGIC_LINK_RESEND_COOLDOWN_MS / 1000,
             });
+            if (!minted || !minted.plaintext_token) return;
             var linkUrl = origin + "/account/portal/" + encodeURIComponent(minted.plaintext_token);
             // The customer's plaintext address: the portal flow needs a
             // deliverable address. The customers store keeps only the hash,

package/package.json

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