Description
Recently, without us making any changes, all our users faced a “passcode wrong” error message when joining a meeting. I suspected maybe the version we were using (1.9.8) was deprecated so I updated to 2.0.1 but the error is still displaying whenever someone tries to join a meeting in-browser.
Browser Console Error
No new console errors are logged beyond things like the browser looking for .map files for the CSS and JS files.
My apologies for the delay. First, as a test, are you seeing this with the Sample Web App? If not, you may be able to use that app as a reference.
If you’re seeing the same issue with the sample app, I’m thinking this is related to the meeting settings. If so, please submit a ticket through our Developer Support Center and include a link to this thread as well as the Meeting ID where you’re seeing this issue.
Thanks @MaxM for your help. This has inexplicably started working again. We haven’t changed anything, but it seems fine once more. Were they any issues with Zoom services in the last week or so?
Can you clarify this? How are you getting the passcode? Is a user entering it in via an input, or are you getting the passcode it programmatically via the Get Meeting API?
Can you give us exact steps to reproduce the issue? We aren’t seeing this issue on our end when we test.
Both the meetings I mentioned would have been created with almost identical parameters, the only differences would have been the start_time, duration, topic and the user who created them.
So what I’m trying to figure out is why for some meetings users can join without passcodes and for other meetings they cannot. Is it something to do with the user who creates the meeting?
You can refer to the API enhancements for meeting security requirements page to learn more details about how these settings can impact the response of your meeting creation and update requests in different scenarios.
Hi @donte.zoom, does this mean that if a user has “Meeting passcode” enabled in their settings, any meetings created via the API will require a meeting passcode, regardless of the settings sent across in the API request? If so, is it possible to override that somehow so only “waiting rooms” are required? It’s impossible for us to send the passcode to all the users who will be expected the join the meeting and it’s hard for us to tell all our clients to make sure they turn off a setting in their Zoom account, as it’s unlikely that they’d all do it.
Apologies if that was covered in the “API enhancements for meeting security” article, but I couldn’t quite be sure from reading that as there were so many cases and the middle column appeared identical for almost all of them.
Great question and thank you for the feedback. I will make sure it is shared with the appropriate team members. To that end, in some cases, the API is not designed exactly one-to-one with the Web portal settings. As mentioned, there is a matrix of outcomes that can occur depending upon account configurations (if settings are enabled/disabled/locked/unlocked). To get the desired meeting configuration via API request (and not send a passcode to meeting participants) be sure the appropriate security properties are configured in the API request. So for this scenario, if the password parameter is added to the request ( or default_password parameter) you should be able to successfully create a link with the passcode included, so users are able to click on it directly and access it without having to enter their password.
Start your meetings without a passcode, it’s better for you and your client, you can use the call request option, so you can check and add users in your meeting if you want to.
@donte.zoom So it sounds like in order to fix this problem I’ll need to set a password on each meeting I create via the API and then include that password in the ZoomMtg.join() function in the web portal, is that right?
If so, that’s quite a significant change for me and not something I’ll be able to implement and test quickly, so I’ll get back to you when I can. If there is any way I can create a meeting with waiting rooms only and no password, regardless of user/account settings, that would be ideal, so please let me know if that is possible.
@45track That’s exactly what I want to do, but apparently I can’t do that for everyone, only some users.