@blamejs/blamejs-shop 0.4.6 → 0.4.7

package/CHANGELOG.md

@@ -8,6 +8,8 @@ upgrading across more than a few patches at a time.
 
 ## v0.4.x
 
+- v0.4.7 (2026-06-05) — **Payment page: Trusted Types now permits Stripe's loader through a real allowlist, and the Amazon Pay button loads.** Two payment-page fixes. The site enforces Trusted Types, and Stripe's browser library assigns script URLs without registering a policy — the console logged a TrustedScriptURL violation on every payment page, the failure class that can break a 3-D Secure challenge mid-payment. Rather than relaxing enforcement, the page now registers the default Trusted Types policy before Stripe loads: it admits script URLs from Stripe's own origins and throws for anything else, so enforcement stays on with a genuine gate. Second, the express-wallet row offered an Amazon Pay button whose frame the payment page's policy refused to load; the page's frame allowance now includes the Stripe-operated CDN that serves wallet buttons, scoped to the payment page only. Every other page keeps the strict policy unchanged. **Fixed:** *Trusted Types policy for the Stripe loader* — The payment page registers the default Trusted Types policy before the Stripe script tag, synchronously, integrity-pinned like every other script. The policy admits script URLs whose origin is js.stripe.com or a subdomain of it and throws for any other host — lookalike domains, plain http, and non-Stripe CDNs are refused. Browsers without Trusted Types are unaffected. Pages outside the payment route keep require-trusted-types-for enforcement with no registered loader policy, exactly as before. · *Express wallet buttons can load their frames* — The payment page's frame allowance adds Stripe's wallet-button CDN (b.stripecdn.com) and Stripe's dynamic subdomains (*.js.stripe.com) alongside the existing js.stripe.com and hooks.stripe.com entries, restoring the Amazon Pay express button. The allowance is scoped to the payment page; the storefront-wide policy still permits no third-party frames at all.
+
 - v0.4.6 (2026-06-05) — **Guest order pages require proof of purchase, and guests can save their order to an account in one tap.** Two changes to what happens after a guest checks out. First, the order confirmation page — which shows the buyer's name, address, and items — is no longer reachable by anyone who learns the order id. A guest order now admits exactly three readers: the browser that placed it (a sealed device cookie set at checkout, surviving the payment redirect), anyone opening the signed link in the order-receipt email (an order-scoped, expiring signed token that works on any device), and the signed-in account that owns it. Everything else sees a 404 indistinguishable from a missing order, and the reorder action is gated the same way. Second, the confirmation page now offers a guest one tap to save the order to an account: it emails a sign-in link to the address they checked out with — shown masked on screen, held only in a short-lived encrypted cookie, never written to the database — and redeeming the link creates the account if needed and attaches their guest orders by a hashed-email match. The response is identical whether or not an account already exists, the trigger is rate-limited, and a second click sends nothing. **Added:** *One-tap account setup after checkout* — A guest buyer's confirmation page offers to save the order to an account: one click emails a magic sign-in link to the checkout address (masked on screen, e.g. r***@e***.com), creating the account on redemption if none exists and linking the buyer's guest orders by hashed-email match at the moment they prove control of the inbox. Signed-in buyers never see the offer; buyers whose address already has an account get sign-in wording with the identical send path. The plaintext address lives only in an encrypted cookie for fifteen minutes — the database keeps only the one-way hash it already kept. **Changed:** *Guest order confirmation pages are access-gated* — A guest order's page requires the placing browser's sealed device cookie (set at checkout, capped to recent orders, 30-day refresh), the signed token in the order-receipt email's view-order link (order-scoped, roughly 90-day expiry, constant-time verified), or the signed-in owner. Unauthorized requests — including a signed-in customer who does not own the order — receive a 404 identical to a missing order. The reorder action carries the same gate; cancel, rating, and return actions were already owner-only. The payment-provider return flow and order analytics are unaffected: the device cookie is set before the redirect to the payment page, so the buyer lands back on their confirmation with access intact.
 
 - v0.4.5 (2026-06-05) — **One sign-in screen: passkey first, email sign-in link as the built-in fallback.** The sign-in page previously offered the passkey ceremony with the email magic-link alternative a page away behind a link. Both now live on one screen: passkey stays the primary action, and an "Email me a sign-in link" form sits inline beneath it — a plain server-rendered form that works with JavaScript disabled. The page meets failure gracefully: a browser without WebAuthn support disables the passkey button and points to the email form, and a failed or cancelled passkey ceremony scrolls the shopper to the fallback with their typed email carried over, one tap from a sign-in link instead of a dead end. Responses are identical whether or not an account exists for the address, the trigger is rate-limited, and a visitor who is already signed in is redirected to their account instead of seeing a login form. **Changed:** *Sign-in page unifies passkey and email-link paths* — Passkey remains the primary action; the email sign-in link form renders inline on the same screen when transactional email is configured, works without JavaScript, and inherits the existing magic-link token semantics unchanged (single-use, expiring). Browsers without WebAuthn support are steered to the email form up front, and any passkey ceremony failure lands the shopper on the fallback with their email pre-filled. The email form's responses do not reveal whether an address has an account, the trigger endpoint is tightly rate-limited, and signed-in visitors are redirected away from the login form.

