⚠️ No Changeset found

Latest commit: ee5532c

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

✅ Deploy Preview for module-federation-docs ready!

Name	Link
🔨 Latest commit	ee5532c
🔍 Latest deploy log	https://app.netlify.com/sites/module-federation-docs/deploys/67254fba2afe5000083fef08
😎 Deploy Preview	https://deploy-preview-3108--module-federation-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

hmm return new Function('return this') is for solving micro-fe sandbox issue , so it can not be changed , but i think we can solve CSP by other way

I see the pr not remove new Function(return this) , so how about this :

export const nativeGlobal: typeof global = (() => {
  try {
    return new Function('return this')();
  } catch {
    return this || globalThis || window
  }
})() as typeof global;

That wouldn't solve the original issue unfortunately. As long as the code tries to evaluate new Function('return this')(), that will be a CSP violation and therefore will be reported by certain tools.
The reason why the webpack runtime doesn't have the same issue is that it doesn't attempt to evaluate new Function('return this')() as long as there's a valid globalThis.

would it be possible to detect the if the sandboxing issue that you mentioned is present and run the new Function('return this')() conditionally based on that?

Eval try catch should work tho. Pretty sure someone else had same problem and I just wrapped it in catch and it worked

Or you can instead check for webpack_require.g if that exists call the runtime function from webpack else run our own fallbacks when outside of webpack

Try-catch works in the sense that the code runs, but for all sites with a Content Security Policy, it logs an error to the console and sends a Content Security Policy report for every single user that loads the site. This leads to an incredible amount of CSP report spam to whichever solution you use to aggregate these reports and detect XSS attacks.

eval and similar functions that can execute arbitrary strings containing code are blocked by CSP by default because they're large vectors for Cross-Site Scripting (XSS) attacks. It is possible to enable them again with the unsafe-eval directive, but as should be clear from the name, that's considered unsafe and would not be acceptable to most people who deploy a CSP.

The best solution for us would be any solution that doesn't try running eval at all in browsers. (CSP's do not apply outside browsers, for example in Node.js.)

Yeh i went and read the Chromium issue about this. Catch works but still throws.

Best option would be to try require.g to use webpacks runtime module, if no webpack runtime, then ours kicks in

I have this exact issue, and since it's the host that controls the CSP we can't do anything about it (we just deploy the micro frontend). I'm using the @module-federation/vite plugin to build, so the __webpack_require__.g runtime won't exist.

It would be great if the implementation could not attempt to eval. According to the host administrator, in production it would not be able to load the script because of the unsafe-eval rule. So currently we can't use module-federation/core or module-federation/vite because of this.

I also think the best bet is to try and figure out if in sandbox and then run the unsafe eval code like described here #3108 (comment)

would it be possible to detect the if the sandboxing issue

if this is not done easily, another option could be to make it configurable whether the eval is attempted here? That could solve the CSP issue for both our usecase (rsbuild) and for vite

You can check the typeof webpack require. If it exists, use require.g if it exists.

Or check if it's webpack; else if it's vite, lose the sandbox prevention.

I have pushed an update to this PR, hows that?

export const nativeGlobal: typeof global = (() => {
  //@ts-ignore
  if (typeof __webpack_require__ !== 'undefined') {
    //@ts-ignore
    if (__webpack_require__.g) {
      //@ts-ignore
      return __webpack_require__.g;
    }
    try {
      return new Function('return this')();
    } catch (e) {
      if (typeof window === 'object') return window;
      if (typeof globalThis === 'object') return globalThis;
    }
  } else {
    if (typeof globalThis === 'object') return globalThis;
    try {
      return this || new Function('return this')();
    } catch (e) {
      if (typeof window === 'object') return window;
    }
  }
})() as typeof global;

vite users could also always just set window.webpack_require.g = window

how about use document.defaultView https://developer.mozilla.org/en-US/docs/Web/API/Document/defaultView

This attr can help get real window , and no csp problem , for node env , we will use catch globalThis

#3163

how about use document.defaultView https://developer.mozilla.org/en-US/docs/Web/API/Document/defaultView

This attr can help get real window , and no csp problem , for node env , we will use catch globalThis

#3163

how about use document.defaultView https://developer.mozilla.org/en-US/docs/Web/API/Document/defaultView

Nice find

Got fixed in #3163 - thanks for the help!