SamVerschueren
commented
1 year ago Hi @nicksrandall 👋 . It is true that WebContainer requires cross-origin-isolation. I wrote more about the mechanics behind it in a blogpost a while ago. That blogpost also shows how you can fix CORS if you own all the resources that your website loads.
Serving, or proxying, the assets yourself doesn't fix this. The reason is that we heavily rely on SharedArrayBuffer and Atomics, which means that the page MUST BE cross-origin isolated. The only way to do that today is by setting the COEP header to require-corp.
One way that would make this process easier is by using COEP: credentialless. This is already supported since Chrome 96, but not yet (I believe?) for Firefox.
You are correct that Nodebox does not require COEP headers, because they don't rely on SharedArrayBuffer or Atomics. However, the downside is that they do not support spawning child processes synchronously for instance. But there are more features that can only be supported by using SABs and Atomics.
I hope my answer gives you a better overview of the bits and pieces. We need the COEP header, not to annoy you are anyone trying to use WebContainer, but because it's required for the tech we use under the hood.
nicksrandall
RandomByte
Because webcontiners require "require-corp" embedder policy, it can cause a lot of CORs issues. One way to get around it would be to allow users to host the service on their own domain.
Describe the solution you'd like: I'd like to have an option to override the domain used by iframe.
Describe alternatives you've considered: COEP is not required by Codesandbox Nodebox so I could try that?
Additional context If this option was available, I would likely setup a reverse proxy at my domain to proxy the webcontainer service so that the iframe could share a domain with the rest of my content.