CORS header for studio.env

Hi,
I was debugging something and everything was working fine, but a couple of minutes ago this started showing up in the browser console:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://assets.babylonjs.com/environments/studio.env. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).
6
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://assets.babylonjs.com/environments/studio.env. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).
2
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://assets.babylonjs.com/environments/studio.env. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).

and so our app stopped loading properly. Was this intentional? If it is, how should we go about fixing this issue, since we need that environment for our app.

Thanks in advance!

One way to fix is to grab your own copy. You used the word ‘our’ so I assume this is commercial, removing as many points of failure has a certain logic to it. This is not coming from a CDN, like the framework itself, so any problem with that server is going to take you out.

I have no idea about the actual issue, but perhaps these were just intended for dev use with the playground, not a source for production use.

1 Like

Thanks I just downloaded it and we’re using the downloaded version as of now.

Actually even the sandbox have this issue (was working fine this morning)

image

@Deltakosh @JCPalmer @RaananW @Vinc3r @dlukanov
I’ve narrowed it down to the Environment Helper. My application relies on es6 tree-shaking, and I assumed that even though everything was local, scene.createDefaultEnvironment() was still calling out to Babylon’s example textures on a server. Well new EnvironmentHelper({}, scene) causes the CORS error too, even if the options params are empty. Scary stuff. Glad none of the web-apps I have out there rely on either, but that still makes me a little queasy because maybe there’s another module I’ve used that’s making some mystery XMLHttpRequest under the hood…

You’re right, maybe this should be mentionned in both the doc’ and API.

To be fully local, download assets used by the helper, and load them with the EnvironmentHelperOptions like environmentTexture or skyboxTexture (actually here it says it’s using the CDN).

It makes sense why they wouldn’t package all those resources with @babylonjs/core, but why does instantiating a helper result in multiple XMLHttpRequests when I haven’t even defined the params… why fetch a skybox texture if I’m not even using one. Everything should be null until set otherwise.

Moved the assets to a new and fast CDN. This should be fine now, please let me know if you experience any problems.

Sorry about that! just took a little while for the SSL certificate and headers to propagate.

4 Likes