question

@mvader (Victron Energy) Might you be able to ping the Victron folk who manage the API cloud services? This has put a dent in my monitoring of our vessel http://yates.ca/brigantine/. The API works fine when accessed outside of a web browser, but web browers are preventing client side Javascript access. Thx.

As a workaround, when I start chrome with "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disable-web-security --disable-gpu --disable-features=IsolateOrigins,site-per-process --disable-features=IsolateOrigins,site-per-process --user-data-dir="C://ChromeDev"

the CORS check is not performed by chrome and your (and my) site works. But it is pain in the ass.

Hey both, I missed your messages in february; but have now asked someone to check.

Have a good Sunday, Matthijs

Was able to implement a workaround; should have posted the details before now....

The API calls were failing the pre-flight browser CORS test.

The OPTIONS browser pre-file was returning the headers:

Instead of:

The workaround I found was to run these API calls through a web proxy. Turned out there is a free one (and a few paid ones) that are run for this specific use case. So my API call then now starts like:

https://corsproxy.io?https://vrmapi.victronenergy.com/v2/users/

This was good for the first call, then I found I was getting the same response over and over. There was a last_updated timestamp I was using, and it was never changing. Obviously being cached in the proxy. Adding in various “no-cache” headers didn’t help. But I did find what was termed “old fashioned cache busting. That is, adding the current time as a random parameter to the end of the URL.

var d = new Date();
var url = URL_VRM_INSTALL + '&ajy=' + d.getTime();

Now the first API call was working fine every time. But the second API call was being rejected by the proxy.

https://corsproxy.io?https://vrmapi.victronenergy.com/v2/installations/' + idSite + '/gps-download?'

Given the proxy is free, I was wondering if they might be screening out downloads due to potential large payloads. I took out the word download, and got past the proxy. Obviously I can’t change the API end point, but I found that if I encoded one of the characters in the word download, then it gets past the proxy check.

https://corsproxy.io?https://vrmapi.victronenergy.com/v2/installations/' + idSite + '/gps-%64ownload?';

Great idea, however I'm still getting this error

Access to XMLHttpRequest at 'https://corsproxy.io/?https://vrmapi.victronenergy.com/v2/users/36628/installations?extended=1&ajy=1717703948925' from origin 'https://www.XXXX.cz' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

I have still to use the modified Chrome.