ربط تطبيقك بمحاكي المصادقة

قبل استخدام محاكي Authentication مع تطبيقك، تأكَّد من أنك تفهم سير العمل العام Firebase Local Emulator Suite، ومن أنك تثبّت وتضبط Local Emulator Suite وتراجع أوامر واجهة سطر الأوامر الخاصة بها.

يفترض هذا الموضوع أنّك على دراية مسبقة بتطوير Firebase Authentication حلول للإنتاج. إذا لزم الأمر، راجِع مستندات النظام الأساسي وطريقة المصادقة اللذين تستخدمهما لـ مزيجك من النظام الأساسي وأسلوب المصادقة.

ما الذي يمكنني فعله باستخدام محاكي Authentication؟

يوفر المحاكي Authentication محاكاة محلية عالية الدقة لـ Firebase Authentication الخدمات، مما يوفر الكثير من الوظائف الموجودة في الإنتاج Firebase Authentication. عند إقران المحاكي بحِزم تطوير البرامج (SDK) من Firebase لمنصّات Apple وAndroid والويب، يتيح لك المحاكي ما يلي:

  • إنشاء حسابات مستخدمين محاكاة وتعديلها وإدارتها لاختبار المصادقة باستخدام البريد الإلكتروني/كلمة المرور ورقم الهاتف/الرسالة القصيرة والمصادقة المتعدّدة العوامل عبر الرسائل القصيرة وموفِّر الهوية التابع لجهة خارجية (مثل Google)
  • عرض المستخدمين المحاكاة وتعديلهم
  • إنشاء نماذج أولية لأنظمة مصادقة الرموز المميّزة المخصّصة
  • الاطّلاع على الرسائل المتعلقة بالمصادقة في علامة التبويب "سجلات واجهة مستخدم المحاكي"

اختيار مشروع Firebase

تحاكي Firebase Local Emulator Suite المنتجات لمشروع واحد على Firebase.

لاختيار المشروع الذي تريد استخدامه، شغِّل الأمر firebase use في دليل العمل قبل بدء المحاكيات في واجهة سطر الأوامر. يمكنك أيضًا تمرير العلامة --project إلى كل أمر من أوامر المحاكي.

Local Emulator Suite تتيح محاكاة مشاريع Firebase الحقيقية ومشاريع توضيحية.

نوع المشروع الميزات الاستخدام مع المحاكيات
حقيقي

مشروع Firebase الحقيقي هو مشروع أنشأته وضبطته (على الأرجح عبر وحدة تحكّم Firebase).

تحتوي المشاريع الحقيقية على موارد مباشرة، مثل مثيلات قاعدة البيانات أو مستودعات التخزين أو الدوال أو أي مورد آخر أعددته لمشروع Firebase هذا.

عند العمل مع مشاريع Firebase الحقيقية، يمكنك تشغيل المحاكيات لأي من المنتجات المتوافقة أو جميعها.

بالنسبة إلى أي منتجات لا تحاكيها، ستتفاعل تطبيقاتك ورمزك مع المورد المباشر (مثيل قاعدة البيانات أو مستودع التخزين أو الدالة وما إلى ذلك).

تجريبي

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

تحتوي معرّفات المشاريع للمشاريع التجريبية على البادئة demo-.

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

ننصحك باستخدام المشاريع التجريبية حيثما أمكن ذلك. تتضمّن المزايا ما يلي:

  • إعداد أسهل، لأنّه يمكنك تشغيل المحاكيات بدون إنشاء مشروع على Firebase
  • أمان أقوى، لأنّه إذا استدعى الرمز عن طريق الخطأ موارد غير محاكاة (في بيئة الإنتاج)، لن يكون هناك أي احتمال لتغيير البيانات أو الاستخدام أو الفوترة
  • دعم أفضل بلا إنترنت، لأنّه ليست هناك حاجة إلى الوصول إلى الإنترنت لتنزيل إعداد حزمة تطوير البرامج (SDK)

إعداد تطبيقك للتواصل مع المحاكي

حِزم تطوير البرامج (SDK) لمنصّات Android وiOS والويب

