@blamejs/blamejs-shop 0.5.13 → 0.5.15

package/CHANGELOG.md

@@ -8,6 +8,10 @@ upgrading across more than a few patches at a time.
 
 ## v0.5.x
 
+- v0.5.15 (2026-07-25) — **`giftCardLedger.history` and `loyaltyRedemption.redemptionsForCustomer` no longer return a next-page cursor that resolves to an empty page.** Fixes a cursor-pagination contract defect in two ledger/history primitives. giftCardLedger.history and loyaltyRedemption.redemptionsForCustomer emitted a next-page cursor whenever a page came back full — its row count equalled the requested limit — instead of first peeking one row past the page. When the history length is an exact multiple of the page size, the last full page still handed back a cursor; following it queried for strictly older rows and returned nothing, so a caller paginating with the cursor would land on an empty page. Both methods now fetch one extra row, emit the cursor only when a genuinely older row exists, and return the page trimmed to the requested size — matching the store-credit and loyalty-transaction history that already peek. This is an API-level correctness fix: the shop's current callers of these two methods read only the returned rows (the admin gift-card ledger view and the account loyalty-redemptions list do not paginate on this cursor), so no live page changes today; the fix corrects the primitives' cursor contract for any consumer that does paginate and removes a latent phantom-page. A codebase check now covers each method so the peek can't be dropped again. **Fixed:** *Gift-card and loyalty-redemption history return an honest next-page cursor* — giftCardLedger.history and loyaltyRedemption.redemptionsForCustomer keyed their next-page cursor off "the page came back full" (row count === limit) rather than peeking one row beyond the page, so a history whose length is an exact multiple of the page size returned a cursor on its last full page that resolves to an empty page when followed. Both now fetch limit + 1 rows, emit the cursor only when an older row actually exists, and return the page trimmed to the requested limit — the same peek the store-credit and loyalty-transaction history already use. The change is to the primitives' pagination contract (the shop's present callers of these two methods consume only the rows, so no rendered page changes); it removes a latent phantom next page for any consumer that paginates on the cursor. A codebase-patterns check now guards each method against a regression that drops the peek.
+
+- v0.5.14 (2026-07-25) — **A sales-tax refund is now credited in the filing period it occurs even when the refunded order was placed in an earlier period, closing a systematic over-remittance.** Fixes a sales-tax over-remittance (CWE-682, incorrect calculation) in sales_tax_filings.computeFiling. A partial or full refund reduces the filing for the period it occurs in, but the computation only consulted refunds for orders that were ALSO created inside that filing window. Because a refund almost always lands in a later period than the sale — the norm under monthly filing — a refund of a prior-period order was silently dropped from every filing: the sale period had already remitted the full tax, and the refund period never subtracted it. The operator over-remitted the refunded tax to the jurisdiction. computeFiling now nets every in-window refund against the current period regardless of when the refunded order was placed, apportioning the refunded cash to subtotal and tax by the order's own structure, matching it to the order's jurisdiction and exemption, and attributing the reduction to the tax rate effective at the order's sale time so both collected and owed reflect it. A window whose refunds exceed its own sales floors at zero rather than storing a negative filing (the schema does not carry a net-credit forward; the guarantee is that the fix never over-remits and never violates the constraint). **Fixed:** *Cross-period sales-tax refunds are credited in the period they occur* — computeFiling netted a refund only when the refunded order fell inside the same filing window as the refund. A refund recorded in a later period than the sale — the common case under monthly or quarterly filing — was therefore attributed to no period at all: the sale period had already remitted the tax in full, and the refund period skipped the order because it was created earlier. The refunded tax was remitted and never credited, so the operator over-paid the jurisdiction on every returned prior-period sale. The filing now processes every refund recorded inside the window against the current period, whether or not the refunded order was created in it — apportioning the refunded cash to taxable subtotal and tax by the order's own totals, honoring the order's jurisdiction and customer exemption, and reducing the rate bucket effective at the order's sale time so tax_collected and tax_owed both net the refund. A window whose in-window sales are outweighed by refunds of earlier-period orders reports zero rather than a negative filing.
+
 - v0.5.13 (2026-07-25) — **Vendored framework refreshed from 0.16.3 to 0.17.22, inheriting a batch of security and correctness fixes across the rate-limit, CSP, cookie, data-subject-request, webhook, TLS, and SQL primitives the store composes.** Refreshes the framework the store is built on from 0.16.3 to 0.17.22, a broad security and robustness update to primitives the store wires into every request. All of the following are inherited without shop code changes. Per-route rate-limit buckets now key on the request path only, not the query string, so an abuser can no longer mint a fresh bucket per request with a rotating query parameter to slip past a login or checkout limiter. CSP source screening, cookie-prefix checks, and the CSRF cookie branch are now ASCII case-insensitive, closing a case-variant bypass of a Content-Security-Policy keyword and of the __Secure-/__Host- cookie-prefix guarantees. A data-subject-request (privacy export/erasure) whose subject has no indexable key now fails closed instead of matching every ticket, removing a cross-subject disclosure and erasure path. The shared outbound HTTP cache no longer serves an Authorization-bearing response across principals, the strict TLS hostname verifier no longer accepts a name smuggled through a quoted subjectAltName, and inbound webhook verification rejects a non-canonical signed timestamp. The minimum Node.js engine is unchanged at 24.18.0. **Changed:** *Vendored framework refreshed to 0.17.22* — Advances the vendored framework from 0.16.3 to 0.17.22. Beyond the security fixes above, the store inherits SQLite/D1 robustness — a paginated query with an OFFSET but no LIMIT now runs instead of raising a syntax error, and a CSV export degrades an out-of-range timestamp for one row instead of aborting the whole export — along with prototype-safe own-property lookups across the crypto, internationalization, and content-guard primitives and a current Public Suffix List snapshot for domain-scoped cookie and email-alignment decisions. The minimum Node.js engine is unchanged at 24.18.0. **Security:** *Per-route rate limiters can no longer be evaded with a rotating query string* — The framework's per-route rate limiters — mounted on the abusable login, signup, checkout, and gift-card endpoints — bucketed a client by the full request target including the query string, so a request stream carrying a rotating parameter such as ?nonce=1, ?nonce=2, ... minted a fresh bucket each time and never tripped the limit. Buckets now key on the path only, so the limit counts every hit to a route regardless of its query string. Inherited from the framework refresh; no configuration change. · *Case-variant bypass of CSP keywords and cookie prefixes closed* — Content-Security-Policy source screening and the __Secure-/__Host- cookie-prefix checks compared tokens case-sensitively, so a case-variant of a policy keyword or a cookie-prefix marker could slip past the guard; the CSRF cookie path was also missing the __Secure- branch. These comparisons are now ASCII case-insensitive and the CSRF branch is present, so the store's CSP and its prefixed session/CSRF cookies enforce their intended guarantees against a mixed-case forgery. Inherited from the framework refresh. · *Data-subject-request filter fails closed on a subject with no indexable key* — The data-subject-request store (the privacy export and erasure path) built its subject filter such that a subject carrying no indexable key matched every ticket, which could disclose or erase records across subjects. The filter now fails closed — a subject that cannot be keyed matches nothing — removing the cross-subject path. The store also now composes the shared SQL builder, inheriting its reserved-word and sealed-column handling. Inherited from the framework refresh. · *Shared outbound HTTP cache no longer crosses principals; TLS and webhook verifiers hardened* — Three verifier and cache fixes ride in with the refresh: the shared outbound HTTP response cache no longer returns an Authorization-bearing response to a different principal; the strict RFC 9525 TLS hostname verifier now parses subjectAltName quote-aware, so a hostname smuggled through a quoted SAN value can no longer be accepted; and inbound webhook signature verification rejects a non-canonical signed timestamp (scientific/hex/leading-zero forms) instead of treating it as valid. The declared algorithm on a verified JWT is now bound to the key's real type, closing an algorithm-confusion acceptance. Inherited from the framework refresh.
 
 - 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.

package/lib/asset-manifest.json

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

package/lib/gift-card-ledger.js

@@ -651,10 +651,14 @@ function create(opts) {
         params.push(cursor);
       }
       sql += " ORDER BY occurred_at DESC, id DESC LIMIT ?" + (params.length + 1);
-      params.push(limit);
+      // Peek one row past the page: emitting next_cursor whenever the page
+      // came back full (rows.length === limit) advertises an "older" page that
+      // renders empty when the ledger length is an exact multiple of the limit.
+      params.push(limit + 1);
       var r = await query(sql, params);
-      var rows = r.rows;
-      var nextCursor = rows.length === limit ? rows[rows.length - 1].occurred_at : null;
+      var hasMore = r.rows.length > limit;
+      var rows = hasMore ? r.rows.slice(0, limit) : r.rows;
+      var nextCursor = hasMore ? rows[rows.length - 1].occurred_at : null;
       return { rows: rows, next_cursor: nextCursor };
     },
 

