Firebase-tools: أضف محاكي مصادقة Firebase إلى مجموعة المحاكي

vladimirdjurdjevic شكرا لرفع هذا! هذا مدرج في قائمة الأشياء التي يجب القيام بها ، لكننا لم نقرر بعد مقدار خدمة المصادقة التي يجب محاكاتها وأفضل استراتيجية للقيام بذلك. من السهل جدًا محاكاة أشياء معينة (مثل المصادقة المجهولة) بينما يصعب جدًا محاكاة أشياء أخرى (مثل مصادقة الرسائل القصيرة).

لكننا نريد بالتأكيد تمكين حالة الاستخدام الشامل التي ذكرتها!

سؤال: هل ستجد أنه من المفيد وجود مكتبة تسمح لك بالسخرية من مستخدم Firebase محليًا لاستخدامه مع برامج المحاكاة؟ شيء مثل:

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

samtstern هل setEmulatedUser() أيضًا إلى تشغيل أي وظائف سحابة functions.auth.user().onCreate() مضاهاتها؟ إذا كان الأمر كذلك ، فسيكون ذلك مفيدًا جدًا.

samtstern من شأنه أن يساعد بعض سيناريوهات الاختبار بالتأكيد ، لكنه لا يزال يتطلب مثالًا حقيقيًا للتطوير. فكرتي هي تجنب إنشاء العديد من مشاريع Firebase لبيئات مختلفة ، وأن أكون قادرًا على التطوير محليًا (ربما في وضع عدم الاتصال). هناك نهج آخر يتمثل في دعم بيئات مختلفة للخدمات. إذا تمكنا من إنشاء بيئات مختلفة لنفترض أن firestore والمصادقة في إطار نفس المشروع ، فسيؤدي ذلك إلى حل العديد من المشكلات. أعلم أنه يمكنني إنشاء مشروع لكل بيئة ، لكن هذا ألم حقيقي في المؤخرة. تكوين كل بيئة ، وتكرار البيانات ، وما إلى ذلك. من الناحية المثالية ، أود أن أكون قادرًا على إنشاء مشروع Firebase واحد ، وإذا كنت بحاجة إلى بيانات وهمية للاختبار اليدوي ، فيمكنني فقط إنشاء بيئة مرحلية لـ firestore ، وتحميل البيانات هناك.

noelmansour سؤال جيد! لن يكون ذلك صعبًا للغاية ، فربما نريد مكالمتين مختلفتين مثل signInAsEmulatedUser و signUpAsEmulatedUser حيث تقوم الثانية فقط بتشغيل الوظيفة.

يوافق vladimirdjurdjevic تمامًا على أن المحاكي كامل

سؤال: هل ستجد أنه من المفيد وجود مكتبة تسمح لك بالسخرية من مستخدم Firebase محليًا لاستخدامه مع برامج المحاكاة؟

حقا مفيد ، سيساعد كثيرا
في الوقت الحالي ، أقوم فقط بإعداد وظيفة القاعدة التي تتحقق من صحة المستخدم المسجل في كل مرة أقوم فيها باختبار شيء ما محليًا على true ، وهو أمر غير آمن إلى حد ما ، ولكن ربما يكون أبسط شيء يمكنني القيام به بدون محاكاة المستخدم الحالي.

نعم ، سيكون هذا مفيدًا للغاية

أود أيضًا اختبار الوحدة functions.auth.user().onCreate() . أفترض الآن أن أفضل حل هو في الأساس تصدير وظيفة رد الاتصال التي تم تمريرها إلى onCreate وتوفير كائن user مزيف له.

لهذا النوع من اختبار الوحدة ، تحقق من Firebase-function-test
Library ، مما يساعدك على استدعاء معالجات الوظائف الخاصة بك باستخدام بيانات وهمية.

الأحد، 13 أكتوبر 2019، 05:44 دانيال K. [email protected] كتب:

أود أيضًا اختبار الوحدة للوظائف. auth.user (). onCreate (). أنا
افترض الآن أن أفضل حل بديل هو رد الاتصال للتصدير
تم تمرير الدالة onCreate وتوفير كائن مستخدم وهمي لها.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/firebase/firebase-tools/issues/1677؟email_source=notifications&email_token=ACATB2QYJLX2LNVDTWJV25TQOMJ4VA5CNFSM4I27PTFKYY3PNVWWK3TUL52HS4DFVREX43
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/ACATB2SO3IR6UB73F4EMZPTQOMJ4VANCNFSM4I27PTFA
.

samtstern هل هذا يعمل بالفعل جنبًا إلى جنب مع محاكي Firestore؟ بناءً على هذا ، حصلت على انطباع أنه لأغراض مختلفة.

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