يمكنك إعداد الإعدادات داخل التطبيق أو فئات الاختبار للتفاعل مع Authentication المحاكي على النحو التالي.

Kotlin
Firebase.auth.useEmulator("10.0.2.2", 9099)
Java
FirebaseAuth.getInstance().useEmulator("10.0.2.2", 9099);
Swift
Auth.auth().useEmulator(withHost:"127.0.0.1", port:9099)

Web

import { getAuth, connectAuthEmulator } from "firebase/auth";

const auth = getAuth();
connectAuthEmulator(auth, "http://127.0.0.1:9099");

Web

const auth = firebase.auth();
auth.useEmulator("http://127.0.0.1:9099");

لا يلزم إجراء أي إعداد إضافي لإنشاء نماذج أولية واختبار التفاعلات بين Authentication و Cloud Functions أو Firebase Security Rules لـ Cloud Firestore أو Realtime Database. عند ضبط محاكي Authentication وتشغيل المحاكيات الأخرى ، ستعمل معًا تلقائيًا.

Admin SDK ثوانٍ

تتصل Firebase Admin SDK تلقائيًا بمحاكي Authentication عند ضبط متغيّر البيئة FIREBASE_AUTH_EMULATOR_HOST.

export FIREBASE_AUTH_EMULATOR_HOST="127.0.0.1:9099"

يُرجى العِلم أنّ محاكي Cloud Functions على دراية تلقائيًا بمحاكي Authentication، لذا يمكنك تخطّي هذه الخطوة عند اختبار عمليات الدمج بين Cloud Functions وAuthentication سيتم ضبط متغيّر البيئة تلقائيًا لـ Admin SDK في Cloud Functions.

عند ضبط متغيّر البيئة، ستقبل Firebase Admin SDK رموز تعريف غير موقَّعة وملفات تعريف ارتباط الجلسة الصادرة عن محاكي Authentication (من خلال الطريقتَين verifyIdToken و createSessionCookie على التوالي) لتسهيل التطوير والاختبار محليًا. يُرجى التأكّد من عدم ضبط متغيّر البيئة في بيئة الإنتاج.

إذا كنت تريد أن يتصل رمز Admin SDK الخاص بك بمحاكي مشترك قيد التشغيل في بيئة أخرى، عليك تحديد رقم تعريف المشروع نفسه الذي ضبطته باستخدام Firebase CLI. يمكنك تمرير رقم تعريف المشروع إلى initializeApp مباشرةً أو ضبط متغيّر البيئة GCLOUD_PROJECT.

حزمة تطوير البرامج (SDK) للمشرف من Node.js
admin.initializeApp({ projectId: "your-project-id" });
متغيّر البيئة
export GCLOUD_PROJECT="your-project-id"

رموز التعريف

لأسباب أمنية، يصدر المحاكي Authentication رموز تعريف غير موقَّعة، ولا يقبلها إلا محاكيات Firebase الأخرى أو حزمة تطوير البرامج (SDK) للمشرف من Firebase عند ضبطها. سترفض خدمات Firebase في بيئة الإنتاج أو حزمة تطوير البرامج (SDK) للمشرف من Firebase قيد التشغيل في وضع الإنتاج هذه الرموز (على سبيل المثال، السلوك التلقائي بدون خطوات الإعداد الموضّحة أعلاه).

بدء المحاكي

يمكنك استخدام محاكي Authentication بشكلٍ تفاعلي من خلال Emulator Suite UI وبشكلٍ غير تفاعلي من خلال واجهة REST المحلية. تتناول الأقسام التالية حالات الاستخدام التفاعلية وغير التفاعلية.

لبدء محاكي Authentication وواجهة REST و Emulator Suite UI، نفِّذ ما يلي:

firebase emulators:start

بالنسبة إلى المصادقة المجهولة، يمكن لتطبيقك استخدام منطق تسجيل الدخول لمنصّتك (iOS أو Android أو الويب).

