Firebase Admin Node httpAgent: acoperirea proxy după serviciu
Identificați ce operațiuni Firebase Admin Node folosesc agentul HTTP configurat înainte de a presupune că tot traficul SDK trece prin același proxy.
Un apel de autentificare funcționează prin proxy, dar o conexiune la baza de date eșuează. Într-o aplicație Firebase, aceasta poate fi o diferență de transport, nu un proxy intermitent.
Opțiunea de aplicație httpAgent din Admin Node SDK se aplică serviciilor care fac apeluri REST, inclusiv Auth și Messaging. Domeniul ei documentat exclude Realtime Database și Firestore. Obiectele de acreditări au și ele propria configurație de agent prin metodele de fabrică corespunzătoare.
| Operațiune care eșuează | Configurație de verificat |
|---|---|
| Un apel de serviciu REST Admin | Agentul HTTP al aplicației |
| Obținerea unui token de acreditare | Configurația HTTP a obiectului de acreditare |
| O conexiune la baza de date | Suportul de transport propriu al clientului bazei de date |
De aceea adăugarea unui agent la inițializare nu poate garanta că fiecare conexiune ulterioară urmează aceeași rută. Notați serviciul și destinația care eșuează înainte de a modifica o configurație care funcționează deja pentru alt serviciu.
Discuțiile vechi amestecă și instrumentul de linie de comandă Firebase cu SDK-urile de aplicație. O corecție în CLI pentru citirea http_proxy nu demonstrează că un client de bază de date din procesul Node folosește aceeași opțiune.
Folosiți interfața de configurare acceptată pentru transportul de care aveți nevoie cu adevărat. Aplicarea unui patch unei dependențe WebSocket imbricate poate părea că afectează o conexiune lăsând nealterată altă cale, și face o actualizare viitoare a dependențelor mai greu de înțeles.