Description
All attempts to access the wasm and js files for the Zoom Meeting web SDK from the Zoom domain are resulting in a 403 error. This was working this morning and yesterday. Since 2.17.0 was released did that affect the older versions?
I believe those endpoints are not meant to be used directly.
Nonetheless, are you trying to cache a local copy?
Some of these might get redirection to a slightly different filename.
These are values returned by the Web SDK (different versions) in the browser console.
I just tried to upgrade Zoom SDK from version 2.16.0 to 2.17.0. There is no change in my code, just change the Zoom SDK version and thatâs all. This error happened in Zoom SDK which gets some inaccessible resources from a server.
Without making any changes to our code the SDK stopped working, and after a time we were seeing a âUnable to load wasm moduleâ message in a dialog. In the browserâs debugger I saw the files that are referenced on the zoom.us server were responding with 403 errors. Coincidentally this happened around the time the 2.17.0 SDK was released. Our code that was previously working did not change.
Iâm not trying to cache a local copy but trying to figure out why this stopped working. This wasm file is the exact URL the 2.16.0 library is trying to download.
Thank you for looking into this. I think I may see what had happened, and have a related question. When a new version of the SDK is released are the resource files for the previous version updated with a prefix to version the resource name? The link you reference does appear to be the correct link, and this morning it looks like I can download the resource correctly.
My guess is that I was running into a caching issue, if it is the case that the URL was updated in a library but my application was still looking at the previous one. If this is the case, do you have any suggestions how we can prevent this in the future? If releasing a new SDK will cause resource paths for the previous SDK to no longer be valid we will likely have issues in the future if the previous path is cached somewhere.
When the new SDK was released and we rebuilt, we pulled the new 2.17.0 dependencies but were still referencing the libraries on the 2.16.0 path. Since the libraries were renamed we started seeing the 403s looking at the previous path. I removed the carat from the dependency version, and once we rebuilt weâre pulling the libraries from the correct paths. Everything is working great know. Thanks for the assistance, and sorry for the wild goose chase.
@cuongle-hdwebsoft@tkapinus , there was a fix which we have rolled out on the CDN towards the end of last week. If there are still pending issues, do let me know.