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