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 зависимост може да изглежда, че засяга една връзка, докато друг път остава непроменен, и прави бъдещото обновяване на зависимости по-трудно за разбиране.