Firebase Admin Node httpAgent: copertura del proxy per servizio
Individuate quali operazioni di Firebase Admin Node utilizzano l'agente HTTP configurato prima di supporre che tutto il traffico dell'SDK passi dallo stesso proxy.
Una chiamata di autenticazione funziona attraverso il proxy, ma una connessione al database non riesce. In un'applicazione Firebase può trattarsi di una differenza di trasporto e non di un proxy intermittente.
L'opzione applicativa httpAgent dell'Admin Node SDK si applica ai servizi che effettuano chiamate REST, inclusi Auth e Messaging. Il suo ambito documentato esclude Realtime Database e Firestore. Anche gli oggetti credenziali hanno una propria configurazione dell'agente tramite i metodi factory corrispondenti.
| Operazione che non riesce | Configurazione da controllare |
|---|---|
| Chiamata a un servizio REST Admin | L'agente HTTP dell'applicazione |
| Ottenimento di un token di credenziale | La configurazione HTTP dell'oggetto credenziale |
| Connessione al database | Il supporto di trasporto proprio del client del database |
Per questo aggiungere un agente all'inizializzazione non può garantire che ogni connessione successiva segua lo stesso percorso. Annotate il servizio e la destinazione che non funzionano prima di modificare una configurazione che già funziona per un altro servizio.
Le vecchie discussioni confondono anche lo strumento da riga di comando di Firebase con gli SDK applicativi. Una correzione della CLI per leggere http_proxy non dimostra che un client di database nel vostro processo Node usi la stessa opzione.
Usate l'interfaccia di configurazione supportata per il trasporto di cui avete davvero bisogno. Correggere una dipendenza WebSocket annidata può sembrare influire su una connessione lasciandone invariata un'altra, e rende più difficile ragionare su un futuro aggiornamento delle dipendenze.