Firebase Admin Node httpAgent. փոխանորդի ծածկույթը՝ ըստ ծառայության
Որոշեք, թե Firebase Admin Node-ի որ գործողություններն են օգտագործում կարգավորված HTTP agent-ը, նախքան ենթադրելը, որ ամբողջ SDK երթևեկությունն օգտագործում է նույն փոխանորդը։
Նույնականացման կանչը աշխատում է փոխանորդի միջով, սակայն տվյալների բազայի միացումը ձախողվում է։ Firebase հավելվածում դա կարող է լինել տրանսպորտի տարբերություն, այլ ոչ պարբերական փոխանորդ։
Admin Node SDK-ի httpAgent հավելվածի ընտրանքը կիրառվում է REST կանչեր կատարող ծառայությունների վրա, ներառյալ Auth-ը և Messaging-ը։ Դրա փաստաթղթավորված շրջանակը բացառում է Realtime Database-ը և Firestore-ը։ Հավատարմագրերի օբյեկտները նույնպես ունեն իրենց agent-ի կարգավորումը համապատասխան գործարանային մեթոդների միջոցով։
| Ձախողվող գործողություն | Ստուգվելիք կարգավորում |
|---|---|
| Admin REST ծառայության կանչ | Հավելվածի HTTP agent-ը |
| Հավատարմագրի թոքենի ստացում | Հավատարմագրի օբյեկտի HTTP կարգավորումը |
| Տվյալների բազայի միացում | Տվյալների բազայի կլիենտի սեփական տրանսպորտի աջակցությունը |
Այդ պատճառով նախաձեռնմանը agent ավելացնելը չի կարող հաստատել, որ յուրաքանչյուր հետագա միացում կանցնի նույն ուղին։ Գրանցեք ձախողվող ծառայությունը և նպատակակետը նախքան փոխելը մի կարգավորում, որն արդեն աշխատում է մեկ այլ ծառայության համար։
Հին քննարկումները նաև խառնում են Firebase հրամանի տողի գործիքը հավելվածների SDK-ների հետ։ http_proxy-ը կարդալու CLI ուղղումը չի ապացուցում, որ ձեր Node գործընթացի ներսում գտնվող տվյալների բազայի կլիենտն օգտագործում է նույն ընտրանքը։
Օգտագործեք աջակցվող կարգավորման ինտերֆեյսը ձեզ իրականում անհրաժեշտ տրանսպորտի համար։ Ներկառուցված WebSocket կախվածությունը կարկատելը կարող է թվալ, թե ազդում է մեկ միացման վրա, մինչդեռ մյուս ուղին մնում է անփոփոխ, և դժվարացնում է ապագա կախվածությունների թարմացումը հասկանալը։