بالنسبة إلى المصادقة باستخدام البريد الإلكتروني/كلمة المرور، يمكنك بدء إنشاء نموذج أولي من خلال إضافة حسابات مستخدمين إلى المحاكي Authentication من تطبيقك باستخدام طرق حزمة تطوير البرامج (SDK) Authentication، أو باستخدام Emulator Suite UI.

  1. في Emulator Suite UI، انقر على علامة التبويب المصادقة.
  2. انقر على الزر إضافة مستخدم.
  3. اتّبِع معالج إنشاء حساب المستخدم، مع ملء حقول المصادقة باستخدام البريد الإلكتروني.

بعد إنشاء مستخدم تجريبي، يمكن لتطبيقك تسجيل دخول المستخدم وخروجه باستخدام منطق حزمة تطوير البرامج (SDK) لمنصّتك (iOS، Android، الويب).

لاختبار عمليات التحقّق من البريد الإلكتروني/تسجيل الدخول باستخدام مسارات روابط البريد الإلكتروني، يطبع المحاكي عنوان URL في الجهاز الذي تم فيه تنفيذ firebase emulators:start.

i  To verify the email address customer@ex.com, follow this link:
http://127.0.0.1:9099/emulator/action?mode=verifyEmail&lang=en&oobCode=XYZ123&apiKey=fake-api-key

الصِق الرابط في متصفّحك لمحاكاة حدث التحقّق، وتحقَّق مما إذا نجحت عملية التحقّق.

{
  "authEmulator": {
    "success": "The email has been successfully verified.",
    "email": "customer@example.com"
  }
}

لاختبار عمليات إعادة ضبط كلمة المرور، يطبع المحاكي عنوان URL مشابهًا في الجهاز، بما في ذلك المَعلمة newPassword (التي يمكنك تغييرها حسب الحاجة).

http://127.0.0.1:9099/emulator/action?mode=resetPassword&oobCode=XYZ!23&apiKey=fake-api-key&newPassword=YOUR_NEW_PASSWORD

الاختبار غير التفاعلي

بدلاً من استخدام Emulator Suite UI أو رمز العميل لإدارة حسابات المستخدمين باستخدام البريد الإلكتروني/كلمة المرور، يمكنك كتابة نصوص برمجية لإعداد الاختبار تستدعي واجهات برمجة تطبيقات REST لإنشاء حسابات المستخدمين وحذفها وجلب رموز التحقّق من البريد الإلكتروني خارج النطاق لتعبئة عنوان URL للتحقّق من البريد الإلكتروني في المحاكي. يؤدي ذلك إلى فصل النظام الأساسي ورمز الاختبار، ما يتيح لك إجراء الاختبار بشكلٍ غير تفاعلي.

بالنسبة إلى مسارات اختبار البريد الإلكتروني وكلمة المرور غير التفاعلية، يكون التسلسل المعتاد على النحو التالي:

  1. إنشاء مستخدمين باستخدام Authentication نقطة نهاية REST لـ `signUp`.
  2. تسجيل دخول المستخدمين باستخدام عناوين البريد الإلكتروني وكلمات المرور لإجراء الاختبارات
  3. إذا كان ذلك ينطبق على اختباراتك، يمكنك جلب رموز التحقّق من البريد الإلكتروني خارج النطاق المتوفّرة من نقطة نهاية REST الخاصة بالمحاكي.
  4. إزالة سجلّات المستخدمين باستخدام نقطة نهاية REST الخاصة بالمحاكي لمحو البيانات

المصادقة المحاكاة باستخدام الهاتف/الرسائل القصيرة

بالنسبة إلى المصادقة باستخدام الهاتف، لا يتيح محاكي "المصادقة" ما يلي:

  • عمليات reCAPTCHA وAPN. بعد ضبط حِزم تطوير البرامج (SDK) للعميل للتفاعل مع المحاكي، يتم إيقاف طرق التحقّق هذه بطريقة مشابهة لتلك الموضّحة لاختبار التكامل (iOS أو Android أو الويب).
  • أرقام الهواتف التجريبية التي تم ضبط رموزها مسبقًا في وحدة تحكّم Firebase

في ما عدا ذلك، يكون مسار المصادقة باستخدام الهاتف/الرسائل القصيرة مطابقًا للمسار الموضّح لبيئة الإنتاج (iOS أو Android أو الويب) من حيث رمز العميل.