package/lib/loyalty-redemption.js

@@ -615,11 +615,16 @@ function create(opts) {
       params.push(listOpts.cursor);
     }
     sql += " ORDER BY redeemed_at DESC, id DESC LIMIT ?" + (params.length + 1);
-    params.push(limit);
-    var rows = (await query(sql, params)).rows;
+    // Peek one row past the page so a full final page does not advertise a
+    // phantom "older" page (empty when the redemption count is an exact
+    // multiple of the limit) — mirrors store-credit / loyalty history.
+    params.push(limit + 1);
+    var fetched = (await query(sql, params)).rows;
+    var hasMore = fetched.length > limit;
+    var pageRows = hasMore ? fetched.slice(0, limit) : fetched;
     var hydrated = [];
-    for (var i = 0; i < rows.length; i += 1) hydrated.push(_hydrateRedemption(rows[i]));
-    var nextCursor = rows.length === limit ? hydrated[hydrated.length - 1].redeemed_at : null;
+    for (var i = 0; i < pageRows.length; i += 1) hydrated.push(_hydrateRedemption(pageRows[i]));
+    var nextCursor = hasMore ? hydrated[hydrated.length - 1].redeemed_at : null;
     return { rows: hydrated, next_cursor: nextCursor };
   }
 

package/lib/sales-tax-filings.js

