Firebase-tools: एमुलेटर सूट में फायरबेस प्रमाणीकरण एमुलेटर जोड़ें

@vladimirdjurdjevic इसे उठाने के लिए धन्यवाद! यह हमारे कामों की सूची में है, लेकिन हमने अभी तक यह तय नहीं किया है कि कितनी प्रामाणिक सेवा का अनुकरण करना है और इसे करने के लिए सबसे अच्छी रणनीति क्या है। कुछ चीजें (जैसे अनाम लेख) का अनुकरण करना बहुत आसान है जबकि अन्य (जैसे एसएमएस प्रमाणीकरण) बहुत कठिन हैं।

लेकिन हम निश्चित रूप से आपके द्वारा उल्लिखित एंड-टू-एंड उपयोग के मामले को सक्षम करना चाहते हैं!

प्रश्न: क्या आपको यह उपयोगी लगेगा यदि कोई पुस्तकालय था जो आपको एमुलेटर के साथ उपयोग के लिए स्थानीय रूप से एक फायरबेस उपयोगकर्ता का मजाक उड़ाने की अनुमति देता था? कुछ इस तरह:

firebase.auth().setEmulatedUser({
   uid: 'abc123',
   // ...
});

@samtstern क्या setEmulatedUser() पर कॉल भी किसी भी functions.auth.user().onCreate() एमुलेटेड क्लाउड फंक्शन को ट्रिगर करेगा? अगर ऐसा है तो यह बहुत उपयोगी होगा।

@samtstern यह निश्चित रूप से कुछ परीक्षण परिदृश्यों में मदद करेगा, लेकिन फिर भी विकास के लिए वास्तविक उदाहरण की आवश्यकता है। मेरा विचार है कि विभिन्न वातावरणों के लिए कई फायरबेस प्रोजेक्ट बनाने से बचें, और स्थानीय रूप से (ऑफलाइन शायद) विकसित करने में सक्षम हों। एक अन्य दृष्टिकोण सेवाओं के लिए विभिन्न वातावरणों का समर्थन करना होगा। अगर हम एक ही प्रोजेक्ट के तहत फायरस्टोर और ऑथ के लिए अलग-अलग वातावरण बना सकते हैं, तो यह कई मुद्दों को हल करेगा। मुझे पता है कि मैं प्रति पर्यावरण परियोजना बना सकता हूं, लेकिन यह गधे में एक वास्तविक दर्द है। प्रत्येक वातावरण को कॉन्फ़िगर करना, डेटा की प्रतिकृति बनाना, आदि। आदर्श रूप से, मैं एक फायरबेस प्रोजेक्ट बनाने में सक्षम होना चाहता हूं, और यदि मुझे मैन्युअल परीक्षण के लिए डमी डेटा की आवश्यकता है, तो मैं केवल फायरस्टोर के लिए एक स्टेजिंग वातावरण बना सकता हूं, और वहां डेटा अपलोड कर सकता हूं।

@noelmansour अच्छा सवाल है! ऐसा करना बहुत कठिन नहीं होगा, हम शायद signInAsEmulatedUser और signUpAsEmulatedUser जैसे दो अलग-अलग कॉल चाहते हैं जहां केवल दूसरा फ़ंक्शन ट्रिगर करता है।

@vladimirdjurdjevic पूरी तरह से सहमत हैं कि एक पूर्ण विशेषताओं वाला एमुलेटर सबसे अच्छा है। क्या आप बता सकते हैं कि "विकास के लिए वास्तविक उदाहरण" से आपको किन चीजों की आवश्यकता होगी जो उपयोगकर्ता को स्थानीय रूप से सेट करने में सक्षम होने से हल नहीं होती हैं?

प्रश्न: क्या आपको यह उपयोगी लगेगा यदि कोई पुस्तकालय था जो आपको एमुलेटर के साथ उपयोग के लिए स्थानीय रूप से एक फायरबेस उपयोगकर्ता का मजाक उड़ाने की अनुमति देता था?

वास्तव में उपयोगी, इससे बहुत मदद मिलेगी।
अभी मैं केवल true सेट कर रहा हूं, हर बार जब मुझे स्थानीय रूप से कुछ परीक्षण करना होता है तो लॉग उपयोगकर्ता को मान्य करने वाला नियम फ़ंक्शन, यह बहुत असुरक्षित है, फिर भी शायद सरल चीज जो मैं अनुकरण किए गए वर्तमान उपयोगकर्ता के बिना कर सकता हूं।

हाँ यह अविश्वसनीय रूप से उपयोगी होगा

मैं यूनिट परीक्षण functions.auth.user().onCreate() भी करना चाहता हूं। मुझे लगता है कि अभी सबसे अच्छा समाधान अनिवार्य रूप से निर्यात कॉलबैक फ़ंक्शन है जो onCreate और नकली user ऑब्जेक्ट की आपूर्ति करता है।

उस तरह के यूनिट परीक्षण के लिए फायरबेस-फ़ंक्शंस-टेस्ट देखें
पुस्तकालय, जो आपको नकली डेटा के साथ अपने फ़ंक्शन हैंडलर को आमंत्रित करने में मदद करता है।

सूर्य पर, अक्टूबर १३, २०१९, ५:४४ पूर्वाह्न डैनियल के. नोटिफिकेशन @github.com ने लिखा:

मैं इकाई परीक्षण कार्य भी करना चाहूंगा।auth.user().onCreate()। मैं
मान लीजिए कि अभी सबसे अच्छा समाधान अनिवार्य रूप से निर्यात कॉलबैक है
फ़ंक्शन ऑनक्रिएट पर पारित हुआ और उस पर नकली उपयोगकर्ता ऑब्जेक्ट की आपूर्ति करता है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/firebase/firebase-tools/issues/1677?email_source=notifications&email_token=ACATB2QYJLX2LNVDTWJV25TQOMJ4VA5CNFSM4I27PTFKYY3PNVWWK3WTUL52HS4DFVREXG43VMVHHQ#TEBZLEBNMV
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/ACATB2SO3IR6UB73F4EMZPTQOMJ4VANCNFSM4I27PTFA
.

@samtstern जो वास्तव में फायरस्टोर एमुलेटर के साथ काम करता है? इसके आधार पर मुझे यह आभास हुआ कि यह एक अलग उद्देश्य के लिए है।

https://firebase.google.com/docs/functions/unit-testing#initializing

मैं निश्चित रूप से यूनिट परीक्षण के लिए ऑनलाइन मोड नहीं चाहता, यह एक धीमी गति होगी। और मुझे यकीन नहीं है कि मैं "स्टबिंग" द्वारा फायरस्टोर एमुलेटर तक पहुंच सकता हूं।

@FredyC उन दस्तावेज़ों को इंगित करने के लिए धन्यवाद। उपयोग किए गए शब्द भ्रमित करने वाले हैं क्योंकि "मोड" एक स्विच नहीं है जिसे आप सक्षम कर सकते हैं, वे केवल उन रणनीतियों का वर्णन कर रहे हैं जिन्हें आप ले सकते हैं।