باستخدام Emulator Suite UI

  1. في Emulator Suite UI، انقر على علامة التبويب المصادقة.
  2. انقر على الزر إضافة مستخدم.
  3. اتّبِع معالج إنشاء حساب المستخدم، مع ملء حقول المصادقة باستخدام الهاتف.

ومع ذلك، بالنسبة إلى مسارات المصادقة باستخدام الهاتف، لن يشغِّل المحاكي عملية تسليم أي رسائل نصية، لأنّ التواصل مع شركة الاتصالات خارج النطاق وليس مناسبًا للاختبار المحلي. بدلاً من ذلك، يطبع المحاكي الرمز الذي كان سيتم إرساله عبر الرسائل القصيرة إلى الجهاز نفسه الذي شغّلت عليه firebase emulators:start، لذا أدخِل هذا الرمز في التطبيق لمحاكاة المستخدمين الذين يتحقّقون من رسائلهم النصية.

الاختبار غير التفاعلي

لاختبار المصادقة باستخدام الهاتف بشكلٍ غير تفاعلي، استخدِم Authentication emulator REST API لاسترداد رموز الرسائل القصيرة المتوفّرة. يُرجى العِلم أنّ الرمز يختلف في كل مرة تبدأ فيها المسار.

التسلسل المعتاد هو كما يلي:

  1. استدعِ signInWithPhoneNumber على النظام الأساسي لبدء عملية التحقّق.
  2. استردِ رمز التحقّق باستخدام نقطة نهاية REST الخاصة بالمحاكي.
  3. استدعِ confirmationResult.confirm(code) كالمعتاد باستخدام رمز التحقّق.

المصادقة المتعدّدة العوامل عبر الرسائل القصيرة

يتيح محاكي Authentication إنشاء نماذج أولية واختبار مسارات المصادقة المتعدّدة العوامل عبر الرسائل القصيرة المتوفّرة في بيئة الإنتاج لمنصّات iOS وAndroid والويب.

عند إضافة مستخدم وهمي إلى المحاكي، يمكنك تفعيل المصادقة المتعدّدة العوامل وضبط رقم هاتف واحد أو أكثر سيتم إرسال رسائل SMS التي تتضمّن العامل الثاني إليها. يتم عرض الرسائل في الجهاز نفسه الذي شغّلت عليه firebase emulators:start، وتتوفّر من واجهة REST.

المصادقة المحاكاة باستخدام موفِّر الهوية التابع لجهة خارجية

يتيح لك محاكي Authentication اختبار العديد من مسارات المصادقة التابعة لجهات خارجية في تطبيقاتك على iOS أو Android أو الويب بدون إجراء أي تغييرات على رمز الإنتاج. للاطّلاع على أمثلة على مسارات المصادقة، يُرجى الرجوع إلى مستندات مجموعات المزوّدين والأنظمة الأساسية المختلفة التي يمكنك استخدامها في تطبيقك.

بشكلٍ عام، يمكنك استخدام حزمة تطوير البرامج (SDK) من Firebase للمصادقة بإحدى الطريقتَين التاليتَين:

  • يسمح تطبيقك لحزمة تطوير البرامج (SDK) بمعالجة العملية بأكملها من البداية إلى النهاية، بما في ذلك جميع التفاعلات مع موفّري الهوية التابعين لجهات خارجية لاسترداد بيانات الاعتماد.
  • يسترد تطبيقك بيانات الاعتماد يدويًا من موفِّر تابع لجهة خارجية باستخدام حزمة تطوير البرامج (SDK) الخاصة بـ هذا الموفِّر، ثم يمرّر بيانات الاعتماد هذه إلى حزمة تطوير البرامج (SDK) لـAuthentication.

ننصحك مرة أخرى بالرجوع إلى رابط المستندات أعلاه والتأكّد من أنّك على دراية بأي مسار تريد استخدامه، سواء كان مسار استرداد بيانات الاعتماد الذي تديره حزمة تطوير البرامج (SDK) من Firebase أو مسار استرداد بيانات الاعتماد اليدوي. يتيح محاكي Authentication اختبار أي من الطريقتَين.

اختبار مسارات موفِّر الهوية التي تديرها حزمة تطوير البرامج (SDK) من Firebase