بالتأكيد لا أريد وضعًا عبر الإنترنت لاختبار الوحدة ، فسيكون ذلك بطيئًا. ولست متأكدًا مما إذا كان بإمكاني الوصول إلى محاكي Firestore عن طريق "stubbing".

FredyC شكرًا للإشارة إلى تلك المستندات. الكلمات المستخدمة محيرة لأن "الأوضاع" ليست مفتاح تحويل يمكنك تمكينه ، إنها تصف فقط الاستراتيجيات التي يمكنك اتخاذها.

إذا كنت ستبدأ تشغيل محاكي Firestore جنبًا إلى جنب مع اختبارات الوحدة الخاصة بك ، فمن المؤكد أن الكود الخاص بك يمكن أن يتصل به. إذا قمت بتعيين متغير البيئة FIRESTORE_EMULATOR_HOST فسيقوم Firebase Admin SDK بالاتصال تلقائيًا بمحاكي Firestore ( firebase emulators:exec يقوم بذلك نيابة عنك).

samtstern ما زلت أواجه مشكلة في ربط النقاط وكيف سيساعدني كل ذلك في اختبار functions.auth.user().onCreate() ؟ أعني أنه من الرائع أن تتصل الوظائف بالمحاكي بدلاً من إصدار الإنتاج ، لكن هذا هو Firestore فقط ، أليس كذلك؟ كيف يمكنني استدعاء إنشاء المستخدم من الاختبارات للحصول على رمز الوظيفة لبدء التشغيل؟

يبدو أن هناك طريقة مشفرة makeUserRecord في اختبار وظائف Firebase المذكور ، ولكن ليس من المنطقي كيف يعمل ذلك أو كيفية استخدامه بالفعل.

حاولت الاتصال بـ auth.createUserWithEmailAndPassword() من الحزمة @firebase/testing ، لكن هذا يشكو من عدم صلاحية مفتاح API ، لذلك أفترض أنه سيعمل مع الإصدار عبر الإنترنت فقط.

عندما أبحث في org عن متغير env الذي ذكرته ، يكون في ثلاثة أماكن فقط ولا يبدو أن أيًا منها له صلة بالمصادقة حقًا. إلا إذا كانت مخفية ببعض سلاسل السلسلة.

لقد كنت أتصفح أيضًا https://github.com/firebase/functions-samples لكنني لم أجد أمثلة على اختبار الوحدة هناك.

هل يمكنك أن تفهم هذا من فضلك؟ :)

لدي أيضًا حالة أخرى ، معاكسة إلى حد ما ، حيث يستخدم كود الوظيفة السحابية admin.auth().getUserByEmail() call. من المستغرب أن الأمر لا ينتهي بالخطأ ، لكن ليس لدي أي فكرة عن كيفية إنشاء هذا المستخدم حتى يمكن إعادته. باستثناء الاستهزاء بالطبع من وحدة الإدارة بأكملها ، لكن هذا جنون :)

samtstern آسف على التأخير. عندما أقول مثالًا حقيقيًا ، أعني مثالًا حقيقيًا: D من الناحية المثالية ، أريد فقط تبديل التكوين في ملف البيئة الزاوية الخاص بي من أجل التطوير ، ومواصلة تنفيذ ميزات المصادقة مثل تطبيقي يتحدث إلى واجهة برمجة تطبيقات حقيقية ، لكنه في الواقع يعمل المحاكي على آلة ، ويمكنني أن أفعل ذلك في وضع عدم الاتصال. الآن ، أفهم التحديات التي تواجه إرسال الرسائل القصيرة على سبيل المثال. سيكون من السخف توقع أن يرسل المحاكي رسائل قصيرة حقيقية إلى هاتفي ، ولكن ربما يمكنك فقط طباعتها لوحدة التحكم (محتوى الرسائل القصيرة التي سيتم إرسالها). ربما يكون الأمر أكثر صعوبة من قيمة هذا. لهذا السبب أعتقد أن مجرد دعم بيئات متعددة لكل مشروع يمكن أن يجعل الأشياء أفضل بكثير. يستغرق الأمر وقتًا طويلاً لتكرار التكوينات بين مشاريع متعددة لبيئات مختلفة. وأيضًا إدارة حسابات خدمة متعددة للنصوص البرمجية لتكون قادرة على زرع البيانات لمشاريع مختلفة من Firestore يعد أمرًا مزعجًا. لهذا السبب علمت أنه إذا كان لدينا منصة Firebase كاملة تمت محاكاتها ، فيمكننا استخدام ذلك في كل بيئة غير إنتاجية ، وإدارة مشروع Firebase حقيقي واحد فقط. ولكن ربما يكون مجرد دعم بيئات متعددة لكل مشروع حلاً أفضل بنتيجة مقبولة.

