We have developed a Zoom application using Vue.js, which also utilizes Firebase for email and password authentication. The login view consists of a simple form that requires an email and a password, and we use the signInWithEmailAndPassword function from firebase.auth().
The issue we’re facing is specific to Windows machines. While the web app works without issues on both Windows and macOS devices (with the same codebase with the zoom app in marketplace), we cannot log in to the zoom app from Windows machines using the zoom client.
After verifying the credentials, we found that the error message received from Firebase is:
Firebase: A network AuthError (such as timeout, interrupted connection, or unreachable host) has occurred. (auth/network-request-failed).
We have checked for any connectivity issues, firewalls, or antivirus software that could be causing this error, but found none. Additionally, we tested the application in non-company environments without any company-wide firewalls, yet the issue persisted. Disabling Windows Defender also did not resolve the problem.
Question
Is there a specific configuration or requirement for Zoom applications to work with Windows machines and firebase login using email and password in the Zoom client environment that we might be overlooking? Any insights or suggestions would be greatly appreciated.
Hello again,
is there any lead on this? The thing is that by whitelisting the google specific domains and urls it worked but only in the dev app.
The whitelisted ones are:
@vk1 I’m sorry to hear that firebase isn’t working as expected in Zoom. I’ve ran into issues like this before with other SDKs but not firebase so far.
Are you using their firebase UI to build the auth flow as well or just the SDK functions?
You mentioned this only happens on prod. Is it as simple as changing the Zoom Client ID to the production key or are you changing the entire environment to production?
I am just using the SDK functions and more specifically the signInWithEmailAndPassword one.
The UI is a simple form actually that expects an email and a password.
Regarding the production now: The staging environment is just a replica of the production (functionality and infrastructure wise) so the data are different but the rest are the same.
Last but not least, as I mentioned, this issue occurs only in windows machines (in MacOS ones the app works perfectly) and the errors that we receive -only in windows- and we can see in the console of the zoom embedded browser are the below attached cors ones.
Having said that, we are wondering if this is an issue related with the windows embedded browser that Zoom is using and whether or not it blocks by default urls that are permitted in the MacOS one and also ignores the whitelisted ones that we have in the Domain Allow List of the features → surface.
Thank you for that information! Based on what I’ve seen before I expect this does indeed have to do with the embedded browser that is used on Windows but I wanted to add my thoughts here in case they help to debug on your end.
First, if this is a published application you will want to make sure that you resubmit the application and have users re-install the app. This will make sure that the allow list changes you made are seen by them.
I also have a firebase sample app that was written some time ago but was recently updated that you can find linked below. In that app, I’m using firebase 10.12.4. Does updating the version of firebase that you’re using change the behavior at all?
As you can see there is a CSP header that is left wide open because it’s a sample app. I’m also wondering if you add a connect-src or script-src of *.googleapis.com if that will work around some of these issues?
First, if this is a published application you will want to make sure that you resubmit the application and have users re-install the app. This will make sure that the allow list changes you made are seen by them.
We have already done this but without success.
One more thing that i would like to mention is that the solution works perfectly in the dev environment, which is exactly the same as the production as I mentioned, so I dont know if it’s actually a CSP related issue.
Could it be that zoom embedded browser by default blocks some urls even if whitelisted and potentially you from your side need to take some action in order to actually enable the in the production environment?
I mention that because, I remember during the initial review process, one of your colleagues have mentioned something similar. Essentially, that zoom is a bit more flexible when it comes to the dev environment but becomes stricter in the production one.
I hope that also helps you to pin point the issue.
Could you please advice on potential next steps? Were you able to identify the root cause of this issue?
As you can understand this has been a blocking point for our application as it affects our user as there isn’t any workaround from our end.
