Firebase Admin Node httpAgent: proxy-dekking per service
Bepaal welke Firebase Admin Node-bewerkingen de geconfigureerde HTTP-agent gebruiken voordat u aanneemt dat al het SDK-verkeer dezelfde proxy gebruikt.
Een authenticatieaanroep werkt via de proxy, maar een databaseverbinding mislukt. In een Firebase-applicatie kan dat een transportverschil zijn en geen sporadisch uitvallende proxy.
De applicatieoptie httpAgent van de Admin Node SDK geldt voor services die REST-aanroepen doen, waaronder Auth en Messaging. Het gedocumenteerde bereik sluit Realtime Database en Firestore uit. Ook credential-objecten hebben hun eigen agentconfiguratie via de bijbehorende credential-fabrieksmethoden.
| Mislukkende bewerking | Te onderzoeken configuratie |
|---|---|
| Een Admin REST-serviceaanroep | De HTTP-agent van de applicatie |
| Een credential-token verkrijgen | De HTTP-configuratie van het credential-object |
| Een databaseverbinding | De eigen transportondersteuning van de databaseclient |
Daarom kan het toevoegen van een agent bij de initialisatie niet garanderen dat elke latere verbinding dezelfde route neemt. Noteer de mislukkende service en bestemming voordat u een configuratie wijzigt die al werkt voor een andere service.
Oudere discussies verwarren ook de Firebase-opdrachtregeltool met applicatie-SDK's. Een CLI-correctie om http_proxy te lezen bewijst niet dat een databaseclient in uw Node-proces dezelfde optie gebruikt.
Gebruik de ondersteunde configuratie-interface voor het transport dat u echt nodig hebt. Het patchen van een geneste WebSocket-afhankelijkheid kan erop lijken één verbinding te beïnvloeden terwijl een ander pad ongewijzigd blijft, en maakt een toekomstige afhankelijkheidsupdate lastiger te doorgronden.