but when I run build file in local, it gives me the compileError like this
Uncaught (in promise) CompileError: WebAssembly.instantiate(): Refused to compile or instantiate WebAssembly module because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'self'"
And npm run build, I checked index.thml file in build file, unsafe-eval is there , same with the above code. but when I run build file , it still gives me the same error. So UseGLTF canât load the model. I was wondering how I could solve this Content Security Policy for useGLTF. Thanks in advance.
Could you show me where I should add this CSP. I added this in meta tag in index.html, build it again, but it still no unsafe-eval. and I try to use the code below:
The error above has a different message, and mentions different rules that must be added to your CSP:
style-src 'self' 'unsafe-inline';
In general when adding a CSP, youâll get a lot of these errors, and you need to read each one to see what is missing.
The later screenshot is of the HTTP Response Headers â if youâre using a <meta /> tag for the CSP then it will not appear in that area, only in the HTML. You can choose whether to specify the CSP with HTTP Response Headers or with a <meta /> tag.
Youâll have to identify what code or URL breaks the CSP â it could be any number of causes. If you try loading a glTF model without draco compression, does that work?
Yes, when I disable Draco and MeshOptDecoder, this indeed work. But, especially in case of an e-commerce that makes it pretty much obsolete without any compression. I am a beginner so might miss something âŚ
These decoders require WebAssembly, and it looks like a CSP will block WebAssembly unless unsafe-eval is enabled. Thereâs a proposal to improve how CSP handles this but Iâm not sure of the status on that proposal.
In the meantime, itâs theoretically possible to compile Draco or Meshopt decoders (from source C/C++) to JavaScript, but these projects are outside the scope of the three.js project, and I donât know how easy or difficult that would be.
Finally, the Meshopt library includes a slower plain-JS reference decoder:
It should be possible to use that instead of the WASM decoder. In plain three.js youâd do that with the loader.setMeshoptDecoder( ... ) function, Iâm not sure about useGLTF.
This was incredibly helpful. Thank you a lot for your inputs.
As you said, I did implement the apparently slower MeshOptDecoder in plain JS.
I also had to add this line somewhere in my useGLTF hook to use only the JS Draco decoder.
âdracoLoader.setDecoderConfig({type: âjsâ}); // Use JavaScript implementationâ
This got rid of the unsafe-eval problem, but introduced a new one related to the CSP:
âRefused to create a worker from âblob:â because it violates the following Content Security Policy directive: âdefault-src âselfâ ânonce-8472a3a8e8533297d4807fe73f0fda79â â. Note that âworker-srcâ was not explicitly set, so âdefault-srcâ is used as a fallback.â
âRefused to create a worker from âblob:http://localhost:3000/f5a17f0e-3c0b-4584-a35a-1d310442d4eeâ because it violates the following Content Security Policy directive: âdefault-src âselfâ ânonce-8472a3a8e8533297d4807fe73f0fda79â https://cdn.shopify.comhttps://shopify.comâ. Note that âworker-srcâ was not explicitly set, so âdefault-srcâ is used as a fallback.â
It is pointing the DRACOLoader.js file which apparently create a worker. (Not sure I understand all of this fully, if any.)
âconst worker2 = new Worker(this.workerSourceURL);â
One way to get rid of this is to add: " workerSrc: [âblob:â] " to the CSP but we are getting back to the risks it introduces when we put this line in the Content Security Policy.
Still fuzzy for me at this point, Iâm a bit of a newbie but I am now trying to figure out how to make it work without the " workerSrc: [âblob:â] " in the CSP.