After some tests, it seems that our code that was working fine up to 1.7.8 does not anymore with 1.7.9.
Any non host profile cannot join an existing meeting and get error code 3110.
So which other step or parameters should we do / pass to be able to join a meeting with 1.7.9 ?
this problem occurs both with CDN + Local sample web app installations (sry for the wrong information above) on windows and linux, and also on our app integration (which uses the CDN sample webapp as base)
our setup has not changed(beside the upgrade from 1.7.7 to 1.7.9), we are copying all relevant files (av libs + zoom-xxx.js) to a docroot and serve them with a webserver (i.e., no npm / node is used).
hosting a meeting works without problems
joining a meeting opens a popup browser window ‘check captcha’ - but with a captcha missing (only ‘cancel’ and ‘Continue’ buttons are visible
I am getting the same error, and started looking for an option to disable in the source code.
I am reading the source code for ZoomMtg v 7.1.9, and looking at the Config Object passed to ZoomMtg.init method, there appears to be no option to disable the new recaptcha option.
In my case we are running a Zoom Webinar within an iframe.
@michael_p.zoom, you wrote ‘right now we do not have a way to disable recaptcha feature’.
this wording makes me wonder (or better hope) that in a future release, there may be the possibility to circumvent this recaptcha feature?
won’t it make sense to make this recaptcha-feature an on/off setting, like password protection for a personal meeting room?
will there be the possibility to stick with sdk 1.7.7 or 1.7.8 in the future, or will support for these versions be removed sometime? if support will be removed, can you make a statement about the timespan we can expect that 1.7.7 / 1.7.8 will be functional?
thx for your input, we really need to know in which direction this thing is going…
@michael_p.zoom - following @harald.glanzer point re: ability to turn off the captcha feature. I would second this request. I raised this at a stand up Engineering meeting today, and we all agreed that having ability to disable would be great for the user experience. In our case, the attendee must already be logged into our application that is itself protected by SAML and CAPTCHA and in some cases U2F / 2FA. If a user has already gone through the process of proving they are who they say they are and also not a robot, it seems overkill to force caption at this point.
I will third this request. Requiring an already authenticated participant to complete a recaptcha will pose a massive hurdle to joining meetings. Please allow this to be disabled.
For security reason, the Attendee will provide Passcode or wait in the Waiting Room, then why should again asking Attendee to enter the reCaptcha? The meeting already “enabled with Passcode” should not redirect to reCaptcha page. So please consider this request and remove/disable the reCaptcha for Passcode enabled meetings.
And also, the developers those who are done with customisation on the previous SDK will suffer a lot with this Captch feature. So please reconsider my request and disable the captcha for at least the passcode enabled meetings.
Of course i (and my team / company) +20 the future (soon i hope) possibility to deactivate this recaptcha feature as it completely destroy user experience as well as customization made up to now with previous SDK versions.
The goal of this post was indeed to have documentation listing regarding this feature but also to check if there are people who share the same concern as us, and i’m more than happy we are not the only one.
So, as already explained very well before me in this thread,
it does not make sense at all to have a recaptcha for application integrating zoom which are already secured in another way / closed to public + protected with password already.
if you try to convince us that this is for security reason, then why do you enable to skip the recaptcha when joining as a host ? This is completely non sense. Recaptcha is to protect against bots so should be activated to public meetings only. I understand that you may want to protect yourself (and your clients) against bots for obvious reasons, especially for those who do not protect their applications and give free access to it, but not at the cost of people doing things right.
The web SDK is there for an integration purpose, so you should consider a way to deactivate certain options at the contrary of your native clients.
@michael_p.zoom here is another big reason why you should give us the possibility to deactivate this recaptcha feature
Recaptcha is collecting user’s data.
If you force us to use this, you forces our users to have some of their data collected by Google, which is against the GDPR and other similar laws depending on which country the user is coming from.
As a service company we have to apply the law (same as you by the way, it’s not because you are a US company that European or APAC law do not apply since you have customers from all over the word)
Because of this law, we must provide a way to have the user’s agreement for data collection.
**With SDK 1.7.9, if the user refuse to have his data collected, then we must not collect it. But since you force us to pass by this recaptcha feature not matter the user accept or not, we are now force to tell to our customers : if you don’t accept you cannot have access to our online services, which is a disaster in term of communication and have a direct impact on our economy.
So please, remove it completely or make it optional as soon as possible.
I also request the ability to turn this off. Changing the user workflow this much should have perhaps been discussed with those using your SDK for business purposes before forcing everyone into something that’s only going to cause mass user complaints.
Think about other use cases too - we’re doing conferences. We have people joining 8-15 sessions daily from an agenda with the WebSDK embedded in our site. They (or anyone) would not be too happy about going thru recaptcha for 10 rapid fire sessions. Or even 1 for that matter. It’s annoying. It would be interesting to hear your rationale for implementing this requirement. Considering one has to generate a signature with the public/private key to join - I see no reason for it. Please explain.
You guys are making it very difficult for us to depend on you as a partner and provider. I’m about at the end of my rope. we’ve been waiting for this release since the the previous version made us look bad to customers in production with black screens and missing Safari audio - now I have a fix for that - with a new “feature” that’s just going to cause more and more complaints. We have customers we have demo’d integrations to who will now have another surprise that will probably not be well received. Meaning lost business for both of us.
We are in the exact same boat, and this just echoes my points on the thread about the actual 1.7.9 update.
There are really no excuses as to why this functionality was implemented and forced onto us … and broken at that.
Unfortunately, the tones of these messages are going to get worse as time goes on until a proper solution is found. And more importantly, a proper answer is given to us with an explanation. We are trusting our businesses to Zoom, and I am aware COVID-19 has skyrocketed your business, but it doesn’t mean you can leave partners in the lurch.
Please reply with a proper answer that isn’t just copying in some link to docs. We deserve a detailed explanation and a realistic turnaround time.
