@blamejs/blamejs-shop 0.3.63 → 0.3.64

package/CHANGELOG.md

@@ -8,6 +8,8 @@ upgrading across more than a few patches at a time.
 
 ## v0.3.x
 
+- v0.3.64 (2026-06-04) — **Google Pay and Apple Pay express buttons can run on the payment page.** The app-level Permissions-Policy denies the Payment Request API everywhere — including the payment page, the one surface whose job is payment — so Stripe's express wallet buttons (Google Pay, Apple Pay) could not operate and the browser console filled with policy violations. The payment page now sends a route-scoped Permissions-Policy that grants the payment feature to the page itself, Stripe, and Google Pay, while every other feature stays denied and every other route keeps the fully strict header — the same route-scoping pattern the payment pages already use for their Content-Security-Policy. Card payments and 3-D Secure challenges were verified live before and after; a remaining cosmetic Trusted-Types console message from Stripe's loader is documented in code with the test recipe for future verification, and does not affect card, wallet, or 3-D Secure flows. **Fixed:** *Payment page grants the Payment Request API to Stripe and Google Pay* — The default Permissions-Policy sets payment=() sitewide, which blocks the Payment Request API that Stripe's express wallet buttons need. The /pay route now emits the same policy with exactly one change — payment=(self "https://js.stripe.com" "https://pay.google.com") — derived from the same source as the default header so the two can never drift apart. Camera, microphone, geolocation, and every other feature remain denied on the payment page, and all other routes keep payment=(). Tests pin the scoped header on the payment route, the strict header elsewhere, and that exactly one feature differs from the default.
+
 - v0.3.63 (2026-06-04) — **Digital-only carts can check out, and the outbound TLS posture is documented end to end.** A cart containing only digital goods could never complete checkout: the shipping resolver correctly filters physical services out for a cart that ships nothing, but checkout then demanded the configured default physical service resolve anyway and refused the order. Digital-only carts now select the operator's digital-shipping service when one is configured, and otherwise complete with a synthesized zero-cost no-shipping selection; a physical cart with a misconfigured service id still fails loudly, since that is a real configuration error. Separately, every outbound TLS connection has been audited against the framework's post-quantum-first key-exchange posture: of all fixed external hosts, only the Stripe API edge refuses the post-quantum groups (already handled by the payment module's explicit agent) — the CAPTCHA providers, PayPal, and Cloudflare all negotiate hybrids cleanly. Operator-supplied destinations — webhook receiver URLs and admin media source URLs — deliberately keep the post-quantum-first default, with the failure mode documented where operators will look for it: a receiver that cannot negotiate a hybrid group sees deliveries fail with a TLS handshake failure, retry on the backoff schedule, and land in the dead-letter queue; a media source URL that cannot fails as the existing clean fetch error. A regression test pins that these dials never silently downgrade. **Changed:** *Outbound TLS posture audited and documented* — Every outbound connection was audited against the framework's post-quantum-first TLS key-exchange list. Fixed external hosts: the Stripe API edge is the only one that refuses the post-quantum groups, and the payment module's explicitly scoped agent already covers it (PayPal currently negotiates hybrids; the agent remains as defense). Operator-supplied destinations keep the post-quantum-first default deliberately: an outbound-webhook receiver that cannot negotiate a hybrid group sees deliveries fail with a TLS handshake failure (alert 40), retry on the backoff schedule, and reach the dead-letter queue after the fifth attempt — front such a receiver with a post-quantum-capable proxy or upgrade its TLS stack; an admin media source URL that cannot negotiate fails as the existing clean fetch error, and the file can be uploaded directly instead. Module documentation now states this where the integrations are configured, and a regression test pins that these dials never silently downgrade. **Fixed:** *Digital-only carts complete checkout* — Shipping rate resolution offers only digital-shipping services to a cart in which no line requires shipping — so the configured default physical service id could never resolve, and checkout refused every all-digital order. Checkout now falls back for all-digital carts: the operator's digital-shipping service is selected when configured, and a zero-cost "No shipping required" selection is synthesized otherwise, so the order completes and records zero shipping. Physical carts are unchanged: an unresolvable service id still fails at the boundary, because that is a real configuration typo.
 
 - v0.3.62 (2026-06-04) — **Live card payments work, and back-in-stock unsubscribe is token-gated.** Checkout failed at the charge step on Stripe-configured deploys: the framework's outbound HTTP client offers only post-quantum hybrid TLS key-exchange groups, and the Stripe and PayPal API edges do not negotiate any of them yet, so every processor call died with a TLS handshake failure (alert 40) and checkout rendered a server error. The payment module now dials the processors through an explicitly constructed agent — TLS 1.3 minimum, the platform's default key-exchange groups — which is the framework's prescribed pattern for a peer that cannot meet the post-quantum list: the downgrade is visible in the code, scoped to the processor connections only, and every other outbound connection keeps the post-quantum-first default. Verified against the live Stripe API. The downgrade reverts when the processor edges add hybrid key-exchange support. Separately, the checkout error page no longer echoes upstream failure detail (such as TLS library internals) to the customer — that detail goes to the audit log, and the page states plainly that nothing was charged. This release also token-gates back-in-stock unsubscribe: cancelling a back-in-stock alert previously took only the subscriber's email address and the product SKU — guessable values, so a third party could silently cancel someone else's restock notification. Unsubscribe is now authorized by an opaque per-subscription token, carried in the confirmation and notification emails as a one-click link, exactly like the newsletter's unsubscribe. Tokens are stored only as keyed hashes, compared in constant time, and unknown tokens get the same response as valid ones, so the endpoint is not a subscription-existence oracle. A schema migration adds the token column; it applies automatically on deploy. **Changed:** *Back-in-stock unsubscribe requires the emailed token* — POST /stock-alert/unsubscribe no longer accepts an email + SKU pair; it requires the per-subscription token from the unsubscribe link in the confirmation or back-in-stock email. The token is minted at subscribe time for the confirmation mail and rotated per notification send, stored only as a keyed hash, and verified with a constant-time compare; bad or unknown tokens return the same uniform response as valid ones. The one-click link works without cookies or a signed-in session, so mail clients can fire it directly; each email carries the token that is current for its send. Operators upgrading: migration 0207 adds the token column and applies with the normal deploy. **Fixed:** *Stripe and PayPal connections complete their TLS handshake* — The outbound HTTP client's default TLS posture offers exclusively post-quantum hybrid key-exchange groups. Processor API edges currently answer that ClientHello with handshake_failure (TLS alert 40), so the first real charge attempt on a Stripe-configured deploy failed checkout with a server error. The payment module now passes its own connection agent on every processor call — TLS 1.3 minimum is kept, key exchange falls back to the platform defaults — while the client's SSRF pinning, retries, and response caps stay in force. The agent is scoped to the payment-processor dials; all other outbound traffic keeps the post-quantum-first posture. A regression test pins the agent's presence and configuration on the charge path. · *Checkout server errors no longer echo upstream detail to the customer* — When the charge step failed, the checkout error page interpolated the underlying error string — in this case raw TLS library internals — into the customer-facing message. Server-side failure detail now goes to the audit log; the customer sees a plain recoverable message that confirms nothing was charged. Field-validation messages, which are written for customers, are unaffected.

package/lib/asset-manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "0.3.63",
+  "version": "0.3.64",
   "assets": {
     "css/admin.css": {
       "integrity": "sha384-6k53cvkRrxMgmeStLIoLjVXZQHqIJgTmv1Izd8TYhh1HOC4POgE6GCvx1bsalyEP",

package/lib/security-middleware.js

@@ -371,6 +371,59 @@ function scopedCsp(keys) {
   }).join("; ") + ";";
 }
 
+// ---- route-scoped Permissions-Policy (payment surface) ------------------
+//
+// The app-level Permissions-Policy is the vendored strict denylist
+// (DEFAULT_PERMISSIONS) — every powerful API, including `payment=()`,
+// disabled in every document. That is correct everywhere EXCEPT the one
+// page whose entire job is taking a payment: GET /pay/:order_id mounts
+// Stripe's Express Checkout Element, whose Google Pay / Apple Pay buttons
+// drive the Payment Request API. Under `payment=()` the browser refuses
+// the API inside the cross-origin pay.google.com / Stripe wallet frames
+// ("Permissions policy violation: payment is not allowed in this
+// document"), so the wallet express buttons are degraded on the payment
+// page. The card form is unaffected (it doesn't use the Payment Request
+// API), which is why card captures complete while wallets don't.
+//
+// `scopedPermissionsPolicy()` returns a Permissions-Policy string for
+// `res.setHeader("permissions-policy", ...)` on the /pay route's response:
+// byte-identical to the vendored default EXCEPT the `payment=()` entry,
+// which becomes `payment=(self "https://js.stripe.com" "https://pay.google.com")`
+// — granting the feature ONLY to the same origin + the Stripe SDK frame +
+// the Google Pay frame, ONLY on that one response. setHeader OVERWRITES, so
+// the app-level strict header still governs every OTHER route. Every other
+// feature in the denylist stays `()`. Derived from the vendored
+// DEFAULT_PERMISSIONS array (the single source the app-level header is also
+// built from in `securityHeadersOpts` → the vendored default), never a
+// hand-forked copy of the list.
+
+// The allowlist that replaces `payment=()` on the pay surface: same origin
+// (the pay page's own form), the Stripe SDK frame, and the Google Pay frame
+// the Stripe Express Checkout Element spawns. Apple Pay rides the same
+// `payment` feature and needs no extra origin (Safari grants it to the
+// top-level same-origin document). Quote-wrapped per RFC 9651 structured
+// fields. Single source — every page that enables the payment feature names
+// it here.
+var _PAYMENT_ALLOWLIST = 'payment=(self "https://js.stripe.com" "https://pay.google.com")';
+
+/**
+ * Build a route-scoped Permissions-Policy string from the vendored strict
+ * denylist with the `payment` feature re-enabled for the same origin + the
+ * Stripe / Google Pay wallet frames. Every other feature is carried through
+ * verbatim as `feature=()`. Returns the string for the pay route's
+ * `res.setHeader("permissions-policy", ...)`; the app-level strict header is
+ * unchanged on every other route (setHeader overwrites this one response).
+ *
+ * Called per-response on the pay render path, so it never throws — it maps
+ * over the vendored default array and swaps the one entry, failing safe (a
+ * missing `payment` entry simply yields the strict default for that feature).
+ */
+function scopedPermissionsPolicy() {
+  return _vendoredSecurityHeaders.DEFAULT_PERMISSIONS.map(function (entry) {
+    return entry.indexOf("payment=") === 0 ? _PAYMENT_ALLOWLIST : entry;
+  }).join(", ");
+}
+
 /**
  * Build the GLOBAL rate-limit options for createApp's
  * `middleware.rateLimit`. Token-bucket so a bursty-but-bounded browsing
@@ -519,6 +572,7 @@ module.exports = {
   globalRateLimitOpts:  globalRateLimitOpts,
   mountRouteGuards:     mountRouteGuards,
   scopedCsp:            scopedCsp,
+  scopedPermissionsPolicy: scopedPermissionsPolicy,
   CSP_HOSTS:            CSP_HOSTS,
   WEBHOOK_PATHS:        WEBHOOK_PATHS,
   HEALTH_PATH:          HEALTH_PATH,

package/lib/storefront.js

@@ -12553,7 +12553,46 @@ function mount(router, deps) {
       // pay.js island load — without relaxing the app-level strict CSP that
       // governs every OTHER route. setHeader OVERWRITES the app-level header
       // for this response only.
+      //
+      // KNOWN, NON-BLOCKING Trusted Types violation on this route (operator
+      // follow-up, intentionally NOT fixed here). The app-level CSP carried
+      // through verbatim by scopedCsp keeps `require-trusted-types-for
+      // 'script'` + `trusted-types 'allow-duplicates' default`. Stripe.js v3
+      // does NOT register a named Trusted Types policy of its own; instead it
+      // expects the APPLICATION to define a `default` policy whose
+      // createScriptURL vets Stripe's own hosts (per Stripe's integration
+      // security guide). When Stripe.js dynamically injects its sub-resource
+      // <script> (the frame-spawning performance path on *.js.stripe.com), the
+      // browser refuses the TrustedScriptURL assignment because no `default`
+      // policy is registered — the console logs "This document requires
+      // 'TrustedScriptURL' assignment ... @ https://js.stripe.com/v3/". The
+      // card form is unaffected: it loads from the STATIC <script
+      // src="https://js.stripe.com/v3/"> tag, which is a direct HTML src (not
+      // a JS-driven sink), so require-trusted-types-for does not gate it —
+      // which is why card captures complete with the violation present. The
+      // blocked path is Stripe's dynamic sub-frame/3DS loader.
+      //
+      // We do NOT loosen Trusted Types to silence it. Naming a Stripe policy
+      // in the trusted-types directive does nothing (Stripe registers none);
+      // the only fix Stripe documents is the app shipping a same-origin
+      // `default` createScriptURL policy that allows js.stripe.com /
+      // *.js.stripe.com AND widening this scoped CSP's script-src/frame-src to
+      // *.js.stripe.com. A `default` TT policy is page-global (it vets EVERY
+      // TrustedScriptURL/TrustedHTML/TrustedScript sink, including any future
+      // app sink), so adopting it is a deliberate posture change, not a
+      // drive-by — left as an operator follow-up. To reproduce + verify a fix,
+      // pay with the Stripe 3-D Secure test card 4000002760003184 (forces an
+      // authentication challenge, which exercises the dynamic challenge-frame
+      // loader that trips this) and confirm the console violation is gone and
+      // the challenge frame renders.
       res.setHeader && res.setHeader("content-security-policy", securityMiddleware.scopedCsp(["stripe"]));
+      // Route-scoped Permissions-Policy that re-enables the `payment` feature
+      // for this one response (same origin + the Stripe / Google Pay wallet
+      // frames) so the Express Checkout Element's Google Pay / Apple Pay
+      // buttons can use the Payment Request API. The app-level strict denylist
+      // (payment=()) still governs every OTHER route; setHeader overwrites
+      // only this response. Every other feature stays denied.
+      res.setHeader && res.setHeader("permissions-policy", securityMiddleware.scopedPermissionsPolicy());
       // Operator trust badges at the checkout placement (container-only;
       // drop-silent → "" on any failure).
       var payTrustBadges = await _trustBadgesHtml("checkout", req);

package/package.json

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