यदि आप अपने यूनिट परीक्षणों के साथ फायरस्टोर एमुलेटर शुरू करते हैं, तो आपका कोड निश्चित रूप से इससे जुड़ सकता है। यदि आप FIRESTORE_EMULATOR_HOST पर्यावरण चर सेट करते हैं तो फायरबेस व्यवस्थापक एसडीके स्वचालित रूप से फायरस्टोर एमुलेटर से कनेक्ट हो जाएगा ( firebase emulators:exec यह आपके लिए करता है)।

@samtstern मुझे अभी भी बिंदुओं को जोड़ने में समस्या है और यह सब मुझे functions.auth.user().onCreate() का परीक्षण करने में कैसे मदद करेगा? मेरा मतलब है कि यह बहुत अच्छा है कि फ़ंक्शन उत्पादन संस्करण के बजाय एमुलेटर से कनेक्ट होंगे, लेकिन यह केवल फायरस्टोर है, है ना? मैं वास्तव में फ़ंक्शन कोड को किक करने के लिए परीक्षणों से उपयोगकर्ता निर्माण का आह्वान कैसे करूं?

उल्लिखित फायरबेस-फ़ंक्शंस-टेस्ट में कुछ गूढ़ विधि makeUserRecord प्रतीत होती है, लेकिन इसका कोई मतलब नहीं है कि यह कैसे काम करेगा या वास्तव में इसका उपयोग कैसे किया जाएगा।

मैंने auth.createUserWithEmailAndPassword() को @firebase/testing पैकेज से कॉल करने का प्रयास किया, लेकिन यह अमान्य API कुंजी के बारे में शिकायत कर रहा है, इसलिए मुझे लगता है कि यह केवल ऑनलाइन संस्करण के साथ काम करेगा।

जब मैं आपके द्वारा उल्लिखित env चर के लिए org के

मैं https://github.com/firebase/functions-samples के माध्यम से भी ब्राउज़ कर रहा हूं लेकिन मुझे वहां यूनिट परीक्षण का कोई उदाहरण नहीं मिला।

क्या आप कृपया इसका कुछ अर्थ निकाल सकते हैं? :)

मेरे पास एक और मामला भी है, कुछ हद तक विपरीत, जहां क्लाउड फ़ंक्शन कोड admin.auth().getUserByEmail() कॉल का उपयोग कर रहा है। हैरानी की बात है कि यह त्रुटि के साथ समाप्त नहीं होता है, लेकिन मुझे नहीं पता कि मैं उस उपयोगकर्ता को कैसे बनाऊंगा ताकि इसे वापस किया जा सके। पूरे व्यवस्थापक मॉड्यूल का मज़ाक उड़ाते हुए, लेकिन वह पागल है :)

@samtstern देरी के लिए खेद है। जब मैं वास्तविक उदाहरण कहता हूं, मेरा मतलब वास्तविक उदाहरण है: डी आदर्श रूप से, मैं विकास के लिए अपनी कोणीय पर्यावरण फ़ाइल में कॉन्फ़िगरेशन को स्वैप करना चाहता हूं, और मेरे ऐप जैसे वास्तविक सुविधाओं को लागू करने के लिए वास्तविक एपीआई से बात कर रहा है, लेकिन यह वास्तव में मेरे पर चल रहा एमुलेटर है मशीन, और मैं इसे ऑफ़लाइन कर सकता हूं। अब, मैं उदाहरण के लिए एसएमएस भेजने की चुनौतियों को समझता हूं। यह अपेक्षा करना मूर्खतापूर्ण होगा कि एमुलेटर मेरे फोन पर वास्तविक एसएमएस भेजे, लेकिन आप शायद इसे कंसोल पर प्रिंट कर सकते हैं (एसएमएस की सामग्री जो भेजी जाएगी)। इसके साथ मूल्य से शायद यह अधिक परेशानी है। इसलिए मुझे लगता है कि प्रति प्रोजेक्ट कई वातावरणों का समर्थन करने से सामान बेहतर हो सकता है। विभिन्न वातावरणों के लिए कई परियोजनाओं के बीच कॉन्फ़िगरेशन को दोहराने में अधिक समय लगता है। और स्क्रिप्ट के लिए अलग-अलग फायरस्टोर परियोजनाओं में डेटा को सीड करने में सक्षम होने के लिए कई सेवा खातों का प्रबंधन भी एक दर्द है। इसलिए मैंने सिखाया कि अगर हमारे पास एक संपूर्ण फायरबेस प्लेटफॉर्म का अनुकरण किया गया है, तो हम इसे हर गैर-उत्पादन वातावरण के लिए उपयोग कर सकते हैं, और सिर्फ एक वास्तविक फायरबेस प्रोजेक्ट का प्रबंधन कर सकते हैं। लेकिन शायद प्रति परियोजना कई वातावरणों का समर्थन करना स्वीकार्य परिणाम के साथ एक बेहतर समाधान है।

@FredyC आपकी सभी प्रतिक्रिया के लिए धन्यवाद! यह देखना वास्तव में हमारे लिए मददगार है कि यह कितना भ्रमित करने वाला हो सकता है। प्रमाणीकरण से संबंधित अपने परीक्षण में लोग दो मुख्य चीजें करना चाहते हैं:

1. वास्तव में वास्तविक उपयोगकर्ता बनाए बिना फायरस्टोर या रीयलटाइम डेटाबेस जैसी सेवाओं का उपयोग करने के लिए साइन इन करें। अभी यही setEmulatedUser जैसा कुछ हल करेगा। यह आपको स्थानीय रूप से एक फर्जी ऑथ टोकन रखने की अनुमति देगा जिसे अनुकरणकर्ता स्वीकार करेंगे लेकिन इसे प्रोड द्वारा अस्वीकार कर दिया जाएगा। अधिक सुरक्षा, अधिक अलगाव, आदि।
2. वास्तव में सीधे प्रमाणीकरण का परीक्षण करें। इसमें कुछ टुकड़े होंगे:
   ए। एक प्रामाणिक एमुलेटर जो सभी आवश्यक एपीआई कॉल का जवाब देता है ताकि आप उस पर प्रामाणिक एसडीके को इंगित कर सकें।
   बी। उस एमुलेटर और फ़ंक्शन एमुलेटर के बीच एकीकरण ताकि .onCreate फ़ंक्शन सही ढंग से चालू हो जाएं।
   सी। फंक्शन एमुलेटर के अंदर ऑटो-मॉकिंग ताकि admin.auth() ऑथ एमुलेटर की ओर इशारा करे, ठीक वैसे ही जैसे हम आज फायरस्टोर और आरटीडीबी के लिए करते हैं।

मुझे लगता है कि स्पष्ट रूप से (2) सही कहानी है लेकिन मैं यह समझने की कोशिश कर रहा था कि कितने लोग खुश होंगे (1) क्योंकि इसे लागू करना और बनाए रखना काफी आसान है।

@samtstern मैं देखता हूं। अगर मैं गलत हूं तो मुझे सुधारें, लेकिन क्या (1) पहले ही हल नहीं हो गया है? मेरा मतलब है कि परीक्षणों में मैं केवल निम्नलिखित को कॉल कर सकता हूं और फायरस्टोर एमुलेटर मुझे उस उपयोगकर्ता के रूप में पहचान लेगा ताकि मैं सुरक्षा नियमों के खिलाफ परीक्षण कर सकूं। मैंने वास्तव में अभी तक कोशिश नहीं की है, लेकिन अब तक आशाजनक लग रहा है :)

  const app = firebase.initializeTestApp({
    projectId,
    auth: {
      uid: 'owner'
    }
  })

