CORS request no longer working in plugin with SU2024. Websecurity change?


We are having a blocking problem with our HtmlDialog-based plugin on SketchUp 2024, and it seems to be due to the update to CEF M112. SketchUp 2021, 2022 and 2023, using older versions, are working fine.

The problem comes when we are using ‘fetch’ to contact our backend.

Through extended research on what could be the problem, one thing that came out is that the CORS HTTP requests we send to our API are no longer having the pre-flight request done by CEF. One is for instance a PATCH request, which is not a simple request as specified in MDN (Cross-Origin Resource Sharing (CORS) - HTTP | MDN).

There have been some changes regarding WebSecurity in CEF (Remove CefBrowserSettings.web_security since it's no longer useful · Issue #3058 · chromiumembedded/cef · GitHub) and the build in SketchUp might have been through some tweaking that is now preventing us from successfully sending such requests.

We are saw on this forum post from Dan that there could be some bugs in the CEF build used by SketchUp 2024: Fetching JSON data in HTML - #2 by DanRathbun

Has anyone been plagued by such a crippling issue, and what could be the fix? And also, is the SketchUp team investigating on such potential problems with the tweaking of the web security?

Kind regards,

1 Like

Given what MDN shows, does a POST request work correctly with respect to CORS?

Yes, they are interested as SketchUp itself has several built-in web interfaces.

Given what MDN shows, does a POST request work correctly with respect to CORS?

Unfortunately no, it does not.

To give some context, this is the workflow:

  1. we send a GET request to get a slot ID from our backend API
  2. we send a POST request to upload a JSON version of the model to our backend with that slot ID as a parameter
  3. we send a DELETE request with the slot ID as a parameter, which returns an upload ID
  4. we send a PATCH request with that upload ID so that our backend triggers a processing of the uploaded model, and get a task ID as an answer.

What I observed:
Request 1 works with CORS - it’s just a GET request

Request 2 does not work with cors mode: the request is truncated, and our multipart/form-data message has a content-length of 0 when received by the backend, causing it to return a 500 error.
If we set the mode to ‘no-cors’ in the fetch parameters, then the response of the request is opaque, which means that the JavaScript script cannot read any returned value, including any potential error code.
We could still go down that road, as it is just an upload and we expect an empty reply, and it seems to succeed if we look at the backend logs.

Request 3 works - we are not setting any specific mode in the fetch parameters.

Request 4 fails with CORS: the endpoint needs an Authentication token, and the backend returns a 400 with the following message:

“The input does not contain any JSON tokens. Expected the input to start with a valid JSON token, when isFinalBlock is true. Path: $ | LineNumber: 0 | BytePositionInLine: 0.”]

Since the request 2 gets truncated with CORS, it feels that the Authentication token is truncated off the request 4 too.

We cannot afford to use no-cors mode for this request because we need to get the content of the backend response.

Just to confirm, we are running the plugin on a local server for debugging (http://localhost:8000) and the backend returns the access-control-allow-origin: http://localhost:8000 when queried with an OPTIONS request, so it matches the CORS requirements.

Last point to add, slightly on the tangent: we have a dynamic loading of the Javascript files used by the plugin, and it does not always load them, somehow.

In this screenshot, upon opening the plugin only the initialise.js script loads, and the execution stops somewhere without any error being thrown.

I just closed the plugin to reopen it (sometimes few times) and now the scripts are loaded.

This might be linked to this issue that I posted initially maybe (Fetching JSON data in HTML - #2 by DanRathbun) - I can also open another topic if it feels too unrelated.

@DanRathbun Good, then hopefully we can combine our forces to understand what’s happening.

Interesting. I assume you’re more or a node.js type rather than Ruby? No matter…

Not sure what is happening, and (obviously) this is a complex issue.

I’ll see if I can spin up a server (Puma) and repro the issue. Might be a few days.

I looked up Treble to see what it’s about.

JFYI, it was several years ago, I had EASE, CATT, Odeon, Easera, and SysTune (and maybe Smaart) loaded on my Windows systems…

1 Like

HI Greg,

Thank you for looking into this.

The plugin is in JavaScript because we upload a 3dm version of the model to our backend (not JSON like I said earlier, my mistake) and there is no Rhino3dm library in Ruby - but there is in JS.

Had Treble been existing, I see that you could have enjoyed our services that group some functionalities of EASE, CATT or Odeon into one cloud-based solution - nothing on your Windows system. (If you are curious, you can always try it out for free.)

Again, thanks for offering to help. Let me know if you need any additional information!

Thanks for reporting this, I’ve logged a bug in our system and I’m taking a look.



Hi Sebastian,

Following our direct emails on Friday I wanted to confirm to you that our development team are currently investigating this for you. As soon as we have some feedback for you we will come back to you.

Kind regards,



Hi Joe, Hi Craig,

Thanks for the prompt reaction to this issue.

Kind regards,

Hi all,

This is exactly what I’m hitting it now. I can’t POST requests succesfully on localhost or local .html file because of preflight was missing. I have 2 UIs which are old and new. New one runs on URL and it doesn’t have any problem with it.

I am looking forward to solution for this too.

Best regards

1 Like

Critical issue for me too.


The release of SketchUp 2024.0.553 moved that problem into the issues-of-the-past category, and our plugin now works just like with SketchUp 2023.

Thanks for taking action on this!

Kind regards,