Firebase Admin Node httpAgent: cobertura do proxy por serviço
Identifique quais operações do Firebase Admin Node usam o agente HTTP configurado antes de supor que todo o tráfego do SDK passa pelo mesmo proxy.
Uma chamada de autenticação funciona através do proxy, mas uma conexão com o banco de dados falha. Em uma aplicação Firebase, isso pode ser uma diferença de transporte e não um proxy intermitente.
A opção de aplicação httpAgent do Admin Node SDK aplica-se aos serviços que fazem chamadas REST, incluindo Auth e Messaging. Seu escopo documentado exclui o Realtime Database e o Firestore. Os objetos de credenciais também têm sua própria configuração de agente pelos métodos de fábrica de credenciais correspondentes.
| Operação que falha | Configuração a inspecionar |
|---|---|
| Uma chamada de serviço REST do Admin | O agente HTTP da aplicação |
| Obter um token de credencial | A configuração HTTP do objeto de credencial |
| Uma conexão com o banco de dados | O suporte de transporte próprio do cliente do banco de dados |
Por isso, adicionar um agente na inicialização não pode certificar que toda conexão posterior siga o mesmo caminho. Anote o serviço e o destino que falham antes de alterar uma configuração que já funciona para outro serviço.
Discussões antigas também misturam a ferramenta de linha de comando do Firebase com SDKs de aplicação. Uma correção na CLI para ler http_proxy não estabelece que um cliente de banco de dados dentro do seu processo Node use essa mesma opção.
Use a interface de configuração suportada para o transporte de que você realmente precisa. Aplicar um patch em uma dependência WebSocket aninhada pode parecer afetar uma conexão enquanto deixa outro caminho inalterado, e torna mais difícil raciocinar sobre uma atualização futura de dependências.