Cannot connect to Firestore (only on network at work)

[remyayad]

Environment

• Operating System version: Microsoft Windows 10 & macOS 10.14.5
• Browser version: Chrome 79.0.3945.117
• Firebase SDK version: 7.6.2
• Firebase Product: Firestore

Problem

I am using AngularFire with Angular to store DB items (I also tried with the "vanilla" firebase ending up with the same results). The application works fine on my home computer and on other computers I have tried (Macbook, PC). I also tried different networks (my home network, a hotspot, a public network, my sister's network). However, when I am trying to use the app on my work PC or simply on the company's network, the entire app loads correctly except for the content that needs to get pulled from Firestore. The anti-virus software on all the PCs at work is Symantec Endpoint Protection and zScaler seems to be the proxy filtering web traffic. Unfortunately, since the entire IT infrastructure is managed by a third-party, I do not have access to the configurations of the network. I am not even able to load a single document of a given collection on the actual Firebase Console which leads me to think that the issue has nothing to do with the way the app was coded. The funny thing however is that if I am patient enough, the data will eventually load after several minutes (sometimes 10-15 minutes, sometimes less. Here is an example in a log). Following @mikelehen's advice, I added the following line of code to provide a detailed log :

firebase.firestore.setLogLevel('debug')

On my personal computer, everything gets executed in a matter of seconds. On my work computer, it seems as though the request gets stuck after the following line in the debug console without loading the Firestore content :

@firebase/firestore: Firestore (7.6.2) [Connection]: WebChannel transport opened.

I also generated a HAR file for reference :
firestore-request-issue.stackblitz.io.zip

Relevant Screenshots :

On my personal PC (the way it should be) :

On my PC at work (something is wrong) :

Relevant Code:

I reproduced the issue in a fairly minimal app on Stackblitz for you to have a look :
https://stackblitz.com/edit/firestore-request-issue

At this point, any help is more than welcome. Thank you

[rommelpe]

It's sounding a network-specific issue to me, and unfortunately this goes beyond our control. Firebase doesn't work well on proxies/firewalls that block access to our database, since it needs to have a secure connection to our servers to make sure that data can be transferred efficiently. See this discussion answered by one of our Firebase advocates.

You may try to whitelist this domain: firestore.googleapis.com to relax some restrictions.

[wu-hui]

I feel sorry but there really is not much we can do from Firebase side to make it work. As rommelpe said, your best way forward is to somehow remove the restriction your corp policy applied to firebase services.

[remyayad]

Thank you for the replies. Like mentioned in the OP, the data eventually gets pulled (after a few minutes) which tells me that the connection is not blocked. How can that be? Is there any way I can troubleshoot?

[wilhuff]

The most common reason for the JS SDK to be blocked is actually that your proxy is buffering responses.

Try setting experimentalForceLongPolling in your settings: https://firebase.google.com/docs/reference/js/firebase.firestore.Settings.html#experimentalforcelongpolling. See more here: #1674.

[remyayad]

Hi @wilhuff, thank you for your input. I saw the post you mentioned. In fact, the last three replies are me and @mikelehen discussing the issue. The tests (running https://debug-my.firebaseapp.com/ on the corporate network) seem to reflect that the network should be reading/writing to Firestore whether the experimentalForceLongPolling flag is enabled or not :

All tests done.
1: webchannel.googleapis.com with default options: FAILED (75039ms)
2: webchannel.sandbox.google.com with default options: FAILED (75017ms)
3: webchannel.googleapis.com with forceLongPolling: SUCCEEDED (2674ms)
4: Firestore listen test with default options: SUCCEEDED (321ms)
5: Firestore listen test with forceLongPolling: SUCCEEDED (438ms)

I believe the line I should add to fully test the functionality is : firebase.firestore().settings({experimentalForceLongPolling: true})

Given the fact that I am using AngularFire, where exactly should I insert this line for the project not to give me the following error?
Firestore has already been started and its settings can no longer be changed. You can only call settings() before calling any other methods on a Firestore object.

I created a Stackblitz project as a reference where you can see exactly how I implemented Firestore in the project : https://stackblitz.com/edit/firestore-request-issue

[wilhuff]

You need to use the FirestoreSettingsToken to provide the settings you want.

This is essentially just like angular/angularfire#2183 (comment), except instead of specifying host and ssl properties, you want to set experimentalForceLongPolling.

[remyayad]

Looks like this fixed the problem at the cost of performance but that's the price to pay to have a working app in complex corporate networks. Still wondering why the test mentioned in issue #1674 passed without the experimentalForceLongPolling flag enabled though...

Also by looking at the title of the flag, I'm wondering how permanent of a "fix" this can be considered. Will this "experimental" feature become part of Firestore at some point? I just don't want to spend thousands of hours developing an app counting on a "temporary" feature that may break the app once deprecated.

[wilhuff]

The flag is experimental but the fix is not. We marked it "experimental" to avoid making it a committed part of the API. Eventually we'll be rolling out a mechanism that can auto-detect this issue and fall back automatically. At that point we can remove the flag.

What kind of performance difference are you seeing?

[remyayad]

I've been using the app for a few day and it seems as though the performance was impacted only on the first day. Might've been a network issue. Thanks to all for your support in solving this issue!