Firebase Admin Node httpAgent: cobertura do proxy por servizo
Identifique que operacións de Firebase Admin Node usan o axente HTTP configurado antes de supoñer que todo o tráfico do SDK emprega o mesmo proxy.
Unha chamada de autenticación funciona a través do proxy, pero unha conexión á base de datos falla. Nunha aplicación de Firebase, iso pode ser unha diferenza de transporte e non un proxy intermitente.
A opción de aplicación httpAgent do Admin Node SDK aplícase aos servizos que fan chamadas REST, incluídos Auth e Messaging. O seu ámbito documentado exclúe Realtime Database e Firestore. Os obxectos de credenciais tamén teñen a súa propia configuración de axente mediante os métodos de fábrica de credenciais correspondentes.
| Operación que falla | Configuración que revisar |
|---|---|
| Unha chamada a un servizo REST de Admin | O axente HTTP da aplicación |
| Obter un token de credencial | A configuración HTTP do obxecto de credencial |
| Unha conexión á base de datos | O soporte de transporte propio do cliente de base de datos |
Por iso engadir un axente na inicialización non pode certificar que todas as conexións posteriores sigan a mesma ruta. Anote o servizo e o destino que fallan antes de cambiar unha configuración que xa funciona para outro servizo.
As discusións antigas tamén mesturan a ferramenta de liña de ordes de Firebase cos SDK de aplicacións. Unha corrección da CLI para ler http_proxy non demostra que un cliente de base de datos dentro do seu proceso Node use esa mesma opción.
Use a interface de configuración admitida para o transporte que realmente necesita. Parchear unha dependencia de WebSocket aniñada pode parecer que afecta unha conexión mentres deixa outra ruta sen cambios, e dificulta razoar sobre unha futura actualización de dependencias.