Firebase Admin Node httpAgent: Proxy-Abdeckung nach Dienst
Ermitteln Sie, welche Firebase-Admin-Node-Vorgänge den konfigurierten HTTP-Agent nutzen, bevor Sie annehmen, dass der gesamte SDK-Datenverkehr denselben Proxy verwendet.
Ein Authentifizierungsaufruf funktioniert über den Proxy, aber eine Datenbankverbindung schlägt fehl. In einer Firebase-Anwendung kann das ein Unterschied im Transportweg sein und kein sporadisch ausfallender Proxy.
Die Anwendungsoption httpAgent des Admin Node SDK gilt für Dienste, die REST-Aufrufe ausführen, darunter Auth und Messaging. Ihr dokumentierter Umfang schließt Realtime Database und Firestore aus. Auch Anmeldedaten-Objekte haben über die entsprechenden Factory-Methoden eine eigene Agent-Konfiguration.
| Fehlschlagender Vorgang | Zu prüfende Konfiguration |
|---|---|
| Ein Admin-REST-Dienstaufruf | Der HTTP-Agent der Anwendung |
| Abrufen eines Anmeldedaten-Tokens | Die HTTP-Konfiguration des Anmeldedaten-Objekts |
| Eine Datenbankverbindung | Die eigene Transportunterstützung des Datenbankclients |
Deshalb kann ein zusätzlicher Agent bei der Initialisierung nicht garantieren, dass jede spätere Verbindung denselben Weg nimmt. Notieren Sie den fehlschlagenden Dienst und das Ziel, bevor Sie eine Konfiguration ändern, die für einen anderen Dienst bereits funktioniert.
Ältere Diskussionen vermischen zudem das Firebase-Kommandozeilenwerkzeug mit Anwendungs-SDKs. Eine CLI-Korrektur zum Lesen von http_proxy belegt nicht, dass ein Datenbankclient in Ihrem Node-Prozess dieselbe Option verwendet.
Nutzen Sie die unterstützte Konfigurationsschnittstelle für den Transport, den Sie tatsächlich benötigen. Das Patchen einer verschachtelten WebSocket-Abhängigkeit kann eine Verbindung beeinflussen, während ein anderer Pfad unverändert bleibt, und macht eine künftige Abhängigkeitsaktualisierung schwerer nachvollziehbar.