@doswiftly/storefront-operations 11.4.0 → 11.5.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/AGENTS.md +1 -1
- package/CHANGELOG.md +48 -0
- package/llms-full.txt +1 -1
- package/operations.json +1 -1
- package/package.json +1 -1
package/AGENTS.md
CHANGED
|
@@ -27,7 +27,7 @@ consumer's `codegen.ts` references this package's `.graphql` files as
|
|
|
27
27
|
live in the consumer's repo.
|
|
28
28
|
|
|
29
29
|
<!-- AUTOGEN:STATS:BEGIN — auto-regenerated, do not edit by hand -->
|
|
30
|
-
- **Schema version**: 11.
|
|
30
|
+
- **Schema version**: 11.5.0
|
|
31
31
|
- **Queries**: 49
|
|
32
32
|
- **Mutations**: 40
|
|
33
33
|
- **Fragments**: 100
|
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,53 @@
|
|
|
1
1
|
# Changelog
|
|
2
2
|
|
|
3
|
+
## 11.5.0
|
|
4
|
+
|
|
5
|
+
### Minor Changes
|
|
6
|
+
|
|
7
|
+
- 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`.
|
|
8
|
+
|
|
9
|
+
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).
|
|
10
|
+
|
|
11
|
+
- 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.
|
|
12
|
+
|
|
13
|
+
### Fix
|
|
14
|
+
|
|
15
|
+
Each handler accepts a new `isTrustedOrigin` callback:
|
|
16
|
+
|
|
17
|
+
```ts
|
|
18
|
+
type OriginValidator = (ctx: {
|
|
19
|
+
origin: string;
|
|
20
|
+
originHost: string;
|
|
21
|
+
request: Request;
|
|
22
|
+
}) => boolean | Promise<boolean>;
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
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`.
|
|
26
|
+
|
|
27
|
+
Two pre-built predicates are exported:
|
|
28
|
+
- `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.
|
|
29
|
+
- `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.
|
|
30
|
+
|
|
31
|
+
### Upgrade impact
|
|
32
|
+
- New storefronts scaffolded via `doswiftly init` ship with `isTrustedOrigin: trustedForwardedHostValidator` configured by default.
|
|
33
|
+
- Existing storefronts using the SDK behind a reverse proxy need a 3-line change to each route handler under `app/api/auth/`:
|
|
34
|
+
```ts
|
|
35
|
+
import {
|
|
36
|
+
createSetTokenHandler,
|
|
37
|
+
trustedForwardedHostValidator,
|
|
38
|
+
} from "@doswiftly/storefront-sdk";
|
|
39
|
+
export const POST = createSetTokenHandler({
|
|
40
|
+
isTrustedOrigin: trustedForwardedHostValidator,
|
|
41
|
+
});
|
|
42
|
+
```
|
|
43
|
+
- 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.
|
|
44
|
+
|
|
45
|
+
### Security
|
|
46
|
+
|
|
47
|
+
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).
|
|
48
|
+
|
|
49
|
+
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).
|
|
50
|
+
|
|
3
51
|
## 11.4.0
|
|
4
52
|
|
|
5
53
|
### Minor Changes
|
package/llms-full.txt
CHANGED
package/operations.json
CHANGED