@blamejs/blamejs-shop 0.4.4 → 0.4.5

package/CHANGELOG.md

@@ -8,6 +8,8 @@ upgrading across more than a few patches at a time.
 
 ## v0.4.x
 
+- 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.
+
 - v0.4.4 (2026-06-05) — **Placement-targeted promo banners with scheduling, audiences, and click tracking.** Operators can now run placement-specific marketing banners alongside the existing sitewide announcement bar. A banner targets one of six placements — the top strip, the homepage hero, the product-page side, the cart side, the empty-search state, or the footer — with a schedule window, an audience (everyone, signed-in, or guests), one of four visual themes, a priority for choosing among overlapping banners, and a call-to-action whose clicks and impressions are counted. Banners are authored, edited, archived, and restored at /admin/promo-banners, render identically on edge-cached and container-rendered pages, and the click counter works on both. Separately, the edge's Permissions-Policy header now denies the same full directive set as the container's, closing a drift where nine newer denials were missing from edge-served pages, and a parity test keeps the two substrates locked together from here on. The vendored blamejs framework is refreshed from v0.14.21 to v0.14.22. **Added:** *Promo banners* — Define a banner with a slug, placement, headline, optional body, call-to-action, audience, schedule window, theme, and priority; the highest-priority active banner per placement renders. Operator-authored text is escaped at render on both substrates. Clicks route through a counting redirect that works whether the page came from the edge cache or the container; impressions count on container renders. The admin screen covers the full lifecycle including archive and restore, and the same operations are available as JSON under the admin bearer token. The sitewide announcement bar is unchanged and remains the simpler always-on notice strip — if you define a top-strip promo banner while an announcement is active, both render, so pick one for the top of the page. **Fixed:** *Edge pages deny the same Permissions-Policy directives as container pages* — The edge-served pages' Permissions-Policy was missing nine newer directives the container already denied (among them shared-storage, run-ad-auction, join-ad-interest-group, and smartcard). Both substrates now send the identical deny-all list, and a test fails the build if a framework update ever grows one list without the other.
 
 - v0.4.3 (2026-06-05) — **Passkey sign-in works again: WebAuthn is permitted on the pages that host it.** The framework's deny-all Permissions-Policy disabled the browser's WebAuthn API everywhere — including the sign-in page's own top-level document — so attempting a passkey sign-in failed with the browser reporting that publickey-credentials-get is not enabled. The policy now permits exactly the WebAuthn capability each ceremony page needs: credential assertion on the sign-in page, credential creation on the registration and passkey-management pages, both scoped to the page's own origin. Every other page keeps the strict deny-all policy, and every other feature (camera, microphone, geolocation, payment outside the payment page) remains denied on the ceremony pages too. **Fixed:** *Passkey ceremonies are no longer blocked by Permissions-Policy* — Sign-in carries publickey-credentials-get=(self); registration and passkey management carry publickey-credentials-create=(self). The allowance is scoped per route following the same pattern the payment page uses, grants apply only to the page's own origin (no cross-origin delegation), and unrecognized feature requests relax nothing. Tests assert the exact header tokens per route and that unrelated pages still deny both WebAuthn features.