FredyC شكرا لجميع ملاحظاتك! من المفيد حقًا أن نرى كيف يمكن أن يكون هذا محيرًا. هناك شيئان رئيسيان يريد الأشخاص القيام بهما في اختباراتهم المتعلقة بالمصادقة:

1. سجّل الدخول لاستخدام خدمات مثل Firestore أو Realtime Database دون إنشاء مستخدمين حقيقيين. الآن هذا ما يمكن أن يحله شيء مثل setEmulatedUser . سيسمح لك فقط بالحصول على رمز مصادقة مزيف محليًا تقبله المحاكيات ولكن سيتم رفضه بواسطة prod. مزيد من الأمان ، مزيد من العزلة ، إلخ.
2. في الواقع اختبر المصادقة مباشرة. سيكون لهذا بضع قطع:
   أ. محاكي مصادقة يستجيب لجميع استدعاءات واجهة برمجة التطبيقات الضرورية بحيث يمكنك توجيه مجموعات Auth SDK إليها.
   ب. التكامل بين هذا المحاكي ومحاكي الوظائف بحيث يتم تشغيل وظائف .onCreate بشكل صحيح.
   ج. السخرية التلقائية داخل محاكي الوظائف بحيث يشير admin.auth() إلى محاكي Auth ، تمامًا كما نفعل مع Firestore و RTDB اليوم.

أعتقد أنه من الواضح أن (2) هي القصة الصحيحة ولكني كنت أحاول التعرف على عدد الأشخاص الذين سيكونون سعداء بهم (1) نظرًا لأنه من الأسهل إلى حد كبير التنفيذ والصيانة.

samtstern أرى. صححني إذا كنت مخطئًا ، لكن ألم يتم حل (1) بالفعل؟ أعني أنه في الاختبارات يمكنني فقط الاتصال بما يلي وسوف يتعرف عليّ محاكي Firestore بصفتي هذا المستخدم حتى أتمكن من الاختبار وفقًا لقواعد الأمان. لم أجرب ذلك بالفعل حتى الآن ، لكن يبدو أنني واعد حتى الآن :)

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

من المؤكد أن (2) يبدو مفيدًا للغاية ، لكن معالجته أكثر تعقيدًا بالتأكيد. للأسف ، فإن رؤيتي للمنتج الكامل محدودة للغاية ، ولا يمكنني حقًا تقديم أي أفكار مفيدة هنا.

أعتقد أنه يجب أن يتم بناؤه بشكل تدريجي. بدلاً من محاولة تغطية جميع السيناريوهات دفعة واحدة ، قم ببنائها بناءً على حالات الاستخدام المعروفة والإضافة أثناء التنقل. في رأيي المحدود ، لا يبدو أن محاكاة "قاعدة بيانات المستخدم" مع مشغلات الوظائف أمر صعب.

FredyC أنت محق في أن (1) تم حلها للاستخدام داخل مجموعات الاختبار. لكن حالة الاستخدام الأخرى هي في الواقع توصيل تطبيق Android / iOS / Web الخاص بك مباشرةً بالمحاكي من أجل التنمية المحلية. في هذه الحالة لا يمكنك استخدام @firebase/testing .

أرى. بصراحة ، سيكون من الرائع نوعًا ما إذا كان من الممكن استخدام @firebase/testing عبر الأنظمة الأساسية بدلاً من وجود حلول منفصلة. أعني ما مدى صعوبة إعادة توجيه الاتصال إلى المحاكي؟ أليس هذا هو FIRESTORE_EMULATOR_HOST بالضبط؟ على الرغم من أنني أعتقد أن شيئًا مثل FIREBASE_EMULATOR_HOST سيكون أكثر ملاءمة إذا كان المحاكي سيحصل على خدمات أخرى أيضًا.

أعتقد أن signInWithPhone حتى تتمكن من التحكم في سلوكها؟ ثم لا داعي للقلق بشأن المحاكي والحصول على رمز محاكاة الرسائل القصيرة في وحدة التحكم :)

بالطبع ، فأنت بحاجة إلى طريقة ما للمصادقة تجاه المحاكي الخاص بـ Firestore (والاتصال به). شيء يشبه ما أوضحته في 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 ويمكن للتكوين من جانب العميل إعادة توجيه سطح API الحالي للاستفادة منه.

