Firebase Admin Node httpAgent: покриття проксі за сервісами
Визначте, які операції Firebase Admin Node використовують налаштований HTTP-агент, перш ніж припускати, що весь трафік SDK іде через один і той самий проксі.
Виклик автентифікації працює через проксі, але з'єднання з базою даних не вдається. У застосунку Firebase це може бути різниця в транспорті, а не періодичний проксі.
Параметр застосунку httpAgent у Admin Node SDK застосовується до сервісів, які виконують REST-виклики, зокрема Auth і Messaging. Його документована область не включає Realtime Database і Firestore. Об'єкти облікових даних також мають власну конфігурацію агента через відповідні фабричні методи.
| Збійна операція | Конфігурація для перевірки |
|---|---|
| Виклик сервісу Admin REST | HTTP-агент застосунку |
| Отримання токена облікових даних | HTTP-конфігурація об'єкта облікових даних |
| З'єднання з базою даних | Власна підтримка транспорту клієнта бази даних |
Тому додавання агента під час ініціалізації не може гарантувати, що кожне наступне з'єднання піде тим самим шляхом. Запишіть збійний сервіс і призначення, перш ніж змінювати конфігурацію, яка вже працює для іншого сервісу.
Старі обговорення також змішують інструмент командного рядка Firebase з SDK застосунків. Виправлення в CLI для читання http_proxy не доводить, що клієнт бази даних у вашому процесі Node використовує той самий параметр.
Використовуйте підтримуваний інтерфейс конфігурації для того транспорту, який вам справді потрібен. Виправлення вкладеної залежності WebSocket може виглядати як вплив на одне з'єднання, тоді як інший шлях залишається незмінним, і ускладнює розуміння майбутнього оновлення залежностей.