Why does status.zoom.us show a big green “All Systems Operational” when this is not the case? You have a major part of your infrastructure down and have been brushing it away for the last few days.
Seems like, from outside observations, all these actions and changes were done to mitigate the information scraping and leading towards war dialing/zoom bombing.
However with how you have performed the rash actions and with the lack of communication, I now fear we are looking at something much more serious. These actions (or lack thereof) seems to point that you are in a very difficult position and are being told to keep it under wraps by senior leadership and/or legal counsel.
You are eroding the trust of the most influential users you have, the developers. It’s a terrible and rare occurrence to see an entire customer base be put into limbo like this.
This is not good enough. You are already giving us false hope and information by stating on your own Zoom status page that everything is operational. We were able to refer our customers to that page so that they realized it’s not our fault (not that it helps in any way), and now that you are displaying false information there as well we have nothing to say.
Update: this seems to be due to some old code on our side that set approval_type of 0, but it’s never been a problem until now. This is new behavior Sunday evening, but is fixed by setting the value to 2.
Things are changing under my nose. This is what I get now when trying to send users to join a meeting using the standard join URL (with password embedded):
This is unacceptable and unbelievable. We have bought about 50 licenses last week, and are in the middle of a process to switch our whole company to Zoom. Accessing the Web Client without a Zoom Account is a mandatory feature required by our customers. If this is not possible anymore, our work over the last few weeks is wasted. You are forcing us to to cancel all of our Zoom subscriptions to switch to a better solution. Our customers are outraged.
Even worse, the current way of account creation is flawed: As we are using SSO Integration, participants are not forwarded to the Zoom Account Page to create their account, instead they are forwarded to our SSO IDP Provider to login with a SSO account - which is not possible for them!
We need to be able to simply allow our clients to enter the Zoom meeting from an embedded web page component, this was working fine 3 days ago. bring it back please.
Simple and easy, keep it that way. Forcing clients to redirect to a singin page when clicking on “Join from Browser” is ridiculous, especially if you are sending the wrong message to children under 16 years old who, according to your privacy policy, should not be singing up for an account anyways.
We’ve been keeping an eye on the problem with the web SDK, which has been bothering us for a few days, but zoom hasn’t had a clear fix or update, which is pretty bad
I just very frustrating with this situation, people who spent thousand of dollars on licensing were hoping for good and reliable service, but they decided to make life crucial changes without notice. First of all create new and reliable replacement and then force people to move to new SDK, but shutting the service for 4+ days it’s beyond my understanding. How the heck you can allow for the service to be down for so long, how the heck you are not answering to peoples posts, how the heck you survived in that business for so long if you can’t manage your customers in proper ways. So many “how’s” but no answers. I moved to jitsi for a while, I know it will not replace what I had with zoom, but at least I can make small meeting rooms without a hassle.
That’s exactly what we’re doing. We just launched our new integration with ClickMeeting, and the auth hash system works beautifully. Hoping Zoom has enough sense to do something similar.
@tommy@TimZoom In addition to the above, an Educations customer with paid multiple accounts has no password set on their meeting, and the Web Client is forcing them to enter a password, which never validates. We tried enabling a password and disabling a password, but still the same issue. Universities and K-12s alike are meeting with students and visitors who will not have a Zoom account. I understand the security concerns released Friday/Saturday, but this is a non-starter and huge breaking change for those schools with no notice. We’ve essentially become your support team over the last few weeks trying to field these questions; understandably they think it’s us, which is fine but we need communication on all of these things so we can help your customers.
Just wanted to chime in that I’m also hoping for a resolution to this ASAP, as we’re super reliant on this integration and standalone isn’t an option for us.
We almost have all our ducks in a row. We are working towards a new WebSDK that we are hoping to have released in the next 24 hours. Please keep in mind this is a moving target and that we are trying our hardest to get this out as quickly as possible but things might change. If they do I will let you all know here the moment I know.
Here are the details:
A new WebSDK will be uploaded to our GitHub with version 1.7.4. When it is released I will update this thread with a direct link to the version for download.
This will require no code changes
Users will not be required to log in/have an account
I know this has been tough on all of you and we are working hard to get things back up and running. Again, I appreciate any and all patience you can afford us and we continue to appreciate you being a Zoom customer!
our team is also implementing Jitsi, in case the zoom web sdk update ends up being delayed or has further problems. If that’s the case we may consider removing zoom as an option for our users and just recommend only Jitsi.