(2) निश्चित रूप से बहुत उपयोगी लगता है, लेकिन निश्चित रूप से निपटने के लिए बहुत अधिक जटिल है। अफसोस की बात है कि पूरे उत्पाद में मेरी अंतर्दृष्टि इतनी सीमित है, मैं वास्तव में यहां कोई उपयोगी विचार नहीं दे सकता।

मुझे लगता है कि इसे क्रमिक रूप से बनाया जाना चाहिए। सभी परिदृश्यों को एक साथ कवर करने का प्रयास करने के बजाय, इसे ज्ञात उपयोग के मामलों और चलते-फिरते जोड़ने के आधार पर बनाएं। मेरी सीमित राय में फ़ंक्शन ट्रिगर्स के साथ "उपयोगकर्ता डेटाबेस" का अनुकरण करना मुश्किल नहीं लगता है।

@FredyC आप सही कह रहे हैं कि (1) परीक्षण सूट के अंदर उपयोग के लिए हल किया गया है। लेकिन अन्य उपयोग का मामला वास्तव में आपके एंड्रॉइड/आईओएस/वेब ऐप को स्थानीय विकास के लिए सीधे एमुलेटर से जोड़ रहा है। इस मामले में आप @firebase/testing उपयोग नहीं कर सकते हैं।

अच्छा ऐसा है। ईमानदारी से, यह बहुत अच्छा होगा यदि @firebase/testing को अलग-अलग समाधानों के बजाय क्रॉस-प्लेटफ़ॉर्म का उपयोग किया जा सकता है। मेरा मतलब है कि एमुलेटर पर संचार को पुनर्निर्देशित करना कितना कठिन हो सकता है? क्या इसके लिए FIRESTORE_EMULATOR_HOST है? हालांकि मुझे लगता है कि FIREBASE_EMULATOR_HOST जैसा कुछ अधिक उपयुक्त होगा यदि एमुलेटर के पास अन्य सेवाएं भी होंगी।

@vladimirdjurdjevic मैं सोच रहा हूं, वास्तव में signInWithPhone विधि का मूल रूप से नकल करने के लिए काम नहीं करेगा ताकि आप इसके व्यवहार को नियंत्रित कर सकें? फिर आपको एक एमुलेटर के बारे में चिंता करने और कंसोल में सिम्युलेटेड एसएमएस कोड प्राप्त करने की आवश्यकता नहीं है :)

बेशक, फिर आपको फायरस्टोर के लिए एमुलेटर की ओर प्रमाणित करने के लिए किसी तरह की आवश्यकता है (और इससे कनेक्ट करें)। कुछ ऐसा जो मैंने पिछले https://github.com/firebase/firebase-tools/issues/1677#issuecomment -542897671 में उल्लिखित किया था। असुरक्षित टोकन उत्पन्न करने के लिए एक अंतर्निहित विधि है: https://github.com/firebase/firebase-js-sdk/blob/master/packages/testing/src/api/index.ts#L64। यकीन नहीं होता कि यह काम करेगा।

बेशक, तीसरे पक्ष के पुस्तकालयों का मज़ाक उड़ाना हमेशा इतना आसान नहीं होता है, लेकिन एक बार पता चल जाने के बाद, यह बहुत अच्छे परिणाम ला सकता है। आखिरकार, इसे आम तौर पर आसान बनाने के लिए इसे कुछ पुस्तकालय में निकाला जा सकता है।

मैं यह भी सोच रहा हूं कि ये साइनइन विधियां काफी अधिक त्रुटि कोड फेंक सकती हैं जो कि कुछ उचित परीक्षणों का भी ध्यान रखना चाहिए। मजाक करना भी आसान है।

@samtstern firebase.auth() नेमस्पेस संदर्भ को setEmulatedUser जैसे कुछ सामयिक के साथ विस्तारित करना मौजूदा अनुकरण रणनीतियों के साथ एक विरोधी पैटर्न की तरह लगता है। क्या वह सिफारिश शायद पैकेज पक्ष पर आसानी से विस्तारशीलता से प्रभावित है?

अन्य अनुकरणकर्ताओं के साथ इनलाइन, मैं HTTP पर एक अलग प्रमाणीकरण सेवा स्तर लॉन्च करने की अपेक्षा करता हूं और क्लाइंट-साइड कॉन्फ़िगरेशन मौजूदा एपीआई सतह को उपयोग करने के लिए रीडायरेक्ट कर सकता है।

उपयोगकर्ता नाम/पासवर्ड पर मूल उपयोगकर्ताओं के लिए सीआरयूडी का न्यूनतम समर्थन करने वाले व्यवस्थापक और क्लाइंट एपीआई के साथ विलक्षण AuthN मामलों की वापसी त्रुटियों के बजाय मेरे पास बहुत अधिक होगा। हेक, मुझे लगता है कि व्यवस्थापक में कस्टम टोकन समर्थन के साथ शुरू करना और signInWithCustomToken वास्तव में बहुत दूर तक जाएगा। हो सकता है कि डॉक्स में प्रकाशित एपीआई सपोर्ट मैट्रिक्स के साथ लो हैंगिंग फ्रूट लागू करें।

@FredyC बिंदु के लिए, एकीकरण initializeTestApp कॉल के लिए रूट करने के लिए एप्लिकेशन कोड में @firebase/testing को सशर्त रूप से आयात करना है। यह क्रिया दोनों प्रोजेक्ट टीमों के लिए बिल्ड-टाइम पर पैकेज बहिष्करण पर जोर देती है, और एमुलेटर रीडायरेक्ट कॉन्फ़िगरेशन को दो पैकेज एपीआई ( initializeTestApp और firestore.settings / functions.useFunctionsEmulator ) में भी फैलाती है।

ग्रह हैक!

एकीकरण के लिए वर्तमान रणनीति प्रामाणिक परीक्षण @firebase/testing को कस्टम initializeTestApp कॉल पर रूट करने के लिए एप्लिकेशन कोड में सशर्त रूप से आयात करना है।

उम, मैं उस विधि को परीक्षणों के अंदर बुला रहा हूं। चाल यह है कि नियमित initializeApp index.ts में रहता है जो कार्यों को आयात करता है। एमुलेटर शुरू होने पर इसे बुलाया जा रहा है, लेकिन जब परीक्षण निष्पादित हो रहे हैं, तो यह एक अलग प्रक्रिया है और यह एक दूसरे के साथ संघर्ष नहीं करती है। तो वास्तव में सशर्त आयात का कोई बोझ नहीं है।

बेशक, यह उदाहरण के परीक्षण के लिए अलग हो सकता है। वेब ऐप जहां टेस्ट रनर ऐप कोड के साथ प्रक्रिया साझा करेगा। हालांकि, यूनिट परीक्षण के साथ आप आमतौर पर एक संपूर्ण ऐप को एक परीक्षण में आयात नहीं करते हैं। initializeApp शायद कुछ कोड में किया जाता है जो परीक्षणों के लिए प्रासंगिक नहीं है और बिल्कुल आयात नहीं किया जाता है।

