Firebase Admin Node httpAgent: सेवा अनुसार प्रोक्सी कभरेज
सबै SDK ट्राफिक एउटै प्रोक्सी प्रयोग गर्छ भनी मान्नु अघि कुन Firebase Admin Node सञ्चालनहरूले कन्फिगर गरिएको HTTP एजेन्ट प्रयोग गर्छन् पहिचान गर्नुहोस्।
प्रमाणीकरण कल प्रोक्सीमार्फत काम गर्छ, तर डेटाबेस जडान असफल हुन्छ। Firebase अनुप्रयोगमा यो बीचबीचमा आउने प्रोक्सी नभई ट्रान्सपोर्टको भिन्नता हुन सक्छ।
Admin Node SDK को httpAgent अनुप्रयोग विकल्प REST कल गर्ने सेवाहरूमा लागू हुन्छ, जसमा Auth र Messaging पर्छन्। यसको कागजात गरिएको दायराले Realtime Database र Firestore समावेश गर्दैन। क्रेडेन्सियल वस्तुहरूको पनि सम्बन्धित क्रेडेन्सियल फ्याक्ट्री विधिहरूमार्फत आफ्नै एजेन्ट कन्फिगरेसन हुन्छ।
| असफल सञ्चालन | जाँच्नुपर्ने कन्फिगरेसन |
|---|---|
| Admin REST सेवा कल | अनुप्रयोगको HTTP एजेन्ट |
| क्रेडेन्सियल टोकन प्राप्त गर्ने | क्रेडेन्सियल वस्तुको HTTP कन्फिगरेसन |
| डेटाबेस जडान | डेटाबेस क्लाइन्टको आफ्नै ट्रान्सपोर्ट समर्थन |
त्यसैले इनिसियलाइजेसनमा एजेन्ट थप्दा पछिका हरेक जडान एउटै मार्ग लिन्छ भन्ने सुनिश्चित गर्न सकिँदैन। अर्को सेवाका लागि पहिले नै काम गरिरहेको कन्फिगरेसन परिवर्तन गर्नु अघि असफल सेवा र गन्तव्य रेकर्ड गर्नुहोस्।
पुराना छलफलहरूले Firebase कमाण्ड-लाइन उपकरणलाई अनुप्रयोग SDK सँग पनि मिसाउँछन्। http_proxy पढ्नका लागि CLI सुधारले तपाईंको Node प्रक्रियाभित्रको डेटाबेस क्लाइन्टले त्यही विकल्प प्रयोग गर्छ भनी प्रमाणित गर्दैन।
तपाईंलाई साँच्चै आवश्यक ट्रान्सपोर्टका लागि समर्थित कन्फिगरेसन इन्टरफेस प्रयोग गर्नुहोस्। नेस्टेड WebSocket निर्भरता प्याच गर्दा एउटा जडानमा असर पर्ला जस्तो देखिन सक्छ जबकि अर्को मार्ग अपरिवर्तित रहन्छ, र भविष्यको निर्भरता अद्यावधिक बुझ्न गाह्रो बनाउँछ।