Firebase Admin Node httpAgent : couverture du proxy par service
Déterminez quelles opérations de Firebase Admin Node utilisent l'agent HTTP configuré avant de supposer que tout le trafic du SDK passe par le même proxy.
Un appel d'authentification fonctionne via le proxy, mais une connexion à la base de données échoue. Dans une application Firebase, cela peut être une différence de transport plutôt qu'un proxy intermittent.
L'option d'application httpAgent du SDK Admin Node s'applique aux services qui effectuent des appels REST, notamment Auth et Messaging. Son périmètre documenté exclut Realtime Database et Firestore. Les objets d'informations d'identification disposent aussi de leur propre configuration d'agent via les méthodes de fabrique correspondantes.
| Opération en échec | Configuration à examiner |
|---|---|
| Un appel de service REST Admin | L'agent HTTP de l'application |
| Obtention d'un jeton d'identification | La configuration HTTP de l'objet d'informations d'identification |
| Une connexion à la base de données | La prise en charge du transport propre au client de base de données |
C'est pourquoi ajouter un agent à l'initialisation ne garantit pas que chaque connexion ultérieure emprunte le même chemin. Notez le service et la destination en échec avant de modifier une configuration qui fonctionne déjà pour un autre service.
Les anciennes discussions mélangent aussi l'outil en ligne de commande Firebase avec les SDK d'application. Un correctif de la CLI pour lire http_proxy ne prouve pas qu'un client de base de données dans votre processus Node utilise cette même option.
Utilisez l'interface de configuration prise en charge pour le transport dont vous avez réellement besoin. Corriger une dépendance WebSocket imbriquée peut sembler affecter une connexion tout en laissant un autre chemin inchangé, et rend plus difficile le raisonnement sur une future mise à jour des dépendances.