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

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

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

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

يوفّر المحاكي Authentication محاكاة محلية عالية الدقة Firebase Authentication للخدمات، ما يتيح الاستفادة من معظم الوظائف المتوفّرة في الإنتاج Firebase Authentication. يتيح لك المحاكي، عند إقرانه بمنصات Apple وAndroid وWeb Firebase SDK، إجراء ما يلي:

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

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

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

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

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

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

مشروع 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");
auth_emulator_connect.js

Web

const auth = firebase.auth();
auth.useEmulator("http://127.0.0.1:9099");
emulator-suite.js

لا يلزم إجراء أي إعداد إضافي لإنشاء نماذج أولية واختبار التفاعلات بين 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 بمحاكي مشترك يعمل في بيئة أخرى، عليك تحديد معرّف المشروع نفسه الذي ضبطته باستخدام واجهة سطر الأوامر (CLI) في Firebase. يمكنك تمرير معرّف مشروع إلى initializeApp مباشرةً أو ضبط متغيّر البيئة GCLOUD_PROJECT.

Node.js Admin SDK
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 من تطبيقك باستخدام طرق Authentication SDK، أو باستخدام 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 API لإنشاء حسابات المستخدمين وحذفها واسترداد رموز إثبات ملكية البريد الإلكتروني خارج النطاق لتعبئة عنوان URL الخاص بإثبات ملكية البريد الإلكتروني في المحاكي. ويؤدي ذلك إلى إبقاء رمز النظام الأساسي ورمز الاختبار منفصلَين ويتيح لك إجراء الاختبار بدون تفاعل.

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

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

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

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

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

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

استخدام Emulator Suite UI:

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

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

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

لاختبار مصادقة الهاتف غير التفاعلية، استخدِم واجهة برمجة تطبيقات REST الخاصة بمحاكي Authentication لاسترداد رموز SMS المتاحة. يُرجى العِلم أنّ الرمز يختلف في كل مرة تبدأ فيها عملية التحقّق.

يكون التسلسل المعتاد على النحو التالي.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. أعِد ربط الجزء من الرمز الذي يستردّ الرموز المميزة لبطاقة التعريف (idToken) من موفِّر الهوية (IDP) أو علِّق عليه، ما يزيل الحاجة إلى إدخال أسماء مستخدمين وكلمات مرور حقيقية أثناء الاختبارات، ويُعفي الاختبارات من حصص واجهة برمجة التطبيقات وحدود المعدّل لدى موفِّر الهوية.
  2. ثانيًا، استخدِم سلسلة JSON حرفية بدلاً من الرمز المميّز لـ signInWithCredential. باستخدام حزمة تطوير البرامج على الويب كمثال، يمكنك تغيير الرمز البرمجي إلى ما يلي:
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 وبيئة الإنتاج

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

Cloud IAM

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

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

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

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

يقبل المحاكي Authentication بيانات الاعتماد الحقيقية من موفّري OpenID Connect، مثل Google وApple. لا تتوافق بيانات الاعتماد من موفّري الخدمات غير المتوافقين مع OpenID Connect.

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

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

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

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

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

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

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

وظائف الحظر

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

ما هي الخطوات التالية؟