@FredyC यूनिट परीक्षणों के लिए प्रलेखित उपयोगों पर सहमत हुए। वास्तव में पूर्ण-ऐप परिदृश्यों के लिए बोल रहा था जहां एपिस डायवर्ज और डायनेमिक आयात दस्तावेज के नक्शे से दूर हो जाते हैं।

मैं आपको केवल Honestly, it would be kinda superb if @firebase/testing could be used cross-platform instead of having separate solutions लिए एट्रिब्यूशन देना चाहता हूं। डिजिटल हाई फाइव

@FredyC आपकी सभी प्रतिक्रिया के लिए धन्यवाद! यह देखना वास्तव में हमारे लिए मददगार है कि यह कितना भ्रमित करने वाला हो सकता है। प्रमाणीकरण से संबंधित अपने परीक्षण में लोग दो मुख्य चीजें करना चाहते हैं:

1. वास्तव में वास्तविक उपयोगकर्ता बनाए बिना फायरस्टोर या रीयलटाइम डेटाबेस जैसी सेवाओं का उपयोग करने के लिए साइन इन करें। अभी यही setEmulatedUser जैसा कुछ हल करेगा। यह आपको स्थानीय रूप से एक फर्जी ऑथ टोकन रखने की अनुमति देगा जिसे अनुकरणकर्ता स्वीकार करेंगे लेकिन इसे प्रोड द्वारा अस्वीकार कर दिया जाएगा। अधिक सुरक्षा, अधिक अलगाव, आदि।
2. वास्तव में सीधे प्रमाणीकरण का परीक्षण करें। इसमें कुछ टुकड़े होंगे:
   ए। एक प्रामाणिक एमुलेटर जो सभी आवश्यक एपीआई कॉल का जवाब देता है ताकि आप उस पर प्रामाणिक एसडीके को इंगित कर सकें।
   बी। उस एमुलेटर और फ़ंक्शन एमुलेटर के बीच एकीकरण ताकि .onCreate फ़ंक्शन सही ढंग से चालू हो जाएं।
   सी। फंक्शन एमुलेटर के अंदर ऑटो-मॉकिंग ताकि admin.auth() ऑथ एमुलेटर की ओर इशारा करे, ठीक वैसे ही जैसे हम आज फायरस्टोर और आरटीडीबी के लिए करते हैं।

मुझे लगता है कि स्पष्ट रूप से (2) सही कहानी है लेकिन मैं यह समझने की कोशिश कर रहा था कि कितने लोग खुश होंगे (1) क्योंकि इसे लागू करना और बनाए रखना काफी आसान है।

@samtstern सबसे पहले मैं इस तरह का अनुकरण करना चाहूंगा।

मैं देखूंगा नहीं। 1 e2e परीक्षण लिखने के लिए बहुत उपयोगी है। वर्तमान में मुझे प्रमाणीकरण के लिए वास्तविक उदाहरण का उपयोग करना है जबकि मैं होस्टिंग, नियम, फायरस्टोर और कार्यों के लिए एमुलेटर का उपयोग कर सकता हूं।

मुझे लगता है कि जिस तरह से यह firebase.initializeTestApp में किया गया है उसी तरह से उपयोगकर्ता का मजाक उड़ाने के लिए setEmulatedUser का उपयोग करना संभव होना चाहिए। सबमिट करना संभव होना चाहिए जैसे कस्टम टोकन और अन्य उपयोगकर्ता संबंधित डेटा।

नमूना क्रेडेंशियल प्राप्त करना भी संभव होना चाहिए जिसका उपयोग क्लाइंट ऐप में firebase.auth().signInWithCredential(credential) साथ किया जा सकता है

इस मुद्दे को उठाने के लिए

हम तीन चीजों के लिए एक वास्तविक एमुलेटर देखना चाहेंगे:

1. e2e पूरे ऐप के लिए परीक्षण करता है, इसलिए हमें अलग-अलग वातावरण बनाने की ज़रूरत नहीं है जैसा कि @vladimirdjurdjevic ने कहा।
2. बैकएंड के लिए एकीकरण परीक्षण, जहां एपीआई को कॉल किया जाता है और उपयोगकर्ता को फायरबेस पर मान्य किया जाना चाहिए।
3. हमारे सभी डेवलपर विकास के दौरान एक केंद्रीय फायरबेस वातावरण का उपयोग कर रहे हैं, जिससे बहुत सारी टक्करें होती हैं। बेशक, प्रत्येक डेवलपर अपना स्वयं का फायरबेस प्रोजेक्ट बना सकता है लेकिन उन्हें अभी भी फायरबेस डैशबोर्ड में अपने परीक्षण उपयोगकर्ताओं को प्रबंधित करने की आवश्यकता है जो आदर्श नहीं है। साथ ही, हम अपने ऐप को ऑफ़लाइन विकसित करना चाहते हैं जो कि वास्तविक एमुलेटर की कमी के कारण आज संभव नहीं है।

मुझे आशा है कि आप जल्द ही हमारे लिए कुछ जारी करेंगे, यह आपके उत्पाद को और अधिक मूल्यवान बना देगा! ऐसी सेवाओं में डेवलपर उत्पादकता बहुत महत्वपूर्ण है!

यह कई लोगों की इच्छा सूची में एक विशेषता प्रतीत होती है। Firebase प्रमाणीकरण अभी मूल्य निर्धारण के लिहाज से #1 IDaaS प्रतीत होता है, इसलिए यह वास्तव में एक दर्द है कि आप इसके साथ क्लाउड फ़ंक्शंस के साथ स्थानीय रूप से विकसित नहीं हो सकते। आशा है कि FB टीम के पास हमारे लिए जल्द ही अपडेट होंगे! 🙏

संपादित करें: @ फायरबेस -ऑप्स से करना क्योंकि यह धागा मुद्दों के तहत

मेरे पास यह त्रुटि भी है ... फ़ंक्शन को अनदेखा कर दिया गया क्योंकि ऑथ एमुलेटर मौजूद नहीं है या नहीं चल रहा है।

यह इस कोड द्वारा ट्रिगर किया गया है:

functions.auth.user().onDelete()

इस पर कोई जानकारी...

@dominikfoldi

मैं आपकी बातों से सहमत हूं। एक टिप जो इस बीच आपकी मदद कर सकती है:

बेशक, प्रत्येक डेवलपर अपना स्वयं का फायरबेस प्रोजेक्ट बना सकता है लेकिन उन्हें अभी भी फायरबेस डैशबोर्ड में अपने परीक्षण उपयोगकर्ताओं को प्रबंधित करने की आवश्यकता है जो आदर्श नहीं है।

आप फायरबेस व्यवस्थापक एसडीके का उपयोग करके प्रोग्रामेटिक रूप से उपयोगकर्ताओं को सीड और प्रबंधित कर सकते हैं, उदाहरण के लिए auth().createUser , यह भी देखें https://firebase.google.com/docs/auth/admin/manage-users