@@ -384,6 +384,49 @@ function create(opts) {
     return out;
   }
 
+  // Fetch specific orders by id (for netting a refund whose order was
+  // created OUTSIDE the filing window — see the cross-period refund pass in
+  // computeFiling). Unlike _ordersInWindow this does NOT restrict to the
+  // sale-status set: a balance-clearing refund moves the order to the
+  // terminal `refunded` state, and that full-refund order is exactly the one
+  // the cross-period pass must credit — so `refunded` is included alongside
+  // the live sale statuses. `pending` / `cancelled` are excluded (they never
+  // counted as a sale, and a real refund transition never lands on them).
+  // The jurisdiction match still applies so a refund only reduces its own
+  // filing.
+  async function _ordersByIds(jurisdiction, ids) {
+    if (!ids.length) return [];
+    var placeholders = ids.map(function (_v, i) { return "?" + (i + 1); }).join(", ");
+    var r = await query(
+      "SELECT id, customer_id, currency, subtotal_minor, tax_minor, grand_total_minor, " +
+      "       ship_to_json, status, created_at " +
+      "FROM orders " +
+      "WHERE id IN (" + placeholders + ") " +
+      "  AND status IN ('paid', 'fulfilling', 'shipped', 'delivered', 'refunded')",
+      ids,
+    );
+    var out = [];
+    for (var i = 0; i < r.rows.length; i += 1) {
+      var row = r.rows[i];
+      var shipTo;
+      try { shipTo = JSON.parse(row.ship_to_json); }
+      catch (_e) { shipTo = null; }
+      if (!_shipToMatches(shipTo, jurisdiction)) continue;
+      out.push({
+        id:                 row.id,
+        customer_id:        row.customer_id,
+        currency:           row.currency,
+        subtotal_minor:     Number(row.subtotal_minor),
+        tax_minor:          Number(row.tax_minor),
+        grand_total_minor:  row.grand_total_minor == null ? 0 : Number(row.grand_total_minor),
+        status:             row.status,
+        created_at:         Number(row.created_at),
+        ship_to:            shipTo,
+      });
+    }
+    return out;
+  }
+
   // Total partial-refund cash refunded per order INSIDE the window. A
   // partial refund is an `on_event = 'refund'` self-loop transition that
   // leaves the order in its paid/fulfilling/shipped/delivered status (no
@@ -626,6 +669,89 @@ function create(opts) {
       bkt.order_count += 1;
     }
 
