Meeting SDK Type and Version
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?
My application attempts to retrieve the Zoom SDK files from the server (ex: https://source.zoom.us/2.16.0/lib/av/video.simd.wasm) and is given a 403 Forbidden status code as a response.
Tried accessing the different files for the different SDK versions.
https://source.zoom.us/2.15.2/lib/av/video.simd.wasm - Not working
https://source.zoom.us/2.16.0/lib/av/video.simd.wasm - Not working
https://source.zoom.us/2.17.0/lib/av/video.simd.wasm - Working
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 got the same error but it’s a different file name. Here is my file https://source.zoom.us/2.17.0/lib/av/1503_js_media.min.js
I would usually look the the browser console to see whats the actual files which is being loaded by the SDK.
For example 2.17.0 using this for js_media_min.js
That’s a good spot, here is my console on the browser
zoomus-websdk-embedded.umd.min.js try to get this file from your server. Could you please check back again?
I tried to reproduce this issue on a new source, but it throws me a different error
For more information:
@cuongle-hdwebsoft before anything further, what are you trying to do?
There are easier ways to load the Web SDK.
I just tried to upgrade Zoom SDK from version
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.
Hi, We are actively investigating this
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.
However, yesterday my app was trying to load that wasm file for 2.16.0 from the link I posted above.
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.
Thank you for investigating, I found the issue. Our package.json was set up to automatically pull the next non-major dependency release:
And the code was looking for the resources on the 2.16.0 path:
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.
That’s a nice fix, I confirm that I cannot reproduce this bug on
thanks for reporting it @cuongle-hdwebsoft