इस धागे को पढ़ने के बाद मुझे लगता है कि यहां के लोगों को फाउंड्री उपयोगी लग सकती है।

मैं फाउंड्री के सह-संस्थापकों में से एक हूं। फाउंड्री एक सीएलआई उपकरण है जो आपके फायरबेस क्लाउड फ़ंक्शंस को लेता है और हमारे सर्वर पर आपके प्रोडक्शन फायरबेस ऐप की एक प्रति बनाता है जो आपके विकास वातावरण के रूप में कार्य करता है जिसमें आप सीधे अपना कोड चलाते हैं। कोई कॉन्फ़िगरेशन की आवश्यकता नहीं है।

फाउंड्री आपकी स्रोत कोड फ़ाइलों को देखता है और हर बार जब आप स्थानीय रूप से अपना कोड सहेजते हैं तो हम इसे अपने सर्वर पर चलाते हैं और आपको कुछ ही सेकंड में परिणाम वापस दे देते हैं। सब कुछ सुपर फास्ट है।
आप निर्दिष्ट करते हैं कि हमारी YAML फ़ाइल के माध्यम से आपके उत्पादन ऐप से कौन से Firestore, RealtimeDB और Auth उपयोगकर्ता डेटा की प्रतिलिपि बनाई जानी चाहिए ताकि आप उन्हें विकास के दौरान उपलब्ध करा सकें।

 users:
      - getFromProd: 5 # Copy first 5 users from your Firebase project
      - getFromProd: ['id-1', 'id-2'] # Copy users with the specified IDs from your Firebase project

 # Copy first 3 documents from production from the collection 'userWorkspaces'
 # also add a custom document with id 'new-user-workspace' with a new data
 # format that you want to use
 firestore:
     - collection: userWorkspaces
       docs:
         - getFromProd: 3
         - id: new-user-workspace
           data: {"newDataFormat": 42}

आप यह भी निर्दिष्ट करते हैं कि जब हम आपका कोड चलाते हैं तो हमें आपके क्लाउड फ़ंक्शंस को कैसे ट्रिगर करना चाहिए। यह आपके क्लाउड कार्यों के लिए एक आरईपीएल की तरह काम करता है। इस तरह आप हमेशा सुनिश्चित होते हैं कि आपके क्लाउड फ़ंक्शंस उत्पादन डेटा और उत्पादन परिवेश में आपके द्वारा उन्हें परिनियोजित करने के बाद सही ढंग से काम करेंगे।
साथ ही, आपके क्लाउड फ़ंक्शन ऐसे कार्य करते हैं जैसे वे परिनियोजित किए गए हों।

एक बार जब आप अपना सत्र शुरू करते हैं तो ये देव परिवेश एड-हॉक बन जाते हैं। इसलिए आपकी टीम में हर कोई अपने वातावरण में काम करता है जहां वे गड़बड़ कर सकते हैं।

मैं यहां चर्चा को स्पैम नहीं करना चाहता, इसलिए बेझिझक मुझे कोई भी प्रश्न ईमेल करें [email protected]
मुझे आपकी परियोजनाओं में फाउंड्री स्थापित करने में मदद करने में बहुत खुशी हो रही है, बस मुझे एक ईमेल भेजें!

फिर भी, आपने इसका वर्णन कैसे किया और मैंने होमपेज पर जो पढ़ा, वह सेवा क्लाउड-आधारित है।
इसके बजाय फायरबेस एमुलेटर ऑफ़लाइन भी काम करता है, इसलिए स्वचालित परीक्षण के लिए इसकी उपयोगिता।

@samtstern इस मुद्दे/सुविधा के लिए कोई प्रगति या कोई अन्य समाधान? मुझे क्लाउड फायरस्टोर एमुलेटर के साथ काम करने के लिए (1) setEmulatedUser की आवश्यकता है ताकि मैं स्थानीय रूप से मैन्युअल परीक्षण कर सकूं। एक अन्य विकल्प कमांड लाइन तर्क होना होगा जो एम्यूलेटर शुरू होने पर उपयोगकर्ता आईडी सेट करता है। इस तरह एमुलेटर स्टार्ट-अप के दौरान पास की गई यूजर आईडी के तहत चलेगा। इस तरह नियमों का स्थानीय स्तर पर परीक्षण किया जा सकता है।

आपकी टिप्पणी के अनुसार: 17 अक्टूबर 2019 को
_मुझे लगता है कि स्पष्ट रूप से (2) सही कहानी है लेकिन मैं यह समझने की कोशिश कर रहा था कि कितने लोग खुश होंगे (1) क्योंकि इसे लागू करना और बनाए रखना काफी आसान है।

(१) वास्तव में वास्तविक उपयोगकर्ता बनाए बिना फायरस्टोर या रीयलटाइम डेटाबेस जैसी सेवाओं का उपयोग करने के लिए साइन इन करें। अभी यही कुछ ऐसा है जैसे setEmulatedUser हल करेगा। यह आपको स्थानीय रूप से एक फर्जी ऑथ टोकन रखने की अनुमति देगा जिसे अनुकरणकर्ता स्वीकार करेंगे लेकिन इसे प्रोड द्वारा अस्वीकार कर दिया जाएगा। अधिक सुरक्षा, अधिक अलगाव, आदि._

हम एक पूर्ण ऑथ एमुलेटर पर काम करने में कठिन हैं जो उम्मीद है कि क्या होगा
सभी चाहते हैं। मैं अभी कोई समयरेखा नहीं दे सकता, लेकिन यह एक उच्च प्राथमिकता है
हमारे लिए।

शुक्र, 22 मई 2020 8:12 पूर्वाह्न ChuckB पर पर [email protected] लिखा है:

@samtstern https://github.com/samttern कोई प्रगति या कोई अन्य
इस मुद्दे/सुविधा का समाधान? मुझे (1) setEmulatedUser के साथ काम करने की आवश्यकता है
क्लाउड फायरस्टोर एमुलेटर ताकि मैं स्थानीय रूप से मैन्युअल परीक्षण कर सकूं।

आपकी टिप्पणी के अनुसार: 17 अक्टूबर 2019 को
_मुझे लगता है कि स्पष्ट रूप से (2) सही कहानी है लेकिन मैं समझने की कोशिश कर रहा था
कितने लोग खुश होंगे (1) क्योंकि यह काफी आसान है
लागू करना और बनाए रखना।

(1) फायरस्टोर या रीयलटाइम डेटाबेस जैसी सेवाओं का उपयोग करने के लिए साइन इन करें बिना
वास्तव में वास्तविक उपयोगकर्ता बनाना। अभी तो कुछ ऐसा है
setEmulatedUser हल करेगा। यह आपको केवल एक फर्जी प्राधिकरण की अनुमति देगा
टोकन स्थानीय रूप से है कि अनुकरणकर्ता स्वीकार करेंगे लेकिन इसे अस्वीकार कर दिया जाएगा
उत्पाद अधिक सुरक्षा, अधिक अलगाव, आदि._

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/firebase/firebase-tools/issues/1677#issuecomment-632660684 ,
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/ACATB2Q4LV7NXMQFEALNPXLRSZT25ANCNFSM4I27PTFA
.

