Description
We switched to the latest websdk 1.8.6 on Monday (1/11/21). We notice that the rate of seeing captchas has increased. Going back to 1.8.0 , we do not see this issue. I am aware that WebSDK users are forced to upgrade to >= 1.8.5. I do not see
Error
We see a Captcha screen which is disruptive for the user experience.
Which version?
1.8.6 WebSDK version
To Reproduce(If applicable)
Steps to reproduce the behavior:
It does not happen all the time. It only happens to a fraction of the calls.
Screenshots
If applicable, add screenshots to help explain your problem.
Device (please complete the following information):
Device: x86
OS: Debian Buster
Browser: Chrome!
** Additional Context **
We are seeing this if we join the call before the host using 1.8.6.
“Your connection has timed out and you cannot join the meeting. Verify your network connectivity and try again.” zoom_error|690x388
Do you have any specific data of how often the captcha is showing? The reasons it shows is if a user gets the passcode wrong multiple times in a short period.
Check the browser console logs to see what the more descriptive error is. Make sure you have started the meeting, or ensure the join before host setting is on.
Hi @tommy ,
The captcha is showing about 20% of the time while it was close to 0 before . This is not happening when the user enters the wrong passcode. This happens when the host hasn’t started the meeting and has also not enabled join before host. So, when the users of the websdk hit retry multiple times [despite using the right password], it shows a captcha.
Is there a reason why the websdk shows a dialog and asks to retry to check when the meeting has started? It sounds like Zoom has all the information necessary to remove that dialog and join automatically using webhooks.
Thank you for providing additional information. It sounds like the Zoom back-end is seeing these repeated retry attempts as potential bot activity. I’m not aware of changes to the captcha but this would align with our efforts to improve platform security.
I think that your idea about using Webhooks to check if the meeting has started is a great idea to prevent these requests if the captcha poses a UX issue.
You could implement a check in your application to prevent attempts to join the meeting before it has started using the return value from join() in combination with our meeting.started webhook.
That being said, I do think that would be a good feature to have in the Web SDK. If you would like this feature to be considered for a future release, I recommend posting in the #feature-requests category.
