@blamejs/blamejs-shop 0.5.10 → 0.5.12

package/CHANGELOG.md

@@ -8,6 +8,10 @@ upgrading across more than a few patches at a time.
 
 ## v0.5.x
 
+- v0.5.12 (2026-07-03) — **Operator password sign-in now has a brute-force lockout keyed on both the client IP and the target account.** Wires a brute-force lockout into the operator email+password sign-in (/admin/operators/signin), which previously relied only on the global per-IP rate limit and Argon2 verification. The sign-in now records each failed attempt and, before checking the password, refuses with 429 once the failure count for the request's IP or for the target operator account exceeds its threshold within a rolling 15-minute window. Keying on the account as well as the IP bounds a distributed guess — an attacker rotating IPs against one operator — that a per-IP limit alone can't see. The account threshold is deliberately higher than the per-IP threshold, so a legitimate operator is only ever account-locked under a genuine multi-IP attack, and the lock is a temporary cooldown that auto-expires with the window rather than a permanent lock an attacker could weaponize into a denial of service. The target account is resolved up front for the account key regardless of whether the email matches a real operator, and a lockout returns the same generic sign-in refusal, so no account-existence oracle is added. A successful sign-in clears the account's recent failures so an operator who mistyped isn't held under the window. The lockout composes the existing operator-session primitive and its already-deployed failed-login table — no schema change and no configuration; the failed-attempt log also feeds the operator security timeline. **Security:** *Brute-force lockout on the operator password sign-in* — The operator email+password sign-in had no per-account brute-force protection — only the global per-IP rate limit and Argon2 slowed guessing, so a distributed attack rotating IPs against a single operator account was unbounded. The sign-in now records each failed attempt and refuses with 429 (before verifying the password) once the failures for the request IP or the target account exceed their thresholds in a rolling 15-minute window. The account threshold is higher than the per-IP one, so a legitimate operator is only account-locked under a real multi-IP attack, and the lock auto-expires with the window (a cooldown, not a weaponizable permanent lock). The account is resolved whether or not the email is real and a lockout returns the same generic refusal, so there is no account-existence oracle; a successful sign-in clears the account's recent failures. Composes the existing operator-session primitive and its deployed failed-login table — no schema change, no configuration, and the failed-attempt log continues to feed the operator security timeline.
+
+- v0.5.11 (2026-07-03) — **A second customer or product import started while one is already running is refused instead of clobbering the first run's cancel handle.** Fixes a small concurrency defect in the customer and product CSV/row import runners. Each runner tracks a single in-flight run so the operator console's cancel action knows which run to stop. The run opener set that handle after writing the run row, so two runs started at nearly the same moment — an operator double-submitting the form or opening two tabs — could both open, and the second would overwrite the first's in-flight handle. A subsequent cancel would then target the wrong run, leaving the other running. The opener now reserves the single in-flight slot synchronously, before any await, so a second run is refused with a clear "an import is already in progress" error while the first proceeds; the reservation is released if the run fails to open, and the console can start a fresh import as soon as the running one finishes. **Fixed:** *Overlapping import runs no longer clobber the in-flight run handle* — The customer and product import runners keep one in-flight run handle so cancel targets the right run. Because the opener set that handle only after inserting the run row, two imports started concurrently could both open and the second would overwrite the first's handle, so a later cancel stopped the wrong run. The opener now claims the in-flight slot synchronously (before the first await, so the check-and-set can't interleave) and refuses a second concurrent run with an "import already in progress" error; the slot is released if the open fails, and a new import can start once the running one completes.
+
 - v0.5.10 (2026-07-03) — **Redirect rules with a regex source are screened for nested-quantifier catastrophic backtracking before they run on the request path.** Closes the last catastrophic-backtracking (ReDoS) gap in operator-authored redirect rules. A site-redirect of kind "regex" compiles the operator's source into a pattern that resolveForPath runs against the request path on every request. The define-time screen already refused backreferences and lookahead/lookbehind, but not a nested unbounded quantifier — a group whose body carries an unbounded quantifier that is itself repeated by one, such as (a+)+, (a*)*, (?:a+)+ or (.+)+ — so an operator could register a rule whose match time is super-linear in the path length, turning every matching request into a denial of service. The screen now also refuses that shape at define time, at any group depth, while continuing to accept linear patterns that merely use a quantified non-capturing group ((?:/page/[0-9]+)?, (?:section)*) or an optional quantified group. The match is exact — only a nested UNBOUNDED quantifier is refused; a single quantifier, an optional group, and bounded repetition are all allowed — so no well-formed redirect regex that worked before is rejected. **Security:** *Redirect regex sources refuse nested unbounded quantifiers at define time* — A redirect rule of kind "regex" runs its compiled pattern against the request path in resolveForPath. The define-time screen rejected backreferences and lookaround but not a nested unbounded quantifier ((a+)+, (a*)*, (?:a+)+, (.+)+, ((ab)+)+ at any depth) — the canonical ReDoS shape — so an operator could land a rule whose match is super-linear in the path length, letting a crafted request path stall the redirect resolver. The screen now refuses that shape when the rule is defined, with an error pointing the operator at a prefix/exact rule or splitting into multiple rows. Linear patterns are unaffected: a quantified non-capturing group, an optional quantified group, a single quantifier, and bounded repetition are all still accepted, so no redirect regex that worked before is rejected.
 
 - v0.5.9 (2026-07-03) — **A federated sign-in no longer auto-merges into a pre-existing account whose email was never proven, closing an account pre-hijacking path.** Closes an account pre-hijacking weakness in federated (Google / Apple) sign-in. When a verified OIDC sign-in found a pre-existing account with the same email, it linked the federated identity into that account on the strength of the incoming email being verified alone — without requiring the pre-existing account to have ever proven control of that email. Because a passkey (or otherwise passwordless) account is created with whatever email address was typed at registration and no ownership check, an attacker could register an account under a victim's email before the victim's first federated sign-in, and the victim's later Google/Apple sign-in would then be folded into the attacker's account — pulling the victim's guest orders in and leaving the attacker's credential enrolled. The merge now requires the pre-existing account to already carry a verified federated identity (the only account-creation path that proves the email); an account whose email was never proven falls through to the existing duplicate-email refusal, so the customer signs in with their existing method and links the provider from account settings. A first federated sign-in still creates a fresh account, and a second provider still links to an account whose email is already proven, so legitimate multi-provider sign-in is unchanged. **Security:** *Federated sign-in refuses to merge into an unverified pre-existing account* — A verified Google/Apple sign-in that matched a pre-existing account by email hash previously linked the federated identity into that account whenever the incoming identity-provider email was verified — even if the pre-existing account had never proven control of the email. A passkey/passwordless account stores the email typed at registration with no verification, so an attacker could pre-seed an account under a victim's email and capture the victim's later federated sign-in (account pre-hijacking, CWE-287). The merge now proceeds only when the pre-existing account already holds a verified federated identity — the one account-creation path that proves the email. An unverified match is refused with the existing duplicate-email conflict, directing the customer to sign in with their existing method and link the provider from account settings. First-time federated sign-in (new account) and second-provider linking into an already-proven account are unchanged.

package/SECURITY.md

@@ -130,7 +130,12 @@ node -e "
   bootstrap / break-glass owner credential; once staff accounts exist,
   treat it like a recovery key — store it offline and use the
   per-operator credentials day to day. Every operator-management action
-  and every role-denied attempt lands in the audit chain.
+  and every role-denied attempt lands in the audit chain. The password
+  sign-in throttles brute force: repeated failures from one IP, or a
+  distributed guess against one account, are refused with a temporary
+  lockout (keyed on both the IP and the account, higher threshold on the
+  account, auto-expiring on a rolling window) on top of the global
+  rate limit and Argon2id.
 - **Guest order pages are access-gated, not capability URLs.** A guest
   order's confirmation page (name, address, items) requires the placing
   browser's sealed device cookie, the signed `?k=` token carried by the

package/lib/admin.js

@@ -927,6 +927,21 @@ function mount(router, deps) {
   // booted) chains every operator-management action + role-denied attempt.
   var operatorAccounts = deps.operatorAccounts || null;
   var operatorAuditLog = deps.operatorAuditLog || null;
+  // Optional brute-force lockout for the operator password sign-in. When wired,
+  // the sign-in records failed attempts and refuses once the per-IP or (higher)
+  // per-account failure threshold trips within the rolling window. Best-effort:
+  // absent this dep the sign-in behaves exactly as before (rate-limit + Argon2).
+  var operatorSessions = deps.operatorSessions || null;
+
+  // Hash of the request's client IP, domain-separated for the operator-login
+  // lockout so it can't be correlated with any other IP-keyed store. Returns
+  // null when the IP can't be resolved (the lockout then keys on the account
+  // only, or is skipped for an unresolved-account attempt).
+  function _clientIpHash(req) {
+    var ip = b.requestHelpers.clientIp(req);
+    if (!ip) return null;
+    return b.crypto.namespaceHash("operator-login-ip", String(ip));
+  }
 
   // Unified order-event feed for the order-detail screen. When wired, the
   // /admin/orders/:id page renders a chronological timeline aggregated
@@ -14373,12 +14388,53 @@ function mount(router, deps) {
       var body  = req.body || {};
       var email = typeof body.email === "string" ? body.email : "";
       var pass  = typeof body.password === "string" ? body.password : "";
+
+      // Brute-force lockout (best-effort — only when operatorSessions is
+      // wired). Resolve the target account up front for the per-account key:
+      // the lookup runs whether or not the email matches a real operator, and
+      // the refusal is the SAME generic form the bad-credential path returns,
+      // so it adds no account-existence oracle. The lockout keys on BOTH the
+      // client IP and the target account so a distributed (IP-rotating) guess
+      // against one operator is bounded, not only per-IP.
+      var ipHash = null, targetId = null;
+      if (operatorSessions) {
+        try { ipHash = _clientIpHash(req); } catch (_e) { ipHash = null; }
+        try {
+          var pre = await operatorAccounts.getByEmail(email);
+          targetId = (pre && pre.id) ? pre.id : null;
+        } catch (_e) { targetId = null; }
+        if (ipHash) {
+          var lock = null;
+          try { lock = await operatorSessions.lockoutCheck(ipHash, { operator_id: targetId }); }
+          catch (_e) { lock = null; }
+          if (lock && lock.locked) {
+            if (res.setHeader) res.setHeader("retry-after", String(lock.window_seconds || 900));
+            return _sendHtml(res, 429, renderOperatorSignin({ shop_name: deps.shop_name, error: true, locked: true }));
+          }
+        }
+      }
+
       var account = null;
       try { account = await operatorAccounts.verifyPassword({ email: email, password: pass }); }
       catch (_e) { account = null; }
       if (!account) {
+        // Record the failed attempt for the lockout (drop-silent — the lockout
+        // is best-effort; a logging failure must not break the sign-in path).
+        if (operatorSessions && ipHash) {
+          try {
+            await operatorSessions.recordFailedVerify({ ip_hash: ipHash, operator_id: targetId, reason: "bad-password" });
+          } catch (_e) { /* drop-silent */ }
+        }
         return _sendHtml(res, 401, renderOperatorSignin({ shop_name: deps.shop_name, error: true }));
       }
+      // Successful sign-in clears THIS account's recent failures so a legit
+      // operator who mistyped isn't held under the rolling window next time.
+      // Scoped strictly to the signed-in account (never the IP) so signing in
+      // can't erase another operator's failures logged from the same IP.
+      if (operatorSessions) {
+        try { await operatorSessions.clearFailures({ operator_id: account.id }); }
+        catch (_e) { /* drop-silent */ }
+      }
       try { _setAdminCookie(req, res, account); }
       catch (e) {
         if (e && e.code === "vault/not-initialized") {

package/lib/asset-manifest.json

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

package/lib/customer-import.js

@@ -182,16 +182,32 @@ function _addError(errors, maxErrors, rowIndex, message) {
 // ---- run-row persistence -----------------------------------------------
 
 async function _openRun(query, state, source, inputByteCount) {
+  // Reserve the single in-flight slot SYNCHRONOUSLY — before the first await —
+  // so two concurrent runs (an operator double-submitting) can't both open. A
+  // second run is refused rather than silently overwriting the first's inflight
+  // handle, which would leave `cancelInflight` targeting the wrong run. The
+  // check + set have no await between them, so the reservation is race-free in
+  // the single-threaded event loop.
+  if (state.inflight) {
+    var busy = new Error("customer-import: an import is already in progress");
+    busy.code = "IMPORT_IN_PROGRESS";
+    throw busy;
+  }
   var runId = b.uuid.v7();
   var startedAt = Date.now();
-  await query(
-    "INSERT INTO customer_imports " +
-    "(id, started_at, completed_at, status, source, input_byte_count, " +
-    " rows_processed, rows_created, rows_updated, rows_skipped, rows_errored, errors_json) " +
-    "VALUES (?1, ?2, NULL, 'running', ?3, ?4, 0, 0, 0, 0, 0, '[]')",
-    [runId, startedAt, source, inputByteCount],
-  );
   state.inflight = { runId: runId, cancelled: false };
+  try {
+    await query(
+      "INSERT INTO customer_imports " +
+      "(id, started_at, completed_at, status, source, input_byte_count, " +
+      " rows_processed, rows_created, rows_updated, rows_skipped, rows_errored, errors_json) " +
+      "VALUES (?1, ?2, NULL, 'running', ?3, ?4, 0, 0, 0, 0, 0, '[]')",
+      [runId, startedAt, source, inputByteCount],
+    );
+  } catch (e) {
+    state.inflight = null;   // release the reservation if the open failed
+    throw e;
+  }
   return { runId: runId, startedAt: startedAt };
 }
 
@@ -205,7 +221,14 @@ async function _closeRun(query, state, runId, status, counters, errors) {
     "SELECT status FROM customer_imports WHERE id = ?1",
     [runId],
   )).rows[0];
-  var finalStatus = (current && current.status === "cancelled") ? "cancelled" : status;
+  // Treat the run as cancelled if EITHER the row already says so OR the
+  // in-memory flag for THIS run is set. The flag path covers a cancel that
+  // landed in the reservation→INSERT window: `cancelInflight` flipped the flag
+  // and ran an UPDATE that matched no row yet (the run row wasn't inserted), so
+  // reading the DB status alone would finalize a cancelled run as complete.
+  var cancelled = (current && current.status === "cancelled") ||
+    !!(state.inflight && state.inflight.runId === runId && state.inflight.cancelled);
+  var finalStatus = cancelled ? "cancelled" : status;
   var errorsJson = b.safeJson.stringify(errors, { canonical: true });
   await query(
     "UPDATE customer_imports SET " +

package/lib/operator-sessions.js

@@ -148,7 +148,14 @@ var MAX_UA_CLASS_LEN        = 64;
 var MAX_IP_HASH_LEN         = 256;
 var MIN_IP_HASH_LEN         = 1;
 var DEFAULT_LOCKOUT_WINDOW  = 15 * 60;                  // allow:raw-time-literal — lockout window stored in seconds; C.TIME returns ms (15-minute rolling window)
-var DEFAULT_LOCKOUT_THRESH  = 5;                        // 5 failures trips lockout
+var DEFAULT_LOCKOUT_THRESH  = 5;                        // 5 failures (per IP) trips lockout
+// Per-account threshold is deliberately HIGHER than the per-IP one: a
+// distributed (IP-rotating) brute force against a single account is the thing
+// the account key catches, and keeping it well above the per-IP threshold
+// means a legitimate operator is only ever account-locked under a genuine
+// multi-IP attack — and only for the rolling window (a temporary cooldown, not
+// a permanent lock an attacker could weaponize into a denial of service).
+var DEFAULT_ACCOUNT_LOCKOUT_THRESH = 20;
 var MAX_LOCKOUT_WINDOW      = 24 * 60 * 60;             // allow:raw-time-literal — lockout window stored in seconds; C.TIME returns ms (sanity cap — one day)
 var MIN_LOCKOUT_THRESHOLD   = 1;
 var MAX_LOCKOUT_THRESHOLD   = 1000;
@@ -647,14 +654,70 @@ function create(opts) {
         [ip, since],
       );
       var count = Number((r.rows[0] && r.rows[0].n) || 0);
+
+      // Optional per-account keying. The per-IP count above can't see a
+      // distributed brute force (one attacker rotating IPs against one
+      // account); counting failures for the target operator across ALL IPs
+      // in the same window catches it. The account threshold is higher (see
+      // DEFAULT_ACCOUNT_LOCKOUT_THRESH) so a legitimate operator isn't locked
+      // by a handful of their own mistypes, only by a genuine multi-IP attack.
+      var accountThreshold = _lockoutThreshold(
+        lopts.account_threshold == null ? DEFAULT_ACCOUNT_LOCKOUT_THRESH : lopts.account_threshold);
+      var acctCount = 0;
+      if (lopts.operator_id != null) {
+        var oid = _uuid(lopts.operator_id, "operator_id");
+        var ar = await query(
+          "SELECT COUNT(*) AS n FROM operator_failed_logins " +
+          "WHERE operator_id = ?1 AND occurred_at >= ?2",
+          [oid, since],
+        );
+        acctCount = Number((ar.rows[0] && ar.rows[0].n) || 0);
+      }
+
+      var lockedByIp      = count >= threshold;
+      var lockedByAccount = lopts.operator_id != null && acctCount >= accountThreshold;
       return {
-        locked:         count >= threshold,
-        count:          count,
-        threshold:      threshold,
-        window_seconds: windowSec,
+        locked:            lockedByIp || lockedByAccount,
+        locked_by:         lockedByIp ? "ip" : (lockedByAccount ? "account" : null),
+        count:             count,
+        threshold:         threshold,
+        account_count:     acctCount,
+        account_threshold: accountThreshold,
+        window_seconds:    windowSec,
       };
     },
 
+    // ---- clearFailures --------------------------------------------------
+    //
+    // Delete the recent failed-attempt rows for the signed-in ACCOUNT after a
+    // SUCCESSFUL sign-in, so a legitimate operator who mistyped a few times
+    // isn't held under the rolling lockout window on the next attempt.
+    //
+    // Scoped to `operator_id` — which is REQUIRED. An optional `ip_hash` only
+    // NARROWS the deletion to that IP (AND), never widens it. This matters:
+    // clearing by IP (or account-OR-IP) would wipe OTHER operators' failed
+    // rows from the same IP, so a shared-IP attacker could brute-force a
+    // victim, sign in as themselves, and reset the victim's lockout. Clearing
+    // strictly the caller's own account can't touch another account's rows.
+    // Returns the row count cleared; a no-op when `operator_id` is absent.
+    clearFailures: async function (input) {
+      input = input || {};
+      if (typeof input !== "object") {
+        throw new TypeError("operator-sessions.clearFailures: input must be an object");
+      }
+      if (input.operator_id == null) return { cleared: 0 };
+      var oid    = _uuid(input.operator_id, "operator_id");
+      var params = [oid];
+      var sql    = "DELETE FROM operator_failed_logins WHERE operator_id = ?1";
+      if (input.ip_hash != null) {
+        var ip = _requiredString(input.ip_hash, "ip_hash", MIN_IP_HASH_LEN, MAX_IP_HASH_LEN);
+        params.push(ip);
+        sql += " AND ip_hash = ?2";
+      }
+      var res = await query(sql, params);
+      return { cleared: Number((res && res.rowCount) || 0) };
+    },
+
     // ---- recordFailedVerify ---------------------------------------------
     //
     // Append-only event log. The login middleware calls this on every

package/lib/product-import.js

@@ -327,20 +327,35 @@ async function _drive(query, catalog, state, input, driveOpts) {
   // Per-row normalization errors land in the error list at the
   // matching row_index; the row is skipped for catalog writes but
   // still counted in `rows_processed`.
+  // Reserve the single in-flight slot SYNCHRONOUSLY — before the INSERT await —
+  // so two concurrent runs (an operator double-submitting) can't both open. A
+  // second run is refused rather than overwriting the first's inflight id,
+  // which would leave `cancelInflight` targeting the wrong import. The check +
+  // set have no await between them, so the reservation is race-free.
+  if (state.inflightId) {
+    var busy = new Error("product-import: an import is already in progress");
+    busy.code = "IMPORT_IN_PROGRESS";
+    throw busy;
+  }
   var importId = b.uuid.v7();
   var startedAt = Date.now();
   var inputByteCount = driveOpts.inputByteCount == null ? 0 : driveOpts.inputByteCount;
+  state.inflightId = importId;
+  state.cancelFlag = false;
 
   // Run row goes in at `running`. The driver updates the counters +
   // status at the end. The error rows go in as they're encountered
   // — operators tailing `errorsForImport` see progress mid-run.
-  await query(
-    "INSERT INTO product_imports (id, format, on_conflict, started_at, status, input_byte_count) " +
-    "VALUES (?1, ?2, ?3, ?4, 'running', ?5)",
-    [importId, format, onConflict, startedAt, inputByteCount],
-  );
-  state.inflightId = importId;
-  state.cancelFlag = false;
+  try {
+    await query(
+      "INSERT INTO product_imports (id, format, on_conflict, started_at, status, input_byte_count) " +
+      "VALUES (?1, ?2, ?3, ?4, 'running', ?5)",
+      [importId, format, onConflict, startedAt, inputByteCount],
+    );
+  } catch (e) {
+    state.inflightId = null;   // release the reservation if the open failed
+    throw e;
+  }
 
   var counters = {
     rows_processed:   0,

package/package.json

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