1. वास्तव में वास्तविक उपयोगकर्ता बनाए बिना फायरस्टोर या रीयलटाइम डेटाबेस जैसी सेवाओं का उपयोग करने के लिए साइन इन करें। अभी यही कुछ ऐसा है जैसे setEmulatedUser हल करेगा। यह आपको स्थानीय रूप से एक फर्जी ऑथ टोकन रखने की अनुमति देगा जिसे अनुकरणकर्ता स्वीकार करेंगे लेकिन इसे प्रोड द्वारा अस्वीकार कर दिया जाएगा। अधिक सुरक्षा, अधिक अलगाव, आदि।

मुझे यहां नंबर 1 से खुशी होगी, अंतरिम में

https://stackoverflow.com/questions/62736060/firebase-test-auth-cloud-functions-locally

क्या यह अभी भी असंभव है?

@ ऋषिसिंह-देव एक ऑथ एमुलेटर चलाना संभव नहीं है क्योंकि फायरबेस एमुलेटर वर्तमान में एक को शिप नहीं करते हैं।

लेकिन उन क्लाउड फ़ंक्शंस का परीक्षण करना पूरी तरह से संभव है जो उनमें शामिल हैं। फ़ायरबेस फ़ंक्शंस फ़ाइल पर वास्तविक प्रदान करते हुए, आप उस फ़ंक्शन को दोबारा कर सकते हैं जिसके लिए कुछ ऑथ एपीआई की आवश्यकता होती है और परीक्षणों पर इसका मजाक उड़ाया जाता है। आपके परीक्षण सेटअप की निष्ठा कम है, लेकिन फिर यह डिग्री का मामला बन जाता है, न कि किसी तरह का मामला: आप सीधे सीधे कॉल का परीक्षण कर रहे हैं, लेकिन आप परीक्षण कर सकते हैं कि आप उनसे क्या उम्मीद करते हैं।

उस SO प्रश्न में यह कुछ ऐसा होगा:

function sendWelcomeEmail(user) {
  console.log(user.uid);
  console.log(user.email);
  console.log(user.displayName);
}

exports.sendWelcomeEmail = functions.auth.user().onCreate((user) => sendWelcomeEmail(user));

और अपने परीक्षणों पर आप यह सुनिश्चित करने के लिए सीधे sendWelcomeEmail पर कॉल करते हैं कि यह वही करता है जो आपको करने की आवश्यकता है।

कल्पना कीजिए कि आपके पास addFriend नामक एक अधिक जटिल क्लाउड फ़ंक्शन है, जहां उपयोगकर्ता एक मित्र ईमेल इनपुट करता है और आप यूआईडी चाहते हैं। आप इसे getUserByEmail माध्यम से प्राप्त कर सकते हैं।

function addFriend(email, getUserByEmail ) {
  const friendUid = getUserByEmail(email);
  // do things with friendUid;
}