أفضل كثيرًا أن تعرض حالات AuthN غريبة الأطوار أخطاءً مع واجهة برمجة تطبيقات المسؤول والعميل التي تدعم الحد الأدنى من CRUD للمستخدمين الأساسيين على اسم المستخدم / كلمة المرور. هيك ، أعتقد أنه حتى البدء بدعم رمز مخصص في المسؤول و signInWithCustomToken سيذهب بعيدًا حقًا. ربما تقوم بتطبيق الفاكهة المعلقة المنخفضة مع مصفوفة دعم API المنشورة في المستندات.

بالنسبة إلى نقطة FredyC ، تتمثل الإستراتيجية الحالية لاختبار مصادقة التكامل في الاستيراد المشروط لكود التطبيق @firebase/testing للتوجيه إلى initializeTestApp المخصصة. يؤكد هذا الإجراء على استبعاد الحزمة في وقت الإنشاء لفرق المشروع ، وينشر أيضًا تكوينات إعادة توجيه المحاكي عبر اثنين من واجهات برمجة التطبيقات ( 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. سجّل الدخول لاستخدام خدمات مثل Firestore أو Realtime Database دون إنشاء مستخدمين حقيقيين. الآن هذا ما يمكن أن يحله شيء مثل setEmulatedUser . سيسمح لك فقط بالحصول على رمز مصادقة مزيف محليًا تقبله المحاكيات ولكن سيتم رفضه بواسطة prod. مزيد من الأمان ، مزيد من العزلة ، إلخ.
2. في الواقع اختبر المصادقة مباشرة. سيكون لهذا بضع قطع:
   أ. محاكي مصادقة يستجيب لجميع استدعاءات واجهة برمجة التطبيقات الضرورية بحيث يمكنك توجيه مجموعات Auth SDK إليها.
   ب. التكامل بين هذا المحاكي ومحاكي الوظائف بحيث يتم تشغيل وظائف .onCreate بشكل صحيح.
   ج. السخرية التلقائية داخل محاكي الوظائف بحيث يشير admin.auth() إلى محاكي Auth ، تمامًا كما نفعل مع Firestore و RTDB اليوم.

أعتقد أنه من الواضح أن (2) هي القصة الصحيحة ولكني كنت أحاول التعرف على عدد الأشخاص الذين سيكونون سعداء بهم (1) نظرًا لأنه من الأسهل إلى حد كبير التنفيذ والصيانة.

samtstern بادئ ذي بدء ، أود الحصول على هذا النوع من المحاكاة.

لا ارى. 1 مفيد جدًا في كتابة اختبارات e2e. يتعين علي حاليًا استخدام مثيل حقيقي للمصادقة بينما يمكنني استخدام المحاكي للاستضافة والقواعد ومتجر الحماية والوظائف.

أعتقد أنه ينبغي أن يكون من الممكن استخدام setEmulatedUser للسخرية من المستخدم بنفس الطريقة التي يتم بها ذلك في firebase.initializeTestApp. يجب أن يكون من الممكن إرسال الرموز المخصصة والبيانات الأخرى ذات الصلة بالمستخدم على سبيل المثال.

يجب أن يكون من الممكن أيضًا الحصول على بيانات اعتماد نموذجية يمكن استخدامها في تطبيق العميل باستخدام firebase.auth().signInWithCredential(credential)

شكرًا لك vladimirdjurdjevic على طرح هذه المشكلة! كنا نبحث عن حل لما يقرب من عام بالفعل.

نود أن نرى محاكيًا حقيقيًا لثلاثة أشياء:

1. اختبارات e2e للتطبيق بأكمله ، لذلك لا يتعين علينا إنشاء بيئات مختلفة كما قال vladimirdjurdjevic .
2. اختبارات التكامل للواجهة الخلفية ، حيث يتم استدعاء واجهات برمجة التطبيقات ويجب التحقق من صحة المستخدم في Firebase.
3. يستخدم جميع مطورينا بيئة Firebase مركزية أثناء التطوير ، مما يتسبب في الكثير من الاصطدامات. بالطبع ، يمكن لكل مطور إنشاء مشروع Firebase الخاص به ، لكنهم ما زالوا بحاجة إلى إدارة مستخدمي الاختبار في لوحة معلومات Firebase وهي ليست مثالية. أيضًا ، نود تطوير تطبيقنا في وضع عدم الاتصال وهذا غير ممكن اليوم بسبب عدم وجود محاكي حقيقي.

آمل أن تطلق لنا شيئًا قريبًا ، سيجعل منتجك أكثر قيمة! إنتاجية المطور مهمة جدًا في مثل هذه الخدمات!

يبدو أن هذه ميزة في قائمة رغبات العديد من الأشخاص. يبدو أن مصادقة Firebase هي # 1 IDaaS في الوقت الحالي من حيث التسعير ، لذا فهي حقًا مشكلة لا يمكنك تطويرها محليًا باستخدام وظائف السحابة. نأمل أن يكون لدى فريق FB تحديثات لنا قريبًا! 🙏

تحرير: Pingingmbleigh من @

لدي أيضًا هذا الخطأ ... تم تجاهل الوظيفة لأن محاكي المصادقة غير موجود أو لا يعمل.

يتم تشغيل هذا بواسطة هذا الرمز:

وظائف.auth.user (). onDelete ()

أي معلومات عن هذا ...

تضمين التغريدة

اتفق مع نقاطك. نصيحة واحدة قد تساعدك في هذه الأثناء:

بالطبع ، يمكن لكل مطور إنشاء مشروع Firebase الخاص به ، لكنهم ما زالوا بحاجة إلى إدارة مستخدمي الاختبار في لوحة معلومات Firebase وهي ليست مثالية.

يمكنك زرع وإدارة المستخدمين برمجيًا باستخدام Firebase admin SDK ، على سبيل المثال auth().createUser ، راجع أيضًا https://firebase.google.com/docs/auth/admin/manage-users

بعد قراءة هذا الموضوع ، أعتقد أن الناس هنا قد يجدون أداة Foundry مفيدة.

أنا أحد مؤسسي Foundry. Foundry هي أداة CLI تأخذ وظائف Firebase Cloud الخاصة بك وتنشئ نسخة من تطبيق Firebase الإنتاجي على خوادمنا التي تعمل كبيئة التطوير الخاصة بك والتي تقوم فيها مباشرة بتشغيل التعليمات البرمجية الخاصة بك. لا يلزم التكوين.

يراقب Foundry ملفات شفرة المصدر الخاصة بك وفي كل مرة تحفظ فيها التعليمات البرمجية محليًا ، نقوم بتشغيلها على خوادمنا ونعيد لك النتائج في غضون ثوانٍ قليلة. كل شيء بسرعة فائقة.
أنت تحدد ما هي بيانات Firestore و RealtimeDB و Auth Users التي يجب نسخها من تطبيق الإنتاج الخاص بك من خلال ملف YAML الخاص بنا حتى تكون متاحة أثناء التطوير.

 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}