إذا كان تطبيقك يستخدم أي مسار من البداية إلى النهاية في Firebase SDK، مثل OAuthProvider لتسجيل الدخول باستخدام Microsoft أو GitHub أو Yahoo، يعرض Authenticationمحاكي "المصادقة" إصدارًا محليًا من صفحة تسجيل الدخول المقابلة للمساعدة في اختبار المصادقة من تطبيقات الويب التي تستدعي الطريقتَين signinWithPopup أوsignInWithRedirect لإجراء اختبار تفاعلي. تظهر صفحة تسجيل الدخول التي يتم عرضها محليًا أيضًا في التطبيقات للأجهزة الجوّالة، ويتم عرضها من خلال مكتبة عرض الويب الخاصة بمنصّتك.

ينشئ المحاكي حسابات مستخدمين وبيانات اعتماد وهمية تابعة لجهات خارجية حسب الحاجة أثناء تقدّم المسارات.

اختبار مسارات موفِّر الهوية باستخدام استرداد بيانات الاعتماد يدويًا

إذا كنت تستخدم طرق تسجيل الدخول "اليدوية" وتستدعي الطريقة signInWithCredentials الخاصة بمنصّتك، سيطلب تطبيقك كالمعتاد تسجيل الدخول الحقيقي من جهة خارجية ويسترد بيانات الاعتماد الحقيقية من جهة خارجية.

يُرجى العِلم أنّ المحاكي لا يتيح المصادقة باستخدام signInWithCredential إلا لبيانات الاعتماد التي يتم استردادها من "تسجيل الدخول باستخدام حساب Google" وApple ومزوّدين آخرين يستخدمون رموز تعريف تم تنفيذها كرموز JSON المميّزة للويب (JWT). لا يتم قبول رموز الوصول (مثل الرموز التي يقدّمها Facebook أو Twitter، والتي ليست رموز JSON المميّزة للويب). يناقش القسم التالي بديلاً في هذه الحالات.

الاختبار غير التفاعلي

إحدى طرق الاختبار غير التفاعلي هي أتمتة نقرات المستخدمين على صفحة تسجيل الدخول التي يعرضها المحاكي. بالنسبة إلى تطبيقات الويب، استخدِم واجهة تحكّم مثل WebDriver. بالنسبة إلى الأجهزة الجوّالة، استخدِم أدوات اختبار واجهة المستخدم من منصّتك، مثل Espresso أو Xcode.

بدلاً من ذلك، يمكنك تعديل الرمز لاستخدام signInWithCredential (على سبيل المثال، في فرع رمز) واستخدام مسار مصادقة الرموز المميّزة مع رموز تعريف وهمية للحسابات بدلاً من بيانات الاعتماد الحقيقية.

  1. أعِد ربط الجزء من الرمز الذي يسترد رموز تعريف من موفِّر الهوية أو علِّق عليه، ما يزيل الحاجة إلى إدخال أسماء مستخدمين وكلمات مرور حقيقية أثناء الاختبارات، ويخفّف عن اختباراتك الحصص ونسب الاستخدام القصوى لواجهة برمجة التطبيقات في موفِّر الهوية.
  2. ثانيًا، استخدِم سلسلة JSON حرفية بدلاً من الرمز المميّز لـ signInWithCredential. باستخدام حزمة تطوير البرامج (SDK) للويب كمثال، يمكنك تغيير الرمز إلى:
firebase.auth().signInWithCredential(firebase.auth.GoogleAuthProvider.credential(
  '{"sub": "abc123", "email": "foo@example.com", "email_verified": true}'
));

عند استخدام هذا الرمز مع المحاكي، سيصادق بنجاح على مستخدم لديه عنوان البريد الإلكتروني foo@example.com على Google. اعتبِر الحقل الفرعي مفتاحًا أساسيًا يمكن تغييره إلى أي سلسلة، ما يحاكي تسجيل دخول مستخدمين مختلفين. يمكنك استبدال firebase.auth.GoogleAuthProvider، على سبيل المثال، بـ new firebase.auth.OAuthProvider('yahoo.com') أو أي معرّف مزوّد آخر تريد محاكاته.

