@doswiftly/storefront-operations 11.4.0 → 12.0.0

package/AGENTS.md

@@ -27,7 +27,7 @@ consumer's `codegen.ts` references this package's `.graphql` files as
 live in the consumer's repo.
 
 <!-- AUTOGEN:STATS:BEGIN — auto-regenerated, do not edit by hand -->
-- **Schema version**: 11.4.0
+- **Schema version**: 12.0.0
 - **Queries**: 49
 - **Mutations**: 40
 - **Fragments**: 100

package/CHANGELOG.md

@@ -1,5 +1,86 @@
 # Changelog
 
+## 12.0.0
+
+### Major Changes
+
+- 2ff6b16: **BREAKING**: `Product.requiresRecipientInfo` field has been removed from the storefront GraphQL schema. Every paid gift card line now guarantees email delivery — to the recipient when your storefront captured one, otherwise to the buyer as fallback.
+
+  ### Why removed
+
+  The field exposed a per-product merchant toggle intended to gate whether your storefront should collect gift card recipient info (email, name, message) at checkout. In practice the toggle did not change actual delivery behaviour — every storefront ended up deciding on its own whether to render a recipient form, and the platform sent emails based solely on whether per-line recipient data was present. Merchants saw an admin control that had no effect downstream, so it has been removed in favour of an explicit storefront-driven model.
+
+  ### New model — storefront-driven recipient mode
+
+  Common e-commerce convention for gift card flow:
+  1. **Your storefront opts in**: render a recipient form on PDP / cart drawer for any cart line where `product.type === 'GIFT_CARD'`. Call `cartUpdateGiftCardRecipient({ cartId, lineItemId, recipientEmail, recipientName?, message? })` per line where the buyer fills it in.
+  2. **Your storefront opts out**: skip the mutation entirely. Gift cards still ship — the platform emails the code to the buyer (the same email used at checkout) as a fallback.
+
+  Every paid gift card is now guaranteed to land in someone's inbox — either the explicit recipient (when collected) or the buyer (fallback). Previously, missing recipient data caused a silent email skip, leaving customers without their codes.
+
+  ### Migration
+
+  If your storefront was reading `Product.requiresRecipientInfo` to conditionally show a recipient form, replace the gate with a simple product type check:
+
+  ```diff
+  - {product.requiresRecipientInfo && (
+  + {product.type === 'GIFT_CARD' && (
+      <GiftRecipientForm cartId={cartId} lineItemId={lineItemId} />
+    )}
+  ```
+
+  If you were not reading the field, no storefront changes are required — the fallback ensures gift card delivery works out of the box.
+
+  See [cart docs — Karty podarunkowe — dostawa kodu](https://docs.doswiftly.pl/storefront-developer/sdk/cart#karty-podarunkowe--dostawa-kodu) for the full delivery semantics, a cart-structuring table (one gift card for self vs N gift cards for N recipients), and a recipient form example.
+
+## 11.5.0
+
+### Minor Changes
+
+- 190fd9d: Version sync with `@doswiftly/storefront-sdk` (linked release pair). No operations file changes — `OrderByToken` query and `Order.accessToken` field were shipped in the previous version (11.4.0); this bump keeps the operations package version aligned with the SDK release that now selects `accessToken` in its built-in `Order` fragment for `cartComplete`.
+
+  If you already use `@doswiftly/storefront-operations` for codegen, no regeneration is required (`queries.graphql` and `fragments.graphql` are unchanged). The companion `@doswiftly/storefront-sdk` upgrade is where the actual behavior change lands (see that changelog entry).
+
+- e6c80ce: Auth route handlers (`createSetTokenHandler`, `createClearTokenHandler`, `createWhoamiHandler`) now accept an optional `isTrustedOrigin` predicate. This unblocks the BFF auth flow when the storefront runs behind a reverse proxy (DoSwiftly hosting, Vercel, custom edge proxy) that rewrites or strips the `Host` header — since 11.3.0 the strict `Origin host = Host` comparison returned 403 for every login, logout, and page-load hydration in that topology, leaving the auth cookie unset and every auth-gated route redirecting to login.
+
+  ### Fix
+
+  Each handler accepts a new `isTrustedOrigin` callback:
+
+  ```ts
+  type OriginValidator = (ctx: {
+    origin: string;
+    originHost: string;
+    request: Request;
+  }) => boolean | Promise<boolean>;
+  ```
+
+  When the predicate returns truthy the strict `Origin host = Host header` comparison is bypassed; when it returns falsy (or is not configured) the existing strict check applies. A thrown predicate fails closed — the error is logged and the strict check applies as if the predicate returned `false`.
+
+  Two pre-built predicates are exported:
+  - `trustedForwardedHostValidator` — passes when `Origin host` equals `X-Forwarded-Host` (falling back to `X-Original-Host`). Use this when a reverse proxy you control sets one of those headers per request. The DoSwiftly hosting platform and Vercel both qualify.
+  - `originAllowlistValidator(['https://shop.example.com', 'other-shop.example'])` — passes when `Origin` matches an entry in a static list. Useful when one storefront is hosted on multiple hostnames (custom apex + platform subdomain) and you do not want to depend on forwarded-host headers.
+
+  ### Upgrade impact
+  - New storefronts scaffolded via `doswiftly init` ship with `isTrustedOrigin: trustedForwardedHostValidator` configured by default.
+  - Existing storefronts using the SDK behind a reverse proxy need a 3-line change to each route handler under `app/api/auth/`:
+    ```ts
+    import {
+      createSetTokenHandler,
+      trustedForwardedHostValidator,
+    } from "@doswiftly/storefront-sdk";
+    export const POST = createSetTokenHandler({
+      isTrustedOrigin: trustedForwardedHostValidator,
+    });
+    ```
+  - Storefronts deployed without a reverse proxy (single-tier hosting where the Next.js process receives traffic directly) need no changes — the default strict check still works because the Host header arrives intact.
+
+  ### Security
+
+  The predicate is invoked AFTER the Origin header is parsed (rejecting malformed origins) and BEFORE the strict Host comparison. Forwarded-host validation is safe because the trusted intermediary overwrites those headers on every inbound request (`headers.set(...)`, not `append`), so an attacker cannot forge them via a browser `fetch()` — browsers cannot set `X-Forwarded-*` from JavaScript (they are forbidden request headers per the fetch spec).
+
+  Defense-in-depth layers continue to apply: CORS preflight at the backend, `SameSite=Lax` on the auth cookie, `HttpOnly` + `Secure` cookie attributes, and the strict Origin URL parse (still rejects malformed origin and the `?host=trusted` query-string bypass).
+
 ## 11.4.0
 
 ### Minor Changes

package/fragments.graphql

@@ -154,7 +154,6 @@ fragment ProductBase on Product {
   descriptionHtml
   stockTotal
   type
-  requiresRecipientInfo
   visibility
   attributeSetId
   createdAt

package/llms-full.txt

@@ -1,6 +1,6 @@
 # DoSwiftly Storefront Operations — Full Reference
 
-> Schema version: **11.4.0**
+> Schema version: **12.0.0**
 > 49 queries · 40 mutations · 100 fragments
 
 Auto-generated from `.graphql` source files. Do not edit by hand — this file is
@@ -2602,7 +2602,6 @@ fragment ProductBase on Product {
   descriptionHtml
   stockTotal
   type
-  requiresRecipientInfo
   visibility
   attributeSetId
   createdAt

package/operations.json

@@ -1,5 +1,5 @@
 {
-  "schemaVersion": "11.4.0",
+  "schemaVersion": "12.0.0",
   "queries": [
     {
       "name": "Shop",
@@ -1932,7 +1932,7 @@
       "fragmentRefs": [
         "ProductCard"
       ],
-      "body": "fragment ProductBase on Product {\n  ...ProductCard\n  description\n  descriptionHtml\n  stockTotal\n  type\n  requiresRecipientInfo\n  visibility\n  attributeSetId\n  createdAt\n  updatedAt\n}",
+      "body": "fragment ProductBase on Product {\n  ...ProductCard\n  description\n  descriptionHtml\n  stockTotal\n  type\n  visibility\n  attributeSetId\n  createdAt\n  updatedAt\n}",
       "onType": "Product"
     },
     {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@doswiftly/storefront-operations",
-  "version": "11.4.0",
+  "version": "12.0.0",
   "description": "GraphQL operations for DoSwiftly Storefront - SSOT from backend",
   "homepage": "https://doswiftly.pl",
   "publishConfig": {

package/schema.graphql

@@ -4083,9 +4083,6 @@ type Product implements Node {
   """Similar products recommendations"""
   recommendations(first: Int = 4): ProductRecommendations
 
-  """Whether storefront checkout requires recipient data for this product"""
-  requiresRecipientInfo: Boolean!
-
   """Number of reviews"""
   reviewCount: Int