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 निर्भरता को पैच करना एक कनेक्शन को प्रभावित करता दिख सकता है जबकि दूसरा मार्ग अपरिवर्तित रहता है, और भविष्य के निर्भरता अपडेट को समझना कठिन बना देता है।

संबंधित लेख