package/lib/asset-manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "0.4.4",
+  "version": "0.4.5",
   "assets": {
     "css/admin.css": {
       "integrity": "sha384-6k53cvkRrxMgmeStLIoLjVXZQHqIJgTmv1Izd8TYhh1HOC4POgE6GCvx1bsalyEP",
@@ -30,8 +30,8 @@
       "fingerprinted": "js/passkey-add.b535e6a3eef4514e.js"
     },
     "js/passkey-login.js": {
-      "integrity": "sha384-AbMxT4s0paFnZsEfAHfcpbS2ZRSmZ9KPnttEBy9SvWErBX3U+LhoeYYN7Nm3Y8AX",
-      "fingerprinted": "js/passkey-login.90c13d7c0d8667e2.js"
+      "integrity": "sha384-YcFe/H5GiEIXJ3bvx4RMUKtKwW249rKWyOYbd6xRcDrlAhDeDpt7HGZYPs+R6yWO",
+      "fingerprinted": "js/passkey-login.41da9ad7da816e97.js"
     },
     "js/passkey-register.js": {
       "integrity": "sha384-BjuUhbPZ18pHFMyOwT+309BEXu+VAc54RSj8lvN93jfFGDydEgmapiAOKTQM1yma",

package/lib/storefront.js

@@ -9129,6 +9129,17 @@ function _setLocaleCookie(res, locale) {
 
 // ---- account-page renderers --------------------------------------------
 
+// One sign-in screen offering BOTH passwordless paths. The passkey form is
+// the primary action (a JS island posts the WebAuthn ceremony to
+// /account/passkey/login-*). The email magic-link is rendered inline as a
+// SERVER-RENDERED form that POSTs to /account/login/link — it works with
+// JavaScript disabled and is the always-available backup so a browser
+// without WebAuthn (or a failed ceremony) is never a dead end. The two
+// forms are independent <form> elements: the no-JS fallback never depends
+// on the island. The magic-link block only renders when the operator has
+// wired the customer-portal primitive AND a transactional mailer (the GET
+// route sets `magic_link_enabled`); absent it, the page degrades to the
+// passkey path with no broken affordance.
 var ACCOUNT_LOGIN_PAGE =
   "<section class=\"auth-page\">\n" +
   "  <div class=\"auth-card\">\n" +
@@ -9149,6 +9160,23 @@ var ACCOUNT_LOGIN_PAGE =
   "  RAW_LOGIN_SCRIPT\n" +
   "</section>\n";
 
+// The inline email magic-link path on the unified login screen. A distinct
+// server-rendered <form> (its own email field) that POSTs to
+// /account/login/link with no JavaScript — the `_injectCsrfFields` wrap
+// chokepoint stamps the `_csrf` token automatically (the action is not an
+// EDGE_POST_PATHS prefix), so a no-JS browser submits an accepted token.
+// `data-passkey-fallback` lets passkey-login.js point a user here in one tap
+// when WebAuthn is unsupported or the ceremony fails — no dead end.
+var LOGIN_MAGIC_INLINE =
+  "<div class=\"auth-oauth\" data-passkey-fallback>" +
+    "<div class=\"auth-oauth__divider\"><span>or</span></div>" +
+    "<p class=\"auth-card__lede\">No passkey on this device? We'll email you a single-use sign-in link.</p>" +
+    "<form method=\"post\" action=\"/account/login/link\" class=\"form-stack auth-form auth-form--magic\">" +
+      "<div class=\"form-row\"><label class=\"form-field\"><span class=\"form-field__label\">Email</span><input type=\"email\" name=\"email\" id=\"magic-email\" required autocomplete=\"email\"></label></div>" +
+      "<div class=\"form-actions\"><button type=\"submit\" class=\"btn-secondary auth-form__submit\">Email me a sign-in link</button></div>" +
+    "</form>" +
+  "</div>";
+
 var LOGIN_ERROR_MESSAGES = {
   oauth:           "We couldn't complete that sign-in. Please try again.",
   "email-conflict": "That email already has an account — sign in with your passkey instead.",
@@ -9173,9 +9201,9 @@ function renderAccountLogin(opts) {
   var errHtml = (opts.error && LOGIN_ERROR_MESSAGES[opts.error])
     ? "<p class=\"auth-form__message auth-form__message--err\">" + b.template.escapeHtml(LOGIN_ERROR_MESSAGES[opts.error]) + "</p>"
     : "";
-  var magicHtml = opts.magic_link_enabled
-    ? "<p class=\"auth-card__alt\"><a href=\"/account/login/link\">Email me a sign-in link instead →</a></p>"
-    : "";
+  // Render the email-link path INLINE (a working no-JS form), not as a link
+  // to a separate page, so both passwordless paths live on one screen.
+  var magicHtml = opts.magic_link_enabled ? LOGIN_MAGIC_INLINE : "";
   var body = ACCOUNT_LOGIN_PAGE
     .replace("RAW_LOGIN_OAUTH", oauthHtml)
     .replace("RAW_LOGIN_MAGIC", magicHtml)
@@ -13688,6 +13716,19 @@ function mount(router, deps) {
     }
 
     router.get("/account/login", async function (req, res) {
+      // An already-signed-in visitor has no business on the sign-in screen —
+      // send them to their account instead of re-rendering a login form
+      // (mirrors the /account guard's auth read + vault-not-configured catch).
+      var signedIn;
+      try { signedIn = _currentCustomer(req); }
+      catch (e) {
+        if (e && e.code === "vault/not-initialized") return _serviceUnavailable(res, "auth not configured");
+        throw e;
+      }
+      if (signedIn) {
+        res.status(303); res.setHeader && res.setHeader("location", "/account");
+        return res.end ? res.end() : res.send("");
+      }
       var cartCount = await _cartCountForReq(req);
       var url = req.url ? new URL(req.url, "http://localhost") : null;
       // Login captcha is opt-in (CAPTCHA_GATE_LOGIN). The widget + the scoped

package/package.json

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