package/lib/asset-manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "0.4.6",
+  "version": "0.4.7",
   "assets": {
     "css/admin.css": {
       "integrity": "sha384-6k53cvkRrxMgmeStLIoLjVXZQHqIJgTmv1Izd8TYhh1HOC4POgE6GCvx1bsalyEP",
@@ -37,6 +37,10 @@
       "integrity": "sha384-BjuUhbPZ18pHFMyOwT+309BEXu+VAc54RSj8lvN93jfFGDydEgmapiAOKTQM1yma",
       "fingerprinted": "js/passkey-register.02b0e196fb9608d8.js"
     },
+    "js/pay-trusted-types.js": {
+      "integrity": "sha384-jD90N8l7J3Vcu+aPSFRi6AE/5XKHQl58/avwHE9PH0mHwMavX991OCsEcznEf3n5",
+      "fingerprinted": "js/pay-trusted-types.53d0df13f9480a66.js"
+    },
     "js/pay.js": {
       "integrity": "sha384-W11JVQhv1RZq4WhsAOglu56gTZTDz1ByLd+b1HFQBCi8xGoEhJ0PZ2yI3FqbYzt6",
       "fingerprinted": "js/pay.683a905563e54a47.js"

package/lib/security-middleware.js

@@ -265,9 +265,27 @@ function securityHeadersOpts() {
 // what the provider's own CDN requires.
 var CSP_HOSTS = {
   stripe: {
-    script:  ["https://js.stripe.com"],
+    // Stripe.js v3 starts sub-frames on per-origin `*.js.stripe.com` hosts
+    // for performance (Stripe security guide), and its dynamic loader
+    // injects those sub-resource <script>s at runtime — so BOTH the apex
+    // and the wildcard must be admitted on script-src, or the
+    // TrustedScriptURL/dynamic-load path is refused (the 3DS challenge
+    // loader rides this).
+    script:  ["https://js.stripe.com", "https://*.js.stripe.com"],
     connect: ["https://api.stripe.com"],
-    frame:   ["https://js.stripe.com", "https://hooks.stripe.com"],
+    // frame-src: the apex + `*.js.stripe.com` carry the Payment Element /
+    // 3DS challenge frames; hooks.stripe.com carries redirect-style
+    // confirmations. `b.stripecdn.com` serves the Express Checkout wallet
+    // button assets (e.g. the Amazon Pay button iframe at
+    // b.stripecdn.com/stripethirdparty-srv/...) — without it the express
+    // wallet button iframe is blocked (net::ERR_ABORTED) while Link /
+    // Google Pay, which render from *.js.stripe.com, load fine.
+    frame:   [
+      "https://js.stripe.com",
+      "https://*.js.stripe.com",
+      "https://hooks.stripe.com",
+      "https://b.stripecdn.com",
+    ],
   },
   paypal: {
     script:  ["https://www.paypal.com", "https://www.paypalobjects.com"],

package/lib/storefront.js

@@ -452,8 +452,14 @@ function _islandScript(name, opts) {
   // construction at the call site, so they go in without escaping.
   var idAttr     = (opts && opts.id)     ? " id=\"" + opts.id + "\"" : "";
   var policyAttr = (opts && opts.policy) ? " data-consent-policy=\"" + opts.policy + "\"" : "";
+  // Islands `defer` by default (run after parse, in document order). The
+  // Trusted Types `default` policy is the exception: it MUST register
+  // synchronously BEFORE the parser-inserted Stripe SDK <script> executes,
+  // so `opts.sync` drops `defer` (and adds no `async`) — a classic blocking
+  // <script> that runs the instant the parser reaches it.
+  var timing = (opts && opts.sync) ? "" : " defer";
   return "<script" + idAttr + " src=\"" + _assetUrl("js/" + name) + "\"" +
-    (sri ? " integrity=\"" + sri + "\"" : "") + " defer" + policyAttr + "></script>";
+    (sri ? " integrity=\"" + sri + "\"" : "") + timing + policyAttr + "></script>";
 }
 
 // ---- announcement bar --------------------------------------------------
@@ -7170,6 +7176,11 @@ var PAY_PAGE =
   "    <button id=\"submit\" type=\"button\" class=\"btn-primary pay-card__submit\">Pay {{grand_total}}</button>\n" +
   "    <p id=\"payment-message\" class=\"pay-card__message\"></p>\n" +
   "  </div>\n" +
+  // Trusted Types `default` policy — MUST be registered before the Stripe
+  // SDK loads (emitted sync/blocking, no defer) so Stripe.js's dynamic
+  // script-URL injections (perf sub-frames + the 3DS challenge loader) pass
+  // the createScriptURL gate instead of being refused as un-typed.
+  "  RAW_PAY_TT_SCRIPT\n" +
   "  <script src=\"https://js.stripe.com/v3/\"></script>\n" +
   "  RAW_PAY_SCRIPT\n" +
   "</section>\n";
@@ -7195,6 +7206,10 @@ function renderPayPage(opts) {
       pk:                  opts.publishable_key,
       client_secret:       opts.client_secret,
       pay_script:          opts.theme.assetUrl("js/pay.js"),
+      // Trusted Types `default` policy asset — rendered (sync, no defer)
+      // BEFORE the Stripe SDK tag in pay.html so it registers the
+      // createScriptURL gate ahead of Stripe.js's first dynamic load.
+      pay_tt_script:       opts.theme.assetUrl("js/pay-trusted-types.js"),
       asset_css_main:      opts.theme.assetUrl("css/main.css"),
     });
   }
@@ -7206,7 +7221,9 @@ function renderPayPage(opts) {
     grand_total:        grandTotal,
     pk:                 opts.publishable_key,
     client_secret:      opts.client_secret,
-  }).replace("RAW_PAY_SCRIPT", _islandScript("pay.js"));
+  })
+    .replace("RAW_PAY_TT_SCRIPT", _islandScript("pay-trusted-types.js", { sync: true }))
+    .replace("RAW_PAY_SCRIPT", _islandScript("pay.js"));
   // Operator trust badges at the checkout placement (container-only — the pay
   // page isn't edge-cached). Pre-resolved + sanitized by the route; appended
   // after the pay card. Empty string when no badges / no dep.