+    // Cross-period refunds: a refund recorded inside this window against an
+    // order created in an EARLIER period is never reached by the loop above
+    // (that order is not in `orders`). The returns-reduce-the-current-period
+    // convention (_refundsInWindow) requires it to reduce THIS filing anyway
+    // — its original sale was already remitted in the sale period, so ONLY
+    // the refunded portion applies here, as a pure reduction (no fresh sale).
+    // Without this pass the refunded tax is remitted in the sale period and
+    // never credited in any period → the operator over-remits.
+    var periodStartMs = Number(raw.period_start);
+    var inWindowIds = Object.create(null);
+    for (var wi = 0; wi < orders.length; wi += 1) { inWindowIds[orders[wi].id] = true; }
+    // Candidate = a refund whose order was NOT counted as an in-window sale.
+    // That set includes both true prior-period orders AND orders created in
+    // this window but already dropped by _ordersInWindow (a full refund moved
+    // them to `refunded`). We fetch them all, then keep ONLY those created
+    // before the window: an order created AND refunded in-window already nets
+    // to zero (its sale was excluded and its refund is not added), so netting
+    // its refund here would double-subtract.
+    var candidateIds = [];
+    var refundOrderIds = Object.keys(refunds);
+    for (var ki = 0; ki < refundOrderIds.length; ki += 1) {
+      if (!inWindowIds[refundOrderIds[ki]]) candidateIds.push(refundOrderIds[ki]);
+    }
+    if (candidateIds.length) {
+      var candidates = await _ordersByIds(raw.jurisdiction, candidateIds);
+      var crossOrders = [];
+      var minCreated = periodStartMs;
+      for (var cj = 0; cj < candidates.length; cj += 1) {
+        if (candidates[cj].created_at >= periodStartMs) continue;   // in-window sale — nets to zero, skip
+        crossOrders.push(candidates[cj]);
+        if (candidates[cj].created_at < minCreated) minCreated = candidates[cj].created_at;
+      }
+      if (crossOrders.length) {
+        // Resolve each refund against the rate effective at the ORDER's own
+        // sale time — a rate that changed and expired before this window is
+        // NOT in `rates`, so pull the rate rows covering the earliest
+        // cross-period sale through this window's end. Without this a
+        // post-rate-change refund lands in "__none__", tax_owed omits the
+        // credit, and the over-remittance persists.
+        var crossRates = await _ratesInWindow(raw.jurisdiction, minCreated, Number(raw.period_end));
+        // Resolve exemption for any cross-period customer not already cached.
+        if (taxExemptApi && typeof taxExemptApi.isExempt === "function") {
+          for (var ce = 0; ce < crossOrders.length; ce += 1) {
+            var cxCust = crossOrders[ce].customer_id;
+            if (!cxCust || Object.prototype.hasOwnProperty.call(exemptByCustomer, cxCust)) continue;
+            try {
+              exemptByCustomer[cxCust] = await taxExemptApi.isExempt({
+                customer_id:  cxCust,
+                jurisdiction: raw.jurisdiction,
+              });
+            } catch (_e) {
+              exemptByCustomer[cxCust] = false;
+            }
+          }
+        }
+        for (var xi = 0; xi < crossOrders.length; xi += 1) {
+          var xo = crossOrders[xi];
+          var xRefunded = refunds[xo.id] || 0;
+          if (!(xRefunded > 0) || !(xo.grand_total_minor > 0)) continue;
+          var xSub = _apportionMinor(xRefunded, xo.subtotal_minor, xo.grand_total_minor);
+          var xTax = _apportionMinor(xRefunded, xo.tax_minor,      xo.grand_total_minor);
+          gross     -= xSub;
+          collected -= xTax;
+          var xExempt = xo.customer_id && exemptByCustomer[xo.customer_id] === true;
+          if (xExempt) {
+            exempt -= xSub;
+          } else {
+            taxable -= xSub;
+            // The bucket may go negative — a valid per-rate CREDIT that offsets
+            // same-rate or other-rate sales when owed is summed across buckets
+            // below. It is intentionally NOT floored per-bucket: zeroing one
+            // negative bucket would discard the credit and over-charge owed on
+            // the surviving buckets.
+            var xRate = _rateForOrder(crossRates, xo.created_at);
+            var xKey  = xRate ? String(xRate.rate_bps) : "__none__";
+            var xbkt  = _bucket(xKey);
+            xbkt.taxable_minor -= xSub;
+            xbkt.tax_minor     -= xTax;
+          }
+        }
+      }
+    }
+
     // Owed: re-derive from per-rate taxable totals using rate_bps.
     // owed = taxable × bps / 10000 per rate, half-even via b.money
     // (BigInt — taxable_minor sums every order in the window and can
@@ -652,6 +778,23 @@ function create(opts) {
       owed = collected;
     }
 
+    // The filing schema stores non-negative totals (CHECK ..._minor >= 0). The
+    // signed accumulation above lets a cross-period refund credit offset sales
+    // across rate buckets, so tax_owed is exact for any net-non-negative
+    // filing. The stored columns are floored here, kept RECONCILED so
+    // taxable + exempt == gross always holds (taxable floors, then exempt is
+    // the remainder of gross). The common case (window sales exceed the refunds
+    // netted in) never reaches the floor and stays exact. A true net-credit
+    // window — refunds outweighing the window's own sales — reports zero
+    // rather than a negative filing (carrying the residual credit forward is a
+    // separate enhancement the schema does not yet model).
+    if (gross    < 0)     gross    = 0;
+    if (taxable  < 0)     taxable  = 0;
+    if (taxable  > gross) taxable  = gross;
+    exempt = gross - taxable;
+    if (collected < 0)    collected = 0;
+    if (owed      < 0)    owed      = 0;
+
     var ts = _now();
     await query(
       "UPDATE sales_tax_filings SET " +

package/package.json

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