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

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

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

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

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

  • إنشاء وتحديث وإدارة حسابات المستخدمين التي تتم محاكاتها لاختبار البريد الإلكتروني/كلمة المرور، رقم الهاتف/الرسائل القصيرة SMS، والرسائل القصيرة SMS متعدد العوامل، والهوية التابعة لجهات خارجية (مثل 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+KTX
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 بمحاكي مشترك يتم تشغيله في بيئة أخرى، سيلزمك تحديد نفس رقم تعريف المشروع الذي حددته باستخدام واجهة سطر الأوامر في Firebase. يمكنك تمرير رقم تعريف المشروع إلى 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. إنشاء مستخدمين باستخدام نقطة نهاية REST للاشتراك في Authentication
  2. يجب تسجيل دخول المستخدمين باستخدام عناوين البريد الإلكتروني وكلمات المرور لإجراء الاختبارات.
  3. إذا كان ذلك منطبقًا على اختباراتك، اجلب ميزة التحقق من عنوان البريد الإلكتروني خارج النطاق. من نقطة نهاية REST الخاصة بالمحاكي.
  4. مسح سجلّات المستخدمين باستخدام نقطة نهاية REST الخاصة بالمحاكي لمحو البيانات

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

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

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

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

استخدام Emulator Suite UI:

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

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

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

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

التسلسل النموذجي هو على النحو التالي.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. إعادة أسلاك جزء من الرمز الذي يسترجع رموز idTokens أو التعليق عليه موفِّر الهوية (idP) فإن هذا لن يحتاج إلى إدخال أسماء مستخدمين وكلمات مرور حقيقية أثناء إجراء اختبارات وإعفاء اختباراتك من حصص واجهات برمجة التطبيقات وحدود المعدّل في موفِّر الهوية (idP).
  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" ومرحلة الإنتاج

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

Cloud IAM

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

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

تسجيل الدخول في الخدمات التابعة لجهات خارجية

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

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

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

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

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

مصادقة الرمز المميّز المخصّص

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

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

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

دوال المنع

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

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