أنت تحدد أيضًا كيف يجب أن نشغل وظائف السحابة الخاصة بك عندما نقوم بتشغيل التعليمات البرمجية الخاصة بك. إنه يعمل نوعًا ما مثل REPL لوظائف السحابة الخاصة بك. بهذه الطريقة تكون دائمًا على يقين من أن وظائف السحابة الخاصة بك ستعمل بشكل صحيح مع بيانات الإنتاج وفي بيئة الإنتاج بمجرد نشرها.
أيضًا ، تعمل وظائف السحابة الخاصة بك كما لو تم نشرها.

يتم إنشاء بيئات التطوير هذه بشكل مخصص بمجرد بدء جلستك. لذلك يعمل كل فرد في فريقك في بيئته الخاصة حيث يمكنهم العبث.

لا أرغب في إرسال رسائل غير مرغوب فيها إلى المناقشة هنا ، لذا لا تتردد في مراسلتي عبر البريد الإلكتروني بأي أسئلة [email protected]
يسعدني جدًا مساعدتك في إعداد Foundry في مشاريعك ، فقط أرسل لي بريدًا إلكترونيًا!

ومع ذلك ، من الطريقة التي وصفتها بها وما قرأته على الصفحة الرئيسية ، فإن هذه الخدمة قائمة على السحابة.
بدلاً من ذلك ، يعمل محاكي Firebase حتى في وضع عدم الاتصال ، ومن ثم فائدته للاختبار التلقائي.

samtstern أي تقدم أو حل آخر لهذه المشكلة / الميزة؟ أحتاج (1) setEmulatedUser للعمل مع محاكي Cloud Firestore حتى أتمكن من إجراء اختبار يدوي محليًا. هناك خيار آخر يتمثل في وجود وسيطة سطر أوامر تحدد معرف المستخدم عند بدء تشغيل المحاكي. بهذه الطريقة سيتم تشغيل المحاكي تحت معرف المستخدم الذي تم تمريره أثناء بدء التشغيل. بهذه الطريقة يمكن اختبار القواعد محليًا.

حسب تعليقك: في 17 أكتوبر 2019
_أعتقد بوضوح أن (2) هي القصة الصحيحة ولكني كنت أحاول التعرف على عدد الأشخاص الذين سيكونون سعداء بهم (1) نظرًا لأنه من الأسهل بشكل كبير التنفيذ والصيانة.