المصادقة المحاكاة باستخدام الرموز المميّزة المخصّصة

يتعامل محاكي Authentication مع المصادقة باستخدام رموز JSON المميّزة للويب المخصّصة من خلال استدعاء الطريقة signInWithCustomToken على الأنظمة الأساسية المتوافقة، كما هو موضّح في مستندات المصادقة Authentication في بيئة الإنتاج.

أوجه الاختلاف بين محاكي Authentication وبيئة الإنتاج

يحاكي محاكي Authentication "مصادقة Firebase" العديد من ميزات المنتج في بيئة الإنتاج. ومع ذلك، بما أنّ أي نوع من أنظمة المصادقة يعتمد بشكلٍ كبير على الأمان على مستويات متعددة (الجهاز ومزوّدو الجهات الخارجية وFirebase وما إلى ذلك)، يصعب على المحاكي إعادة إنشاء جميع المسارات بشكلٍ صحيح.

Cloud IAM

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

بما أنّ تسجيل الدخول عبر رابط البريد الإلكتروني على منصّات الأجهزة الجوّالة يعتمد على "روابط Firebase الديناميكية"، سيتم فتح جميع هذه الروابط على منصّة الويب (للأجهزة الجوّالة) بدلاً من ذلك.

طلبات تسجيل الدخول من خدمات الجهات الخارجية

بالنسبة إلى مسارات تسجيل الدخول من خدمات الجهات الخارجية، تعتمد Firebase Authentication على بيانات اعتماد آمنة من مزوّدين تابعين لجهات خارجية، مثل Twitter وGithub.

يقبل محاكي Authentication بيانات الاعتماد الحقيقية من مزوّدي اتصال OpenID، مثل Google وApple. لا يتم قبول بيانات الاعتماد من المزوّدين الذين لا يستخدمون OpenID Connect.

تسجيل الدخول باستخدام البريد الإلكتروني / الرسائل القصيرة

في التطبيقات في بيئة الإنتاج، تتضمّن مسارات تسجيل الدخول باستخدام البريد الإلكتروني والرسائل القصيرة عملية غير متزامنة يتحقّق فيها المستخدم من رسالة تم تلقّيها ويدخل رمز تسجيل الدخول في واجهة تسجيل الدخول. لا يرسل محاكي Authentication أي رسائل إلكترونية أو رسائل SMS ، ولكن كما هو موضّح أعلاه، ينشئ رموز تسجيل الدخول ويطبعها في الجهاز لاستخدامها في الاختبار.

لا يتيح المحاكي إمكانية تحديد أرقام هواتف تجريبية باستخدام رموز تسجيل دخول ثابتة، كما يمكن إجراء ذلك باستخدام وحدة تحكّم Firebase.

المصادقة باستخدام الرموز المميّزة المخصّصة

لا يتحقّق محاكي Authentication من التوقيع أو تاريخ انتهاء صلاحية الرموز المميّزة المخصّصة. يتيح لك ذلك استخدام الرموز المميّزة التي تم إنشاؤها يدويًا وإعادة استخدام الرموز المميّزة إلى أجل غير مسمّى في سيناريوهات إنشاء النماذج الأولية والاختبار.

الحدّ من المعدّل / مكافحة إساءة الاستخدام

لا يكرّر محاكي Authentication ميزات الحدّ من المعدّل أو مكافحة إساءة الاستخدام في بيئة الإنتاج.

الدوال التي تحظر المستخدمين

في بيئة الإنتاج، تتم كتابة بيانات المستخدمين في مساحة التخزين مرة واحدة بعد تشغيل الحدثَين beforeCreate وbeforeSignIn. ومع ذلك، بسبب القيود الفنية، يكتب محاكي Authenticationفي مساحة التخزين مرّتَين، مرة بعد إنشاء المستخدم و مرة أخرى بعد تسجيل الدخول. يعني ذلك أنّه بالنسبة إلى المستخدمين الجدد، يمكنك استدعاء getAuth().getUser() بنجاح في beforeSignIn في Authentication محاكي، ولكن سيظهر لك خطأ عند إجراء ذلك في بيئة الإنتاج.

الخطوات التالية