Firebase Admin Node httpAgent: proxy estaldura zerbitzuaren arabera
Zehaztu zein Firebase Admin Node eragiketa erabiltzen duen konfiguratutako HTTP agentea, SDK trafiko guztiak proxy bera erabiltzen duela suposatu aurretik.
Autentifikazio dei bat proxyaren bidez funtzionatzen du, baina datu-baseko konexio batek huts egiten du. Firebase aplikazio batean, hori garraio-desberdintasuna izan daiteke, eta ez proxy aldizkakoa.
Admin Node SDKren httpAgent aplikazio-aukerak REST deiak egiten dituzten zerbitzuei eragiten die, Auth eta Messaging barne. Bere dokumentatutako irismenak Realtime Database eta Firestore baztertzen ditu. Kredentzialen objektuek ere badute beren agente-konfigurazioa dagozkien kredentzialen fabrika-metodoen bidez.
| Huts egiten duen eragiketa | Egiaztatzeko konfigurazioa |
|---|---|
| Admin REST zerbitzu-dei bat | Aplikazioaren HTTP agentea |
| Kredentzial token bat lortzea | Kredentzial objektuaren HTTP konfigurazioa |
| Datu-baseko konexio bat | Datu-baseko bezeroaren garraio-euskarri propioa |
Horregatik, hasieraketan agente bat gehitzeak ezin du ziurtatu geroagoko konexio guztiek bide bera hartzen dutenik. Idatzi huts egiten duen zerbitzua eta helmuga, beste zerbitzu baterako dagoeneko funtzionatzen duen konfigurazioa aldatu aurretik.
Eztabaida zaharrek Firebase komando-lerroko tresna aplikazioen SDKekin ere nahasten dute. http_proxy irakurtzeko CLI konponketa batek ez du frogatzen zure Node prozesuaren barruko datu-baseko bezero batek aukera hori bera erabiltzen duenik.
Erabili benetan behar duzun garraiorako onartutako konfigurazio-interfazea. WebSocket mendekotasun habiaratu bat adabaki egiteak konexio bat ukitzen duela eman dezake, beste bide bat aldatu gabe utziz, eta etorkizuneko mendekotasun-eguneratzea ulertzeko zailagoa egiten du.