Firebase Admin Node httpAgent: mbulimi i proxy-t sipas shërbimit
Përcaktoni cilat operacione të Firebase Admin Node përdorin agjentin HTTP të konfiguruar përpara se të supozoni se i gjithë trafiku i SDK-së përdor të njëjtin proxy.
Një thirrje vërtetimi funksionon përmes proxy-t, por një lidhje me bazën e të dhënave dështon. Në një aplikacion Firebase, kjo mund të jetë një ndryshim transporti dhe jo një proxy i ndërprerë.
Opsioni i aplikacionit httpAgent i Admin Node SDK zbatohet për shërbimet që bëjnë thirrje REST, duke përfshirë Auth dhe Messaging. Fusha e tij e dokumentuar përjashton Realtime Database dhe Firestore. Edhe objektet e kredencialeve kanë konfigurimin e tyre të agjentit përmes metodave përkatëse të fabrikës së kredencialeve.
| Operacioni që dështon | Konfigurimi për t'u kontrolluar |
|---|---|
| Thirrje shërbimi REST i Admin | Agjenti HTTP i aplikacionit |
| Marrja e një tokeni kredenciali | Konfigurimi HTTP i objektit të kredencialit |
| Lidhje me bazën e të dhënave | Mbështetja e transportit e vetë klientit të bazës së të dhënave |
Kjo është arsyeja pse shtimi i një agjenti në inicializim nuk mund të vërtetojë se çdo lidhje e mëvonshme ndjek të njëjtën rrugë. Shënoni shërbimin dhe destinacionin që dështon përpara se të ndryshoni një konfigurim që tashmë funksionon për një shërbim tjetër.
Diskutimet e vjetra gjithashtu përziejnë mjetin e linjës së komandës Firebase me SDK-të e aplikacioneve. Një rregullim i CLI për të lexuar http_proxy nuk vërteton që një klient i bazës së të dhënave brenda procesit tuaj Node përdor të njëjtin opsion.
Përdorni ndërfaqen e konfigurimit të mbështetur për transportin që ju nevojitet vërtet. Rregullimi i një varësie të mbivendosur WebSocket mund të duket se prek një lidhje ndërsa një rrugë tjetër mbetet e pandryshuar, dhe e bën më të vështirë arsyetimin për një përditësim të ardhshëm të varësive.