@blamejs/blamejs-shop 0.5.12 → 0.5.13

package/CHANGELOG.md

@@ -8,6 +8,8 @@ upgrading across more than a few patches at a time.
 
 ## v0.5.x
 
+- 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.
 
 - 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.

package/lib/asset-manifest.json

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