@@ -13661,43 +13678,40 @@ function mount(router, deps) {
         res.status(503);
         return res.end ? res.end("Stripe publishable key not configured") : res.send("Stripe publishable key not configured");
       }
-      // Route-scoped CSP that admits js.stripe.com on script/connect/frame-src
-      // (and Trusted Types stays on) so the Stripe SDK + the same-origin
+      // Route-scoped CSP that admits Stripe's hosts on script/connect/frame-src
+      // (and Trusted Types stays ON) so the Stripe SDK + the same-origin
       // 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.
+      // TRUSTED TYPES, RESOLVED. The app-level CSP carried through verbatim by
+      // scopedCsp keeps `require-trusted-types-for 'script'` +
+      // `trusted-types 'allow-duplicates' default`. Stripe.js v3 registers no
+      // Trusted Types policy of its own; it expects the APPLICATION to define
+      // a `default` policy whose createScriptURL vets Stripe's hosts (Stripe
+      // security guide). The pay page now ships that policy in
+      // `pay-trusted-types.js`, emitted (sync, no defer) BEFORE the Stripe SDK
+      // tag, so when Stripe.js dynamically injects its sub-resource <script>
+      // (the perf sub-frames on *.js.stripe.com and the 3-D Secure
+      // challenge-frame loader) the browser routes the URL through the policy
+      // and admits it — instead of refusing it with "This document requires
+      // 'TrustedScriptURL' assignment". The policy throws for any non-Stripe
+      // origin, so Trusted Types stays a real gate, not a relaxation. The
+      // scoped CSP's script-src/frame-src admit both `js.stripe.com` and
+      // `*.js.stripe.com` (the sub-origins the dynamic loader uses).
+      //
+      // EXPRESS WALLET FRAMES. The scoped frame-src also admits
+      // `b.stripecdn.com`, where the Express Checkout Element loads its wallet
+      // button iframes (e.g. the Amazon Pay button at
+      // b.stripecdn.com/stripethirdparty-srv/...); without it that iframe is
+      // blocked (net::ERR_ABORTED) while Link / Google Pay, served from
+      // *.js.stripe.com, render fine.
       //
-      // 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.
+      // A live 3-D Secure path still warrants a production verification: pay
+      // with the Stripe 3DS test card 4000002760003184 (forces an
+      // authentication challenge that exercises the dynamic challenge-frame
+      // loader) and confirm the challenge frame renders with no TrustedScriptURL
+      // console violation.
       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

package/package.json

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