johnboxall
commented
6 months ago A specific case where it is useful to have the "shopper" facing host is when doing CORS – you might want to decide whether to respond with Access-Control-Allow-Origin headers based on the requested host and to do that, you'd need the origin host.
To implement X-Forwarded-Host in user space, you can:
- Configure your Stacked CDN to add the
X-Forwarded-Hostheader. Most CDN provide rules to allow you to do this, for example in CloudFlare, you can use Transform rules to dynamically add the header. - Enable cookies on your MRT environment. This is required to forward all HTTP request headers to the App Server.
- Update your
request-processor.jsto grab theX-Forwarded-Hostheader and add it to the request class. This is required to make the cache key vary this header. - Update
ssr.jsto use the header!
// request-processor.js
// 1️⃣ Grab the shopper facing host and put it in the request class to vary cache keys by it.
export const processRequest = ({setRequestClass, headers, path, querystring}) => {
const host = headers.getHeader('x-forwarded-host')
setRequestClass(new URLSearchParams({host}))
return { path, querystring }
}// app/ssr.js
// 2️⃣ Dig out the value. Use it however you want to vary responses!
app.get('/', (req, res) => {
res.json({host: req.get('x-forwarded-host'})
})
drewzboto
mgalassi
When a CDN like eCDN is stacked on top of PWA Kit / MRT, the app may be unaware of the origin that the shoppers browser has landed on. This can result in:
For the purposes of describing the problem, lets imagine a stacked CDN with the domain
www.example.comand a MRT environment with the domainexample-production.mobify-storefront.comin a stacked setup:Within the PWA Kit, the
getAppOriginutility function andprocess.env.APP_ORIGINenvironment variable are used to help construct URLs used to make requests both in browser and on MRT:https://github.com/SalesforceCommerceCloud/pwa-kit/blob/51bf787c046d7d8d53cb97d21bb6a79e5bc20c60/packages/pwa-kit-react-sdk/src/utils/url.js#L21-L35 https://github.com/SalesforceCommerceCloud/pwa-kit/blob/51bf787c046d7d8d53cb97d21bb6a79e5bc20c60/packages/pwa-kit-runtime/src/ssr/server/build-remote-server.js#L140
They are set to
process.env.EXTERNAL_DOMAIN_NAME, which comes from a MRT environment's external domain (eg.example-production.mobify-storefront.com)In a stacked setup, this is the wrong domain for building client side absolute URLs.
The browser's origin will be
www.example.com, but requests will end up being routed toexample-production.mobify-storefront.com, which will result in CORS issues.There are a few potential user-space work arounds today:
1️⃣ Make the MRT env accept requests on the same domain as the CDN
www.example.com)www.example.com. At this point, the MRT env will not be directly accessible from the browser as the DNS entry forwww.example.comwill point to the CDN.example-production-cdn.mobify-storefront.comwith HTTPHost: www.example.com.2️⃣ Static Configuration
www.example.comdomain.getAppOrigin()to make requests, use the domain from the config files..3️⃣ Dynamic Configuration
x-forwarded-hostHTTP request header.X-Forwarded-Host: www.example.comin requests to MRT.getAppOrigin(), use this forwarded value to make requests client side. The request class is available via thewindow.Progressiveglobal object.4️⃣ Use relative URLs in browser
One other solution that may work is to use relative URLs when requests are being made to proxies in browser.
It would seem useful to have first class support for one of these options.
When we think about "desirable qualities" of a solution ... ideally: