Vue Storefront middleware: forwarding client timezone headers to commerce backend without leaking auth headers
0 reputation · 02 Jul 2022, 20:21 UTC
0 reputation · 02 Jul 2022, 20:21 UTC
We're running Vue Storefront 2.x with the server middleware (middleware.config.js) proxying a commerce backend, and we need backend date fields — order dates, promotion start/end times — to respect each shopper's region.
The documented behavior is that the integration's axios api-client forwards cookies from the incoming request to preserve session identity, but there appears to be no built-in convention for propagating locale or timezone context (e.g., a custom X-Timezone header or Accept-Language) through the middleware to the backend. Blindly forwarding all incoming headers seems risky since it could leak or conflict with authorization headers, so we assume a whitelist approach is needed.
A second concern is SSR consistency: if timezone conversion happens only in the browser via Intl APIs, server-rendered dates may mismatch after hydration, so we're unsure whether normalization belongs in the middleware, an extension method, or the composable layer.Which headers are safe and sufficient to whitelist for regional date handling? Should conversion happen server-side in a middleware extension or client-side after hydration? And is there a documented pattern for this in the newer standalone SDK/middleware split versus older @vue-storefront/middleware versions?
31775 reputation · 02 Jul 2022, 20:43 UTC
To handle regional date fields without leaking sensitive authentication data, implement a strict whitelist in your middleware.config.js. The only headers required for regional context are Accept-Language and a custom timezone header (e.g., X-Timezone). Avoid forwarding the entire request header object, as this risks leaking Authorization tokens or internal proxy headers to the backend.
In Vue Storefront 2.x, the middleware acts as the bridge. To ensure the commerce backend receives the shopper's region, follow these steps:
Accept-Language and X-Timezone. Ensure that the existing cookie-forwarding logic remains untouched, as this is required for session identity.Intl.DateTimeFormat().resolvedOptions().timeZone and attach it to the X-Timezone header for all outgoing requests.X-Timezone and apply the offset to date fields before returning the JSON response.Performing date conversion only in the browser leads to hydration mismatches because the server renders a default timezone (often UTC) while the client renders the local time. To prevent this, normalization must happen server-side.
The middleware should extract the X-Timezone header from the incoming request and pass it to the backend. The backend then returns the date already formatted for that timezone. This ensures the HTML generated during SSR matches the state the client expects upon hydration.
To verify the implementation without risking production data, use a mock server or proxy logs to inspect the request flow:
Authorization headers are absent from the middleware-to-backend request, while X-Timezone is present.X-Timezone string against a known list of IANA timezones to prevent malformed input from causing calculation errors.Diagnostic Detail Required: Are you using the integrated @vue-storefront/middleware package or a custom Node.js proxy? The specific syntax for header whitelisting differs slightly between the built-in config and a manual http-proxy-middleware setup.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.