exports.addFriend = functions.https.onCall(async (data, context) => {
  const email = data.email;
  const getUserByEmail = (email) => admin.auth().getUserByEmail(email);
  return { res: await addFriend(email, getUserByEmail ) };
}

क्लाउड fn घोषणा पर आप वास्तविक getUserByEmail भेजते हैं, लेकिन अपने परीक्षणों पर आप इसके बजाय एक नकली भेजते हैं:

async function testAddFriend() {
  const emails = {"[email protected]": "test-uid")
  const fakeGetUserByEmail = (email) => emails[email];
  addFriend("[email protected]);
  // verify the things were done with friendUid
}

मुझे नहीं लगता कि यह यूनिट टेस्ट में किसी तीसरे पक्ष एपीआई के परीक्षण से काफी अलग है। फायरबेस एमुलेटर होने से बॉयलरप्लेट को एंड-टू-एंड परीक्षण परिदृश्यों को हटा देता है, लेकिन यह यूनिट परीक्षणों में महत्वपूर्ण रूप से बदलाव नहीं करता है क्योंकि आप नहीं चाहते कि लगातार स्थिति को परीक्षणों के बीच रखा जाए।

मैं जांच के लिए क्लाउड पर अपलोड किए बिना इसे स्थानीय रूप से चलाने में सक्षम होना पसंद करूंगा

export const onCreate = functions.auth.user().onCreate((user) => {
    addGravatarURLtoUserData(user.uid, user.email)
})

export const addGravatarURLtoUserData = async (uid, email) => {
    const hash = crypto.createHash("md5").update(email).digest("hex")
    await admin.database().ref(`users/${uid}`).update({ gravatarURL: uid })
}

वैसे, क्या मुझे onCreate फंक्शन के अंदर user.displayName मिल सकता है?

हाँ अगर यह सेट है तो मुझे लगता है, क्या आपने इसे आजमाया?

हाँ, यह शून्य लौटाता है।
मैंने इसे क्लाउड पर आज़माया (स्थानीय रूप से नहीं)।

मेरा कोड यहाँ है।

exports.sendWelcomeEmail = functions.auth.user().onCreate((user) => {
  console.log(user.uid);
  console.log(user.email);
  console.log(user.displayName);
});

दिलचस्प बात यह है कि मैं प्रदर्शन नाम का उपयोग नहीं करता, मैं कस्टम उपयोगकर्ता डिस्प्लेनाम का उपयोग करता हूं
वास्तविक समय डीबी

/**
 * updates Custom data in the realtime datastore users object, except for the username
 * <strong i="7">@param</strong> data
 * <strong i="8">@returns</strong> {Promise<void>}
 */
export async function updatePersonalData(data) {
    const { displayName } = data
    try {
        await firebase
            .database()
            .ref("users/" + firebase.auth().currentUser.uid)
            .update({
                displayName: displayName,
            })

        userDataStore.update((user) => {
            return { ...user, displayName: displayName }
        })
    } catch (e) {
        alert(e.message)
    }
}

शुक्र, १० जुलाई २०२० को १०:४४ बजे, ऋषीसिंह-देव नोटिफिकेशन @github.com
लिखा था:

हाँ, यह शून्य लौटाता है।
मैंने इसे क्लाउड पर आज़माया (स्थानीय रूप से नहीं)।

[छवि: स्क्रीन शॉट २०२०-०७-१० अपराह्न २ ४३ १२ बजे]
https://user-images.githubusercontent.com/56976320/87140958-29f3ac80-c257-11ea-98d3-084fad619de7.png

मेरा कोड यहाँ है।

कंसोल.लॉग (user.uid);
कंसोल.लॉग (user.email);
कंसोल.लॉग (user.displayName);
});```

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/firebase/firebase-tools/issues/1677#issuecomment-656587759 ,
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AABU35Q27EMMHYAYU5CNZR3R23PIDANCNFSM4I27PTFA
.

>

सधन्यवाद

निकोस कट्सिकानिसो

हां, मेरा प्राथमिक लक्ष्य onCreate फ़ंक्शन के अंदर उपयोगकर्ता जानकारी के साथ डेटाबेस को अपडेट करना था।
लेकिन चूंकि मुझे displayName नहीं मिल रहा है, onCallable फ़ंक्शन बनाया, और इसे किया।

धन्यवाद।

@samtstern मैं आपको इस पर काम करते हुए देखकर बहुत खुश हूं :)

एक और सबसे अच्छी बात यह है कि मुझे बिना सुरक्षा के क्रोम खोलने की जरूरत नहीं है

@samtstern

दो महीने बाद, क्या अब एक मोटा अनुमान देना संभव है?

हम अगले साल की शुरुआत में जहाज भेजना चाहते हैं। अब हमें इस निर्णय का सामना करना पड़ रहा है कि क्या हम वास्तविक परियोजना के खिलाफ एकीकरण परीक्षण लिखना शुरू करते हैं या यदि हम ऑथ एमुलेटर के लिए कुछ महीने प्रतीक्षा करते हैं। क्या आप यहां हमारी कुछ मदद कर सकते हैं?

श्रेष्ठ,

निकलस

Firebase पर हमारी नीति यह अनुमान लगाने की नहीं है कि कोई चीज़ कब लॉन्च होगी, जब तक कि हम 100% सुनिश्चित न हों। अभी हम प्रामाणिक एमुलेटर पर कड़ी मेहनत कर रहे हैं लेकिन हम लॉन्च की तारीख चुनने के लिए पर्याप्त नहीं हैं।

यह हमारी सर्वोच्च प्राथमिकताओं में से एक है, लेकिन मुझे लगता है कि आपको अपने ऐप का परीक्षण शुरू करने के लिए हमें इंतजार नहीं करना चाहिए। आज ही उत्पादों के खिलाफ अपने परीक्षण लिखें, उपलब्ध होने पर उन्हें एमुलेटर को लक्षित करने के लिए स्विच करें।

ठीक है, धन्यवाद @samtstern। यह सहायता करता है!

क्लाउड फ़ंक्शंस और फायरस्टोर अनुरोधों का परीक्षण करने के लिए हम वास्तव में एक ऑथ एमुलेटर का उपयोग करना चाहते हैं, जिसमें उपयोगकर्ता टोकन पर कस्टम दावे शामिल हैं। हम फायरबेस कंसोल में नियमों के खेल के मैदान में फायरस्टोर के साथ परीक्षण कस्टम दावों को सॉर्ट कर सकते हैं, लेकिन एक पूर्ण अधिकृत एमुलेटर सैद्धांतिक रूप से हमें उपयोगकर्ता टोकन की बात करते समय परीक्षण के तरीके में बहुत कुछ करने में सक्षम बनाता है।

स्पष्ट होने के लिए: हम एक पूर्ण अधिकृत एमुलेटर के लिए प्रतिबद्ध हैं जो वास्तविक सेवा समापन बिंदुओं (जहां भी संभव हो) का अनुकरण करता है। हम अब कुछ हल्के वजन पर विचार नहीं कर रहे हैं जैसे मेरी पिछली टिप्पणियों का सुझाव दिया गया था।

@samtstern यह सुनकर बहुत अच्छा लगा (कस्टम दावों के साथ, क्योंकि इसका उपयोग अक्सर तीसरे पक्ष के एकीकरण के साथ किया जाता है)। क्या कहीं भी हम प्रगति/ईटीए के साथ बने रह सकते हैं?

@fandy नहीं क्षमा करें हमारे पास अभी तक साझा करने के लिए कुछ भी नहीं है ...

धन्यवाद सैम, वर्तमान में मैं अपने सभी परीक्षण मैन्युअल रूप से कर रहा हूं क्योंकि यह नहीं है
प्रामाणिक मॉक के बिना e2e परीक्षण लिखने के प्रयास के लायक

बुधवार, 26 अगस्त 2020 को 14:32 बजे, सैम स्टर्न नोटिफिकेशन @github.com ने लिखा:

>
>

@fandy https://github.com/fandy नहीं क्षमा करें हमारे पास कुछ भी नहीं है
अभी तक साझा करें ...

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/firebase/firebase-tools/issues/1677#issuecomment-680850282 ,
या सदस्यता समाप्त करें
https://github.com/notifications/unsubscribe-auth/AABU35UAQDBYEXKKINJSM43SCT6E7ANCNFSM4I27PTFA
.

--

सधन्यवाद

निकोस कट्सिकानिसो

इसके आसपास काम करने के लिए, मैंने ब्राउज़र में @firebase/testing आयात करने के साथ प्रयोग किया। यह वास्तव में काम नहीं किया। हालांकि, यह करता है: निम्नलिखित थोड़ा संपादित खंड को कॉपी करने के लिए @ फायरबेस/परीक्षण स्रोत को मैनेज करें:

import firebase from "firebase/app"
import * as component from "@firebase/component"
import * as util from "@firebase/util"
import { __awaiter, __generator } from "tslib"

function createUnsecuredJwt(auth) {
    // Unsecured JWTs use "none" as the algorithm.
    var header = {
        alg: 'none',
        kid: 'fakekid'
    };
    // Ensure that the auth payload has a value for 'iat'.
    auth.iat = auth.iat || 0;
    // Use `uid` field as a backup when `sub` is missing.
    auth.sub = auth.sub || auth.uid;
    if (!auth.sub) {
        throw new Error("auth must be an object with a 'sub' or 'uid' field");
    }
    // Unsecured JWTs use the empty string as a signature.
    var signature = '';
    return [
        util.base64.encodeString(JSON.stringify(header), /*webSafe=*/ false),
        util.base64.encodeString(JSON.stringify(auth), /*webSafe=*/ false),
        signature
    ].join('.');
}

function initializeApp(accessToken, options) {
    var _this = this;
    var app = firebase.initializeApp(options);
    if (accessToken) {
        var mockAuthComponent = new component.Component('auth-internal', function () {
            return ({
                getToken: function () { return __awaiter(_this, void 0, void 0, function () { return __generator(this, function (_a) {
                    return [2 /*return*/, ({ accessToken: accessToken })];
                }); }); },
                getUid: function () { return null; },
                addAuthTokenListener: function (listener) {
                    // Call listener once immediately with predefined accessToken.
                    listener(accessToken);
                },
                removeAuthTokenListener: function () { }
            });
        }, "PRIVATE" /* PRIVATE */);
        app._addOrOverwriteComponent(mockAuthComponent);
    }
    return app;
}

export function initializeTestApp(options) {
  let accessToken = undefined
  if (options.auth !== undefined) {
    accessToken = createUnsecuredJwt(options.auth)
  }
  return initializeApp(accessToken, options)
}

अब अपने ऐप ब्राउज़र-साइड कोड में, आप उसे आयात कर सकते हैं, और

  let app
  if (dev) {
    app = initializeTestApp({projectId: "test", auth: {uid: "testuser"}})
    app.firestore().settings({
      host: "localhost:8080",
      ssl: false,
    })
  } else {
    app = firebaseProduction.initializeApp({ firebase config here })
    app.firestore().settings({ firestore config here })
  }
  window.firebase = app

यह बहुत अच्छा काम करता है! अब जब मैं विकास में चल रहा हूं, मेरे पास एक स्थानीय नकली उपयोगकर्ता है जो एमुलेटर सोचता है "परीक्षक" है (जैसे फायरस्टोर सुरक्षा नियम परीक्षण मार्गदर्शिका दिखाता है)।

एक और समाधान जो मैं उपयोग करता हूं वह है आपके प्रमाणीकरण को रोकना (मैं परीक्षण के लिए जेनरेट किए गए नकली उपयोगकर्ताओं का उपयोग कर रहा हूं)।

टाइपस्क्रिप्ट उदाहरण:

import type { User as AuthUser } from '@firebase/auth-types'
// not importing a type, but a module of types
import { auth as authTypes} from 'firebase/app'
type Auth = authTypes.Auth

export const authStub = {
    getUser(uid: string) {
        // for uids like `testuser1234uid`
        let n = uid ? uid.replace("testuser", '').replace("uid", '') : ''
        return Promise.resolve({
            uid,
            email: `test.user${n}@foo.com`,
            emailVerified: true,
            providerData: [{
                providerId: 'google.com',
                email: `test.user${n}@foo.com`,
                uid: `testuser${n}provideruid`,
                phoneNumber: null,
                displayName: `Test User ${n}`.trim(),
                photoURL: 'https://thispersondoesnotexist.com/image',
            }],
            metadata: {
                // https://firebase.google.com/docs/reference/admin/node/admin.auth.UserMetadata
                createTime: new Date().toUTCString(),
                lastSignInTime: new Date().toUTCString()
            },
            customClaims: {
                username: `testuser${n}`
            }
        })
    },
    deleteUser(uid: string) {
        return Promise.resolve()
    },
    async updateUser(uid: string, data: AuthUser) {
        let user = await this.getUser(uid)
        return { ...user, data }
    },
    setCustomUserClaims(uid: string, customUserClaims: Object): Promise<void> {
        return Promise.resolve()
    }
}

export const auth = <Auth><unknown>authStub

अपने नियमों को भी संशोधित करें क्योंकि auth.token का अनुकरण नहीं किया जाता है। उदाहरण के लिए:

const rules = fs.readFileSync(__dirname + '/src/firebase/firestore/firestore.rules', 'utf8')
const modifiedRules =
    rules
        .replace(/request\.auth\.token\.email_verified/g, "true")
        .replace(/request\.auth\.token\.firebase\.sign_in_provider/g, "'password'")

await firebase.loadFirestoreRules({ projectId, rules: modifiedRules })

यह मेरे लिए बहुत अच्छा काम कर रहा है। आशा है कि इससे सहायता मिलेगी…

यदि आप इस थ्रेड का अनुसरण कर रहे हैं और फायरबेस प्रमाणीकरण एमुलेटर के अल्फा टेस्टर बनने के इच्छुक हैं, तो इन चरणों का पालन करें:

1. फायरबेस अल्फा प्रोग्राम के लिए साइन अप करें: https://services.google.com/fb/forms/firebasealphaprogram/
2. मुझे [email protected] पर एक ईमेल भेजें, इसे उस ईमेल पते से भेजना सुनिश्चित करें जिसे आप परीक्षण के लिए उपयोग करेंगे।

कृपया इसे केवल तभी करें जब आप प्रारंभिक चरण के एमुलेटर को आज़माने और प्रतिक्रिया प्रदान करने में गंभीरता से रुचि रखते हैं! बग होंगे और सेटअप के कुछ हिस्से कठिन होंगे, लेकिन हम जानना चाहते हैं कि आप क्या सोचते हैं।

@samtstern यह बहुत अच्छी खबर है! मैं इसे आजमाना पसंद करूंगा, लेकिन मैं सप्ताह के अंत तक अपने वर्तमान प्रोजेक्ट के साथ प्रोडक्शन करने जा रहा हूं, इसलिए मैं इस समय इसके साथ खेलने का जोखिम नहीं उठा सकता। मैं जितनी जल्दी हो सके अल्फा के लिए साइन अप करूंगा :) महान कार्य के लिए धन्यवाद।

100% इसे आजमाना चाहेंगे! आपका आदमी सैम!

@samtstern इसे आजमाने के लिए उत्सुक है और मैं जो कुछ भी कर सकता हूं उसकी मदद कर सकता हूं!

मुझे एंड्रॉइड से स्थानीय रूप से कार्यों का परीक्षण करने के लिए प्रमाणीकरण की सुविधा की आवश्यकता है, प्रामाणिक का संदर्भ हमेशा शून्य है

अच्छी खबर है, प्रमाणीकरण एमुलेटर ताजा 8.14.0 रिलीज का हिस्सा है! मैं

कड़ी मेहनत के लिए धन्यवाद दोस्तों और @samtstern

बढ़िया लोग!

मैं सिर्फ दूत हूँ! प्रामाणिक एमुलेटर 99% था ... और इसलिए मैं उसे जागने पर इस मुद्दे को बंद करने का सम्मान देने जा रहा हूं।

क्या इस नए एमुलेटर पर कोई दस्तावेज है? (कैसे स्थापित करें, क्लाइंट को कॉन्फ़िगर करें, आदि)

PSइस पर कड़ी मेहनत के लिए बहुत-बहुत धन्यवाद। यह हमारे लिए हर तरह की अच्छी चीजें सक्षम करने वाला है।

@nicoburns बहुत जल्द! आधिकारिक घोषणा, दस्तावेज़, और वह सभी अच्छी चीज़ें बहुत जल्द आ रही हैं।

बढ़िया खबर! :) इसे आजमाने के लिए इंतजार नहीं कर सकता :)

मुझे पता है कि आप इसके लिए प्रतीक्षा कर रहे हैं, तो चलिए बस इस बिंदु पर आते हैं:

• फायरबेस प्रमाणीकरण एमुलेटर अब उपलब्ध है। आप इसे फायरबेस सीएलआई>= v8.14.0 इंस्टॉल करके प्राप्त कर सकते हैं।
• आरंभ करने के अपने ऐप्स कनेक्ट करें ।
• इस तरह की रोमांचक घोषणाओं और बहुत कुछ के लिए, अभी फायरबेस समिट लाइवस्ट्रीम में ट्यून करें।**

**बेशर्म प्लग: मैं आज बाद में "फ़ायरबेस एमुलेटर सूट का उपयोग करके सीआई कैसे सेट करें" पर एक सत्र भी कर रहा हूं। यह पता लगाना कि सत्र अनुसूची पर पाठक के लिए एक अभ्यास के रूप में छोड़ दिया गया है।

_पी.एस. मैं वास्तव में 99% क्रेडिट नहीं ले सकता क्योंकि प्रामाणिक एमुलेटर निश्चित रूप से टीम वर्क है। फायरबेस और फायरबेस डेवलपर्स (आप) के विभिन्न लोगों ने इसमें भी बड़ी भूमिका निभाई। शुक्रिया!_

@yuchenshi क्या

@vdjurdjevic अभी नहीं, हम उस पर काम कर रहे हैं।

यह वास्तव में एक लोकप्रिय मुद्दा है और हर अपडेट 50-100 लोगों को सूचित करता है। चूंकि हमने अब प्रामाणिक एमुलेटर जारी कर दिया है, इसलिए मैं इस मुद्दे को भविष्य के अपडेट से लॉक करने जा रहा हूं। यदि आपके पास कोई प्रश्न, बग या फीचर अनुरोध है तो कृपया एक नया मुद्दा शुरू करें!