CORS errors when loading default BJS playground & other projects that use BJS due to 'Access-Control-Allow-Origin' header containing the invalid value '**'

Bugs
1

Hello BJS team,

Overnight we’ve started to see CORS errors in our webpages that use BJS and it’s BJS hosted content/dependencies. They seem like errors you’d get from a misconfigured web server.

Examples of the errors are:

Access to fetch at 'https://preview.babylonjs.com/glTF2Interface/babylon.glTF2Interface.d.ts' from origin 'https://playground.babylonjs.com' has been blocked by CORS policy: The 'Access-Control-Allow-Origin' header contains the invalid value '**'. Have the server send the header with a valid value, or, if an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

Access to fetch at 'https://preview.babylonjs.com/loaders/babylonjs.loaders.d.ts' from origin 'https://playground.babylonjs.com' has been blocked by CORS policy: The 'Access-Control-Allow-Origin' header contains the invalid value '**'. Have the server send the header with a valid value, or, if an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

Access to fetch at 'https://preview.babylonjs.com/zstddec.wasm' from origin '<REDACTED>' has been blocked by CORS policy: The 'Access-Control-Allow-Origin' header contains the invalid value '**'. Have the server send the header with a valid value, or, if an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

Did something change recently that would cause this?

1 Like
2

We are aware of a CDN server issue on Azure. We are trying to find a workaround as soon as possible

2 Likes
3

Thank you.

I think this issue would be less of a problem for our own webpages if the KTX2 support and its use of ZSTDDecoder didn’t have a hard-coded reference to this external file, and instead came from within the local BJS package:

export class ZSTDDecoder {
 public static WasmModuleURL = "https://preview.babylonjs.com/zstddec.wasm";

Is it customisable?

4

Was having widespread corruption of these files before this and was about to start hosting them ourselves anyway. Most recently everybody in Netherlands had an edge cache with a corrupted version which broke all GLTF using draco.

MicrosoftTeams-image (9)
MicrosoftTeams-image (9)702×722 49 KB

1 Like
5

Seems like it just started working again.

Thank you for fixing.

6

As you can see you can overwrite the url by code (this is meant exactly for this case:))

Simply set BABYLON. ZSTDDecoder. WasmModuleURL To the good value for you

3 Likes
7

We should be back on track good people!!!

3 Likes
8

Thank you @Deltakosh

Is there a plan to bring the dependencies hosted at https://preview.babylonjs.com into the main bjs distributable package before the 5.0.0 release?

9

What do you mean by main distribuables?

It is already available on npm (preview)

10

By “main distributables” I mean the npm package available at babylonjs with the command npm install babylonjs

We self host the babylonjs package at a specific version with an entry like this in package.json
"babylonjs": "^5.0.0-rc.2",

I expected that distributable to contain all libraries and files required by babylonjs. Now I understand thats not the case and some features need libraries available at the preview CDN, which is fair enough.

I’m asking if it will always be the case that some parts of the babylonjs codebase will require us to download those preview libraries and then set the url to our own domain?
Or is the default loading of some libraries from the preview CDN something that only happens for alpha/beta/rc’s.

1 Like
11

Oh I see. Yes this is our expected way of working. The external files (not included in the npm package) are files we do not own/control

2 Likes