Firebase Admin Node httpAgent: pokrycie proxy według usługi
Ustal, które operacje Firebase Admin Node korzystają ze skonfigurowanego agenta HTTP, zanim założysz, że cały ruch SDK przechodzi przez ten sam serwer proxy.
Wywołanie uwierzytelniania działa przez proxy, ale połączenie z bazą danych kończy się niepowodzeniem. W aplikacji Firebase może to być różnica w transporcie, a nie sporadycznie znikające proxy.
Opcja aplikacji httpAgent w Admin Node SDK dotyczy usług wykonujących wywołania REST, w tym Auth i Messaging. Jej udokumentowany zakres wyklucza Realtime Database i Firestore. Obiekty poświadczeń mają też własną konfigurację agenta przez odpowiednie metody fabryki poświadczeń.
| Nieudana operacja | Konfiguracja do sprawdzenia |
|---|---|
| Wywołanie usługi REST Admin | Agent HTTP aplikacji |
| Uzyskanie tokenu poświadczeń | Konfiguracja HTTP obiektu poświadczeń |
| Połączenie z bazą danych | Własne wsparcie transportu klienta bazy danych |
Dlatego dodanie agenta podczas inicjalizacji nie może zagwarantować, że każde późniejsze połączenie pójdzie tą samą drogą. Zapisz nieudaną usługę i miejsce docelowe, zanim zmienisz konfigurację, która już działa dla innej usługi.
Stare dyskusje mylą też narzędzie wiersza poleceń Firebase z zestawami SDK aplikacji. Poprawka w CLI do odczytu http_proxy nie dowodzi, że klient bazy danych w procesie Node używa tej samej opcji.
Użyj obsługiwanego interfejsu konfiguracji dla transportu, którego naprawdę potrzebujesz. Łatanie zagnieżdżonej zależności WebSocket może wyglądać, jakby wpływało na jedno połączenie, podczas gdy inna ścieżka pozostaje niezmieniona, i utrudnia zrozumienie przyszłej aktualizacji zależności.