(1) قم بتسجيل الدخول لاستخدام خدمات مثل Firestore أو Realtime Database دون إنشاء مستخدمين حقيقيين بالفعل. الآن هذا ما يمكن أن يحله شيء مثل setEmulatedUser. سيسمح لك فقط بالحصول على رمز مصادقة مزيف محليًا تقبله المحاكيات ولكن سيتم رفضه بواسطة prod. مزيد من الأمان ، مزيد من العزلة ، إلخ.

نحن نعمل بجد على محاكي المصادقة الكاملة والذي نأمل أن يكون كذلك
الجميع يريد. لا يوجد جدول زمني يمكنني تقديمه الآن ولكنه يمثل أولوية عالية
لنا.

في الجمعة 22 مايو 2020 الساعة 8:12 صباحًا كتب ChuckB [email protected] :

samtstern https://github.com/samtstern أي تقدم أو آخر
حل لهذه المشكلة / الميزة؟ أحتاج (1) setEmulatedUser للعمل مع
محاكي Cloud Firestore حتى أتمكن من إجراء اختبار يدوي محليًا.

حسب تعليقك: في 17 أكتوبر 2019
_أعتقد بوضوح أن (2) هي القصة الصحيحة ولكني كنت أحاول التعرف عليها
كم عدد الأشخاص الذين سيكونون سعداء بـ (1) لأنه من الأسهل إلى حد كبير
تنفيذ وصيانة.

(1) قم بتسجيل الدخول لاستخدام خدمات مثل Firestore أو Realtime Database بدون
إنشاء مستخدمين حقيقيين. الآن هذا ما يشبه شيء
setEmulatedUser سوف يحل. سيسمح لك فقط بالحصول على مصادقة مزيفة
رمز محلي تقبله المحاكيات ولكن سيتم رفضه بواسطة
همز. مزيد من الأمان ، مزيد من العزلة ، إلخ.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/firebase/firebase-tools/issues/1677#issuecomment-632660684 ،
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/ACATB2Q4LV7NXMQFEALNPXLRSZT25ANCNFSM4I27PTFA
.

1. سجّل الدخول لاستخدام خدمات مثل Firestore أو Realtime Database دون إنشاء مستخدمين حقيقيين. الآن هذا ما يمكن أن يحله شيء مثل setEmulatedUser. سيسمح لك فقط بالحصول على رمز مصادقة مزيف محليًا تقبله المحاكيات ولكن سيتم رفضه بواسطة prod. مزيد من الأمان ، مزيد من العزلة ، إلخ.

سأكون سعيدًا برقم 1 هنا ، في هذه الأثناء

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

هل ما زالت مستحيلة؟

@ rishisingh-dev ليس من الممكن تشغيل محاكي مصادقة لأن محاكيات Firebase لا تقوم حاليًا بشحن واحد.

لكن من الممكن تمامًا اختبار وظائف السحابة التي تتضمن المصادقة فيها. يمكنك إعادة تشكيل الوظيفة التي تحتاج إلى بعض واجهة برمجة تطبيقات المصادقة والسخرية منها في الاختبارات ، مع توفير الوظيفة الحقيقية في ملف وظائف Firebase. دقة إعداد الاختبار الخاص بك أقل ، ولكن بعد ذلك تصبح مسألة درجة ، وليس مسألة نوع: أنت فقط تختبر استدعاءات المصادقة مباشرة ولكن يمكنك اختبار ما تتوقعه.

في هذا السؤال 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 ، حيث يُدخل المستخدم بريدًا إلكترونيًا للأصدقاء وتريد uid. يمكنك الحصول على ذلك عن طريق المصادقة 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
}

لا أشعر أن هذا يختلف اختلافًا كبيرًا عن اختبار أي واجهة برمجة تطبيقات تابعة لجهة خارجية في اختبار الوحدة. إن وجود محاكيات Firebase توفر المصادقة يزيل النموذج المعياري لسيناريوهات الاختبار الشامل ، ولكنه لا يغير بشكل كبير اختبارات الوحدة نظرًا لأنك لا تريد الاحتفاظ بالحالة المستمرة بين الاختبارات على أي حال.

أود أن أكون قادرًا على تشغيل هذا محليًا دون الحاجة إلى التحميل على السحابة للتحقق

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 })
}

بالمناسبة ، هل يمكنني الحصول على user.displayName داخل وظيفة onCreate؟

نعم إذا تم ضبطه على ما أعتقد ، هل جربته؟

نعم ، إنها ترجع فارغة.
لقد جربته على السحابة (وليس محليًا).

الكود الخاص بي هنا.

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)
    }
}

يوم الجمعة ، 10 يوليو 2020 الساعة 10:44 ، rishisingh-dev [email protected]
كتب:

نعم ، إنها ترجع فارغة.
لقد جربته على السحابة (وليس محليًا).

[الصورة: لقطة شاشة 2020-07-10 الساعة 2 43 12 صباحًا]
https://user-images.githubusercontent.com/56976320/87140958-29f3ac80-c257-11ea-98d3-084fad619de7.png

الكود الخاص بي هنا.

console.log (user.uid) ؛
console.log (user.email) ؛
console.log (user.displayName) ،
}) ؛ ``

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/firebase/firebase-tools/issues/1677#issuecomment-656587759 ،
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AABU35Q27EMMHYAYU5CNZR3R23PIDANCNFSM4I27PTFA
.

>

أطيب التحيات

نيكوس كاتسيكانيس

نعم ، كان هدفي الأساسي هو تحديث قاعدة البيانات بمعلومات المستخدم داخل الوظيفة onCreate .
ولكن نظرًا لأنني لا أستطيع الحصول على displayName ، فقد صنعت وظيفة onCallable ، وقمت بذلك.

شكرا.

samtstern يسعدني جدًا أن أراك تعمل على هذا :) بدأت للتو مشروعًا جديدًا باستخدام Firebase ، وتجربة dev أفضل بكثير بالفعل (مع خيار واجهة المستخدم المحاكي و-inspect-function). نتطلع إلى رؤية محاكي المصادقة قيد التنفيذ :) عمل رائع!

أفضل شيء آخر هو أنني لست مضطرًا إلى فتح chrome بدون أمان

تضمين التغريدة

بعد شهرين ، هل من الممكن الآن إعطاء تقدير تقريبي؟

نود أن نشحن بداية العام المقبل. نواجه الآن القرار إذا بدأنا في كتابة اختبارات تكامل مقابل مشروع حقيقي أو إذا انتظرنا بضعة أشهر لمحاكي المصادقة. هل يمكنك مساعدتنا قليلا هنا؟

أفضل،

نيكلاس

سياستنا في Firebase هي عدم إعطاء تقديرات حول موعد إطلاق شيء ما إلا إذا كنا متأكدين بنسبة 100٪. في الوقت الحالي ، نعمل بجد على محاكي Auth ، لكننا لسنا قريبين بما يكفي من الانتهاء لاختيار تاريخ الإطلاق.

إنها إحدى أهم أولوياتنا ، لكنني أعتقد أنه لا ينبغي عليك الانتظار حتى نبدأ في اختبار تطبيقك. اكتب اختباراتك ضد prod اليوم ، وقم بتبديلها لاستهداف المحاكي عندما يكون متاحًا.

حسنًا ، شكرًاsamtstern. هذا يساعد!

هناك شيء نود حقًا استخدام محاكي المصادقة له وهو اختبار وظائف السحابة وطلبات Firestore التي تتضمن مطالبات مخصصة على رموز المستخدم المميزة. يمكننا نوعًا من اختبار المطالبات المخصصة باستخدام Firestore في ملعب القواعد في Firebase Console ، ولكن محاكي المصادقة الكامل سيمكننا نظريًا من القيام بالكثير في طريقة الاختبار عندما يتعلق الأمر برموز المستخدم.

لنكون واضحين: نحن ملتزمون بمحاكي مصادقة كامل يحاكي نقاط نهاية الخدمة الفعلية (حيثما أمكن ذلك). لم نعد نفكر في شيء خفيف الوزن مثل تعليقاتي السابقة التي اقترحتها.

من الرائع سماع samtstern (جنبًا إلى جنب مع المطالبات المخصصة ، حيث يتم استخدامها غالبًا مع عمليات تكامل الجهات الخارجية). هل هناك أي مكان يمكننا مواكبة التقدم فيه / ETA؟

fandy لا آسف ليس لدينا أي شيء لمشاركته حتى الآن ...

شكرًا Sam ، حاليًا أقوم بإجراء جميع الاختبارات يدويًا لأنها ليست كذلك
يستحق الجهد المبذول في كتابة اختبارات e2e بدون نماذج Auth

يوم الأربعاء ، 26 أغسطس 2020 الساعة 14:32 ، كتب Sam Stern [email protected] :

>
>

fandy https://github.com/fandy لا آسف ليس لدينا أي شيء
شارك حتى الآن ...

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/firebase/firebase-tools/issues/1677#issuecomment-680850282 ،
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AABU35UAQDBYEXKKINJSM43SCT6E7ANCNFSM4I27PTFA
.

-

أطيب التحيات

نيكوس كاتسيكانيس

للتغلب على هذا ، جربت استيراد @ firebase / test في المتصفح. هذا لم ينجح حقًا. هذا ، مع ذلك ، يفعل: mangle @ firebase / test source لنسخ الجزء التالي الذي تم تعديله قليلاً:

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

