Firebase Admin Node httpAgent: proxy-dækning pr. tjeneste
Afgør hvilke Firebase Admin Node-handlinger der bruger den konfigurerede HTTP-agent, før du antager, at al SDK-trafik bruger samme proxy.
Et godkendelseskald virker gennem proxyen, men en databaseforbindelse fejler. I en Firebase-applikation kan det være en transportforskel snarere end en periodisk proxy.
Applikationsindstillingen httpAgent i Admin Node SDK gælder for tjenester, der laver REST-kald, herunder Auth og Messaging. Dets dokumenterede omfang udelukker Realtime Database og Firestore. Legitimationsobjekter har også deres egen agentkonfiguration via de tilsvarende fabriksmetoder.
| Fejlende handling | Konfiguration, der skal undersøges |
|---|---|
| Et Admin REST-tjenestekald | Applikationens HTTP-agent |
| Anskaffelse af et legitimations-token | Legitimationsobjektets HTTP-konfiguration |
| En databaseforbindelse | Databaseklientens egen transportunderstøttelse |
Derfor kan tilføjelse af en agent ved initialisering ikke garantere, at alle senere forbindelser tager samme rute. Notér den fejlende tjeneste og destination, før du ændrer en konfiguration, der allerede virker for en anden tjeneste.
Gamle diskussioner blander også Firebase-kommandolinjeværktøjet med applikations-SDK'er. En CLI-rettelse til at læse http_proxy beviser ikke, at en databaseklient i din Node-proces bruger samme indstilling.
Brug den understøttede konfigurationsgrænseflade til den transport, du faktisk har brug for. Patchning af en indlejret WebSocket-afhængighed kan se ud til at påvirke én forbindelse, mens en anden vej forbliver uændret, og det gør en fremtidig afhængighedsopdatering sværere at gennemskue.