1

Wondering, has anyone at all managed to make Next.js Multisite add-on work well? I spent lots of time trying to overcome a CORS issue, which I don't know how to solve. There is a troubleshooting guide, which is not very descriptive on resolution, it says what we should do at a high level without explaining how exactly. It says:

Ensure all domains used in your multisite configuration have access to the domain used for the PUBLIC_URL variable, for example, by using the Access-Control-Allow-Origin header.

It is crystal clear we must allow CORS for all the secondary domains, but how exactly to do that? Where in the code should we pass Access-Control-Allow-Origin? The only place search finds is within src\sxastarter\src\lib\next-config\plugins\cors-header.js but that one is used for different purposes -CM editors. Just for the sake of a test, I tried putting * but still with no luck.

It is possible to make it work remotely in Vercel and XM Cloud, by modifying next.config.js file to something as below:

{
        // matching all routes
        source: '/:path*',
        headers: [
          { key: 'Access-Control-Allow-Credentials', value: 'true' },
          { key: 'Access-Control-Allow-Origin', value: '*' },
          { key: 'Access-Control-Allow-Methods', value: 'GET,OPTIONS,PATCH,DELETE,POST,PUT' },
          { key: 'Access-Control-Allow-Headers', value: '*' },
        ],
}

and introducing an additional env variable for Rendering Host (XMC_DEFAULT_RH) then manipulating publicUrl variable based on the value: assetPrefix: process.env.XMC_DEFAULT_RH === "true" ? publicUrl : undefined. It specifies the full hostname if it is XM Cloud (editors) or not (leaving relative path only) if it comes from Vercel.

The problem is: how to make the same work locally in the containers? Since both "published website" and pages under editors run within the same environment (in fact a local container) serving both EE and direct site requests, there is no way to distinguish that. So need to find another creative way of doing that.

4
  • What is the actual error you are getting? As in, what assets are being blocked? What is the expectation?
    – Richard Seal
    Nov 28, 2023 at 19:41
  • What I am getting in result is multiple websites DO work at the same rendering host, which is the desired result. I can prove that by turning off other RHs leaving only one that is being shared between sites. So far so good. The problem comes immediately after page loads, all the sites except the main one that matches PUBLIC_URL hostname go into a never-ending loop of redirects to itself. Dev Tools expose the problem - and it is CORS. That is because PUBLIC_URL is used for the cors and other domains not. Nov 28, 2023 at 20:07
  • More diving into a problem explains that when RH is being used - assetPrefix should be a full path with a hostname and when editors operate - relative. Please note that all the above relates only to LOCAL development in containers when RH and EH operate from the same container. Nov 28, 2023 at 20:12
  • I had the same issue - I fixed it by just setting the assetPrefix to undefined in next config. The assets are then downloaded using the current domain with no issues. Dec 14, 2023 at 8:59

1 Answer 1

0

For anyone still looking to find a fix for this. Sitecore support team has suggested to add traefik rules for newly added hostnames. You can do this in your docker compose override yml file. These rules should be added to rendering container. This works for me!

- "traefik.http.middlewares.rendering-headers.headers.accesscontrolallowmethods=GET,POST,OPTIONS"
- "traefik.http.middlewares.rendering-headers.headers.accesscontrolalloworiginlist=${RENDERING_HOST}, <extra hostnames>"
- "traefik.http.routers.rendering-secure.middlewares=rendering-headers"

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.