هذا يعمل بشكل رائع! الآن عندما أعمل في مجال التطوير ، لدي مستخدم مزيف محلي يعتقد المحاكي أنه "مختبِر" (مثل دليل اختبار قواعد أمان firestore الذي يظهر).

هناك حل آخر أستخدمه وهو إيقاف المصادقة الخاصة بك (أنا أستخدم مستخدمين مزيفين تم إنشاؤهم لإجراء الاختبارات).

مثال على TypeScript:

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 })

إنه يعمل بشكل رائع بالنسبة لي. آمل أن يساعد ...

إذا كنت تتابع سلسلة الرسائل هذه وترغب في أن تكون أحد مختبري Alpha في Firebase Authentication Emulator ، فاتبع الخطوات التالية:

1. اشترك في برنامج Firebase Alpha: https://services.google.com/fb/forms/firebasealphaprogram/
2. أرسل لي بريدًا إلكترونيًا على [email protected] ، وتأكد من إرساله من عنوان البريد الإلكتروني الذي ستستخدمه للاختبار.

الرجاء القيام بذلك فقط إذا كنت مهتمًا بجدية بتجربة أحد برامج المحاكاة في مرحلة مبكرة وتقديم التعليقات! ستكون هناك أخطاء وستكون بعض أجزاء الإعداد صعبة ، لكننا نريد أن نعرف ما هو رأيك.

samtstern هذه أخبار رائعة! أرغب في تجربته ، لكنني سأبدأ الإنتاج بمشروعي الحالي بنهاية الأسبوع ، لذا لا يمكنني تحمل تكاليف اللعب به في الوقت الحالي. سأشترك في ألفا في أقرب وقت ممكن :) شكرا على العمل الرائع.

100٪ سيرغبون في تجربة هذا! أنت الرجل سام!

samtstern نتطلع إلى

أحتاج إلى استخدام ميزة المصادقة لاختبار الوظائف محليًا من Android ، سياق المصادقة فارغ دائمًا

أخبار سارة ، برنامج Authentication Emulator هو جزء من الإصدار الجديد

شكرا لك على الرجال العمل الجاد وsamtstern 💪

الرجال رهيبة!

أنا مجرد رسول! تم إنشاء محاكي Auth بنسبة 99٪ بواسطة yuchenshi ... ولهذا السبب سأسمح له بشرف إغلاق هذه المشكلة عندما يستيقظ.

هل هناك أي توثيق لهذا المحاكي الجديد؟ (كيفية التثبيت ، تكوين العملاء ، إلخ)

ملاحظة: شكرًا جزيلاً على كل العمل الشاق في هذا الشأن. سيؤدي هذا إلى تمكين جميع أنواع الأشياء الرائعة بالنسبة لنا.

nicoburns قريبا جدا! الإعلان الرسمي والمستندات وكل هذه الأشياء الجيدة ستأتي قريبًا جدًا.

أخبار رائعة! :) لا أستطيع الانتظار لتجربته :)

أعلم أنك كنت تنتظر هذا ، لذا دعنا ننتقل إلى النقطة:

• محاكي مصادقة Firebase متاح الآن. يمكنك الحصول عليه عن طريق تثبيت Firebase CLI> = v8.14.0.
• اتبع دليل Emulator Suite للبدء ، وقم بتوصيل تطبيقاتك .
• للحصول على إعلانات مثيرة مثل هذه وغير ذلك الكثير ، يمكنك المتابعة إلى البث المباشر

** Shameless plug: أقوم أيضًا بإجراء جلسة حول "كيفية إعداد CI باستخدام مجموعة Firebase Emulator" في وقت لاحق اليوم. يتم ترك تحديد ذلك في جدول الجلسة كتدريب للقارئ.

_ملاحظة. لا يمكنني حقًا الحصول على 99٪ من الرصيد نظرًا لأن Auth Emulator هو عمل جماعي بالطبع. لعب العديد من الأشخاص في مطوري Firebase و Firebase (أنت) دورًا كبيرًا في هذا أيضًا. شكرا لك!_

yuchenshi هل من الممكن تصدير المستخدمين الذين تم

vdjurdjevic ليس بعد ، نحن نعمل على ذلك.

هذه مشكلة شائعة حقًا وكل تحديث يخطر 50-100 شخص. نظرًا لأننا أصدرنا الآن محاكي Auth ، فسوف أقفل هذه المشكلة من التحديثات المستقبلية. إذا كان لديك سؤال أو خطأ أو طلب ميزة ، فيرجى بدء إصدار جديد!