Firebase Admin Node httpAgent: proxydekning per teneste
Fastslå kva Firebase Admin Node-operasjonar som brukar den konfigurerte HTTP-agenten før du går ut frå at all SDK-trafikk brukar same proxy.
Eit autentiseringskall fungerer gjennom proxyen, men ei databasetilkopling feilar. I ein Firebase-applikasjon kan det vere ein transportforskjell snarare enn ein periodisk proxy.
Applikasjonsvalet httpAgent i Admin Node SDK gjeld tenester som gjer REST-kall, mellom anna Auth og Messaging. Det dokumenterte omfanget utelukkar Realtime Database og Firestore. Legitimasjonsobjekt har òg sin eigen agentkonfigurasjon gjennom dei tilsvarande fabrikkmetodane.
| Feilande operasjon | Konfigurasjon som må undersøkjast |
|---|---|
| Eit Admin REST-tenestekall | HTTP-agenten til applikasjonen |
| Å skaffe eit legitimasjons-token | HTTP-konfigurasjonen til legitimasjonsobjektet |
| Ei databasetilkopling | Databaseklienten sin eigen transportstøtte |
Difor kan det å leggje til ein agent ved initialisering ikkje garantere at kvar seinare tilkopling tek same rute. Noter den feilande tenesta og destinasjonen før du endrar ein konfigurasjon som allereie fungerer for ei anna teneste.
Eldre diskusjonar blandar òg Firebase-kommandolinjeverktøyet med applikasjons-SDK-ar. Ei CLI-retting for å lese http_proxy beviser ikkje at ein databaseklient i Node-prosessen din brukar same val.
Bruk det støtta konfigurasjonsgrensesnittet for transporten du faktisk treng. Å patche ein innebygd WebSocket-avhengigheit kan sjå ut som det påverkar éi tilkopling medan ein annan veg blir uendra, og det gjer ei framtidig avhengigheitsoppdatering vanskelegare å forstå.