متصل کردن برنامه به «شبیه‌ساز اصالت‌سنجی»

قبل‌از استفاده از شبیه‌ساز Authentication با برنامه‌تان، مطمئن شوید که گردش کار کلی Firebase Local Emulator Suite را درک می‌کنید، و نصب و پیکربندی Local Emulator Suite را انجام داده‌اید و فرمان‌های CLI آن را مرور کرده‌اید.

این موضوع فرض می‌کند که شما ازقبل با توسعه راه‌حل‌های Firebase Authentication برای تولید آشنا هستید. درصورت نیاز، اسناد مربوط به ترکیب پلاتفرم و روش اصالت‌سنجی خود را مرور کنید.

با شبیه‌ساز Authentication چه کارهایی می‌توانم انجام دهم؟

شبیه‌ساز Authentication شبیه‌سازی محلی با وفاداری بالا از سرویس‌های Firebase Authentication ارائه می‌دهد و بسیاری از عملکردهای موجود در تولید Firebase Authentication را فراهم می‌کند. این شبیه‌ساز که با پلاتفرم‌های Apple، کیت‌های توسعه نرم‌افزار Firebase وب و Android جفت شده است، به شما امکان می‌دهد:

  • ایجاد، به‌روزرسانی، و مدیریت حساب‌های کاربری شبیه‌سازی‌شده برای آزمایش ایمیل/گذرواژه، شماره تلفن/پیامک، چندعاملی پیامک، و اصالت‌سنجی ارائه‌دهنده هویت طرف سوم (مثلاً Google)
  • مشاهده و ویرایش کاربران شبیه‌سازی‌شده
  • نمونه اولیه سیستم‌های اصالت‌سنجی با کد سفارشی
  • پیام‌های مربوط به اصالت‌سنجی را در برگه «گزارش‌های میانای کاربری شبیه‌ساز» بررسی کنید.

پروژه Firebase را انتخاب کنید

Firebase Local Emulator Suite محصولات را برای یک پروژه Firebase شبیه‌سازی می‌کند.

برای انتخاب پروژه موردنظر، قبل‌از شروع شبیه‌سازها، در CLI firebase use را در دایرکتوری کاری‌تان اجرا کنید. یا می‌توانید پرچم --project را به هر فرمان شبیه‌ساز ارسال کنید.

Local Emulator Suite از شبیه‌سازی پروژه‌های واقعی Firebase و پروژه‌های نمونه پشتیبانی می‌کند.

نوع پروژه ویژگی‌ها استفاده با شبیه‌سازها
رئال

پروژه Firebase واقعی پروژه‌ای است که شما ایجاد و پیکربندی کرده‌اید (احتمالاً ازطریق کنسول Firebase).

پروژه‌های واقعی منابع زنده دارند، مانند نمونه‌های پایگاه داده، سطل‌های ذخیره‌سازی، توابع، یا هر منبع دیگری که برای آن پروژه Firebase راه‌اندازی می‌کنید.

هنگام کار با پروژه‌های واقعی Firebase، می‌توانید شبیه‌سازها را برای هرکدام یا همه محصولات پشتیبانی‌شده اجرا کنید.

برای هر محصولی که شبیه‌سازی نمی‌کنید، برنامه‌ها و کد شما با منبع فعال (نمونه پایگاه داده، سطل ذخیره‌سازی، تابع، و غیره) تعامل خواهند داشت.

پخش نمایشی

پروژه نمایشی Firebase پیکربندی واقعی Firebase و منابع زنده ندارد. این پروژه‌ها معمولاً ازطریق codelabs یا سایر آموزش‌ها قابل‌دسترسی هستند.

شناسه‌های پروژه برای پروژه‌های نمایشی پیشوند demo- دارند.

هنگام کار با پروژه‌های نمایشی Firebase، برنامه‌ها و کد شما فقط با شبیه‌سازها تعامل دارند. اگر برنامه‌تان تلاش کند با منبعی تعامل برقرار کند که شبیه‌ساز برای آن اجرا نمی‌شود، آن کد ناموفق خواهد بود.

توصیه می‌کنیم هرجا ممکن است از پروژه‌های نمایشی استفاده کنید. مزایا عبارت‌اند‌از:

  • راه‌اندازی آسان‌تر، زیرا می‌توانید شبیه‌سازها را بدون ایجاد پروژه Firebase اجرا کنید
  • ایمنی قوی‌تر، زیرا اگر کد شما به‌طور تصادفی منابع شبیه‌سازی‌نشده (تولید) را فراخوانی کند، هیچ احتمالی برای تغییر داده، استفاده، و صدور صورت‌حساب وجود ندارد
  • پشتیبانی آفلاین بهتر، زیرا برای بارگیری پیکربندی کیت توسعه نرم‌افزار نیازی به دسترسی به اینترنت نیست.

برنامه‌تان را برای صحبت با شبیه‌ساز آماده کنید

کیت‌های توسعه نرم‌افزار 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)
Unity
FirebaseAuth auth = FirebaseAuth.DefaultInstance;
// Connects to the Auth Emulator running on port 9099
auth.UseEmulator("127.0.0.1", 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_AUTH_EMULATOR_HOST تنظیم شود، Firebase Admin SDK به‌طور خودکار به شبیه‌ساز Authentication متصل می‌شود.

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 را تنظیم کنید.

Node.js Admin SDK
admin.initializeApp({ projectId: "your-project-id" });
متغیر محیط
export GCLOUD_PROJECT="your-project-id"

کدهای شناسه

به دلایل امنیتی، شبیه‌ساز Authentication توکن‌های شناسه امضانشده صادر می‌کند که فقط توسط شبیه‌سازهای دیگر Firebase یا Firebase Admin SDK درصورت پیکربندی پذیرفته می‌شوند. این توکن‌ها توسط سرویس‌های Firebase تولیدی یا Firebase Admin SDK که در حالت تولید اجرا می‌شوند (مثلاً رفتار پیش‌فرض بدون مراحل راه‌اندازی شرح‌داده‌شده در بالا) رد خواهند شد.

راه‌اندازی شبیه‌ساز

می‌توانید از شبیه‌ساز Authentication به‌صورت تعاملی ازطریق Emulator Suite UI و به‌صورت غیرتعاملی ازطریق میانای REST محلی آن استفاده کنید. بخش‌های زیر موارد استفاده تعاملی و غیرتعاملی را پوشش می‌دهند.

برای شروع شبیه‌ساز Authentication، میانای REST آن، و Emulator Suite UI، این دستور را اجرا کنید:

firebase emulators:start

برای اصالت‌سنجی ناشناس، برنامه‌تان می‌تواند منطق ورود به سیستم را برای پلاتفرم شما (iOS، Android، وب) اجرا کند.

برای اصالت‌سنجی ایمیل/گذرواژه، می‌توانید با افزودن حساب‌های کاربری به شبیه‌ساز Authentication از برنامه‌تان بااستفاده از روش‌های کیت توسعه نرم‌افزار Authentication یا بااستفاده از Emulator Suite UI، نمونه‌سازی اولیه را شروع کنید.

  1. در Emulator Suite UI، روی برگه اصالت‌سنجی کلیک کنید.
  2. روی دکمه افزودن کاربر کلیک کنید.
  3. مراحل برنامه نصب ایجاد حساب کاربری را دنبال کنید و فیلدهای اصالت‌سنجی ایمیل را تکمیل کنید.

با ایجاد کاربر آزمایشی، برنامه‌تان می‌تواند با منطق کیت توسعه نرم‌افزار برای پلاتفرم شما (iOS، Android، وب) کاربر را به سیستم وارد و از آن خارج کند.

برای آزمایش درستی‌سنجی ایمیل/ورود به سیستم با جریان‌های پیوند ایمیل، شبیه‌ساز نشانی وبی را در پایانه‌ای که 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"
  }
}

برای آزمایش بازنشانی گذرواژه، شبیه‌ساز نشانی وب مشابهی را در پایانه چاپ می‌کند که شامل پارامتر 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 را برای ایجاد و حذف حساب‌های کاربری و واکشی کدهای درستی‌سنجی ایمیل خارج از باند برای پر کردن نشانی وب درستی‌سنجی ایمیل شبیه‌ساز فراخوانی می‌کنند. این کار کد پلاتفرم و کد آزمایش را از هم جدا نگه می‌دارد و به شما امکان می‌دهد به‌صورت غیرتعاملی آزمایش کنید.

برای جریان‌های آزمایشی غیرتعاملی ایمیل و گذرواژه، توالی معمول به‌صورت زیر است.

  1. کاربران را با Authentication نقطه پایانی REST ثبت‌نام ایجاد کنید.
  2. کاربران را بااستفاده از ایمیل‌ها و گذرواژه‌ها برای انجام آزمایش‌ها به سیستم وارد کنید.
  3. اگر برای آزمایش‌هایتان کاربرد دارد، کدهای درستی‌سنجی ایمیل خارج‌از باند دردسترس را از نقطه پایانی REST مختص شبیه‌ساز واکشی کنید.
  4. بااستفاده از نقطه پایانی REST مختص شبیه‌ساز برای پاک کردن داده‌ها، سوابق کاربر را پاک کنید.

اصالت‌سنجی شبیه‌سازی‌شده تلفن/ پیامک

برای اصالت‌سنجی تلفن، شبیه‌ساز Auth از موارد زیر پشتیبانی نمی‌کند:

  • جریان‌های reCAPTCHA و APN. پس‌از پیکربندی برای تعامل با شبیه‌ساز، کیت‌های توسعه نرم‌افزار کارخواه این روش‌های درستی‌سنجی را به‌روشی مشابه آنچه برای آزمایش ادغام شرح داده شده است غیرفعال می‌کنند (iOS، Android، وب).
  • شماره تلفن‌های آزمایشی با کدهای ازپیش پیکربندی‌شده در کنسول Firebase.

درغیراین‌صورت، ازنظر کد کارخواه، جریان اصالت‌سنجی تلفن/ پیامک با آنچه برای تولید شرح داده شده است (iOS، Android، وب) یکسان است.

بااستفاده از Emulator Suite UI:

  1. در Emulator Suite UI، روی برگه اصالت‌سنجی کلیک کنید.
  2. روی دکمه افزودن کاربر کلیک کنید.
  3. مراحل جادوی ایجاد حساب کاربری را دنبال کنید و فیلدهای اصالت‌سنجی تلفن را تکمیل کنید.

بااین‌حال، برای جریان‌های اصالت‌سنجی تلفن، شبیه‌ساز ارسال هیچ پیامکی را راه‌اندازی نخواهد کرد، زیرا تماس با شرکت مخابراتی خارج از محدوده است و برای آزمایش محلی مناسب نیست! درعوض، شبیه‌ساز کدی را که باید ازطریق پیامک به همان پایانه‌ای که firebase emulators:start را در آن اجرا کرده‌اید ارسال می‌شد چاپ می‌کند؛ این کد را در برنامه وارد کنید تا بررسی پیامک‌ها توسط کاربران شبیه‌سازی شود.

آزمایش غیرتعاملی

برای آزمایش اصالت‌سنجی تلفن غیرتعاملی، از شبیه‌ساز Authentication REST API برای بازیابی کدهای پیامک دردسترس استفاده کنید. توجه داشته باشید که هر بار که جریان را شروع می‌کنید، کد متفاوت است.

توالی معمول به‌صورت زیر است.

  1. برای شروع فرایند درستی‌سنجی، با پلاتفرم signInWithPhoneNumber تماس بگیرید.
  2. کد درستی‌سنجی را بااستفاده از نقطه پایانی REST مختص شبیه‌ساز بازیابی کنید.
  3. با کد درستی‌سنجی، مثل همیشه با confirmationResult.confirm(code) تماس بگیرید.

پیامک چندعاملی

شبیه‌ساز Authentication از نمونه‌سازی و آزمایش جریان‌های اصالت‌سنجی چندعاملی (MFA) پیامکی که در تولید برای iOS، Android، و وب دردسترس است پشتیبانی می‌کند.

وقتی کاربر ساختگی به شبیه‌ساز اضافه می‌کنید، می‌توانید «احراز هویت چندعاملی» را فعال کنید و یک یا چند شماره تلفن را که پیامک‌های عامل دوم به آن‌ها ارسال می‌شود پیکربندی کنید. پیام‌ها به همان پایانه‌ای که firebase emulators:start را در آن اجرا کردید خروجی داده می‌شوند، و ازطریق میانای REST دردسترس هستند.

اصالت‌سنجی ارائه‌دهنده هویت (IDP) طرف سوم شبیه‌سازی‌شده

شبیه‌ساز Authentication به شما امکان می‌دهد بسیاری از جریان‌های اصالت‌سنجی طرف سوم را در برنامه‌های iOS،‏ Android، یا وب خود بدون هیچ تغییری در کد تولید آزمایش کنید. برای نمونه‌هایی از جریان‌های اصالت‌سنجی، به اسناد مربوط به ترکیب‌های مختلف ارائه‌دهندگان و پلاتفرم‌هایی که می‌توانید در برنامه‌تان استفاده کنید مراجعه کنید.

به‌طور کلی، می‌توانید از کیت توسعه نرم‌افزار Firebase برای اصالت‌سنجی به یکی از دو روش زیر استفاده کنید:

  • برنامه شما به کیت توسعه نرم‌افزار اجازه می‌دهد کل فرایند را به‌صورت سرتاسر مدیریت کند، ازجمله همه تعاملات با ارائه‌دهندگان شخص ثالث IDP برای بازیابی اطلاعات کاربری.
  • برنامه شما بااستفاده از کیت توسعه نرم‌افزار ارائه‌دهنده طرف سوم، اعتبارنامه‌ها را به‌صورت دستی از آن ارائه‌دهنده بازیابی می‌کند و آن اعتبارنامه‌ها را به کیت توسعه نرم‌افزار Authentication ارسال می‌کند.

مجدداً پیوند اسناد بالا را بررسی کنید و مطمئن شوید با هر جریانی که می‌خواهید استفاده کنید (مدیریت‌شده توسط کیت توسعه نرم‌افزار Firebase درمقابل بازیابی دستی اعتبارنامه) آشنا هستید. شبیه‌ساز Authentication از آزمایش هر دو رویکرد پشتیبانی می‌کند.

درحال آزمایش جریان‌های IDP مبتنی بر کیت توسعه نرم‌افزار Firebase

اگر برنامه‌تان از هر جریان سرتاسری Firebase SDK استفاده می‌کند، مثل OAuthProvider برای ورود به سیستم با Microsoft،‏ GitHub، یا Yahoo، برای آزمایش تعاملی، شبیه‌ساز Authentication نسخه محلی صفحه ورود به سیستم مربوطه را ارائه می‌دهد تا به شما کمک کند اصالت‌سنجی را از برنامه‌های وب که روش signinWithPopup یا signInWithRedirect را فراخوانی می‌کنند آزمایش کنید. این صفحه ورود به سیستم که به‌صورت محلی ارائه می‌شود در برنامه‌های تلفن همراه نیز ظاهر می‌شود و توسط کتابخانه وب‌نمای پلاتفرم شما ارائه می‌شود.

شبیه‌ساز حساب‌های کاربری و اعتبارنامه‌های ساختگی طرف سوم را درصورت نیاز با پیشرفت جریان‌ها ایجاد می‌کند.

درحال آزمایش جریان‌های «ارائه‌دهنده هویت» با بازیابی دستی اطلاعات اعتباری

اگر از روش‌های ورود به سیستم «دستی» استفاده می‌کنید و روش signInWithCredentials پلاتفرمتان را فراخوانی می‌کنید، دراین‌صورت، طبق معمول، برنامه‌تان درخواست ورود به سیستم طرف سوم واقعی را می‌دهد و اطلاعات اعتباری طرف سوم واقعی را بازیابی می‌کند.

توجه داشته باشید که شبیه‌ساز فقط از اصالت‌سنجی signInWithCredential برای اطلاعات اعتباری بازیابی‌شده از «ورود به سیستم با Google»، ‏Apple، و سایر ارائه‌دهندگانی که از توکن‌های شناسه پیاده‌سازی‌شده به‌عنوان «توکن‌های وب JSON» ‏(JWT) استفاده می‌کنند پشتیبانی می‌کند. نشان‌های دسترسی (مثلاً نشان‌های ارائه‌شده توسط Facebook یا Twitter که JWT نیستند) پشتیبانی نمی‌شوند. در بخش بعدی، جایگزینی برای این موارد بحث می‌شود.

آزمایش غیرتعاملی

یک رویکرد برای آزمایش غیرتعاملی، خودکارسازی کلیک‌های کاربر در صفحه ورود به سیستم ارائه‌شده توسط شبیه‌ساز است. برای برنامه‌های وب، از میانای کنترلی مانند WebDriver استفاده کنید. برای تلفن همراه، از ابزار آزمایش واسط کاربر پلاتفرم خود، مانند Espresso یا Xcode، استفاده کنید.

یا می‌توانید کدتان را برای استفاده از signInWithCredential به‌روز کنید (مثلاً در شاخه کد) و از جریان اصالت‌سنجی بااستفاده از کد با کدهای شناسه ساختگی برای حساب‌ها به‌جای اطلاعات اعتباری واقعی استفاده کنید.

  1. بخشی از کدتان را که idTokens را از IDP بازیابی می‌کند، بازسیم‌کشی یا غیرفعال کنید؛ این کار نیاز به وارد کردن نام‌های کاربری و گذرواژه‌های واقعی را درطول آزمایش‌هایتان برطرف می‌کند و آزمایش‌هایتان را از سهمیه‌های API و محدودیت‌های نرخ در IDP رها می‌کند.
  2. دوم، از رشته JSON تحت‌اللفظی به‌جای کد برای signInWithCredential استفاده کنید. بااستفاده از کیت توسعه نرم‌افزار وب به‌عنوان نمونه، می‌توانید کد را به این صورت تغییر دهید:
firebase.auth().signInWithCredential(firebase.auth.GoogleAuthProvider.credential(
  '{"sub": "abc123", "email": "foo@example.com", "email_verified": true}'
));

وقتی از این کد با شبیه‌ساز استفاده شود، اصالت کاربر با ایمیل foo@example.com در Google باموفقیت تأیید خواهد شد. فیلد sub را به‌عنوان کلید اصلی درنظر بگیرید، که می‌تواند به هر رشته‌ای تغییر کند و ورود به سیستم کاربران مختلف را شبیه‌سازی کند. می‌توانید firebase.auth.GoogleAuthProvider را با، برای مثال، new firebase.auth.OAuthProvider('yahoo.com') یا هر شناسه ارائه‌دهنده دیگری که می‌خواهید شبیه‌سازی کنید جایگزین کنید.

اصالت‌سنجی با کد سفارشی شبیه‌سازی‌شده

شبیه‌ساز Authentication اصالت‌سنجی با «نشان‌های وب JSON» سفارشی را بااستفاده از فراخوانی‌های روش signInWithCustomToken در پلاتفرم‌های پشتیبانی‌شده، همان‌طور که در اسناد Authentication تولید شرح داده شده است، مدیریت می‌کند.

تفاوت شبیه‌ساز Authentication با تولید

شبیه‌ساز Firebase Authentication بسیاری از ویژگی‌های محصول تولیدی را شبیه‌سازی می‌کند. بااین‌حال، ازآنجایی‌که هر نوع سیستم اصالت‌سنجی به‌شدت به امنیت در سطوح مختلف (دستگاه، ارائه‌دهندگان شخص ثالث، Firebase، و غیره) متکی است، برای شبیه‌ساز دشوار است که همه جریان‌ها را به‌درستی بازسازی کند.

Cloud IAM

«مجموعه شبیه‌ساز Firebase» تلاش نمی‌کند هیچ‌گونه رفتار مرتبط با IAM را برای اجرا تکرار کند یا به آن احترام بگذارد. شبیه‌سازها از «قوانین امنیتی Firebase» ارائه‌شده پیروی می‌کنند، اما در شرایطی که معمولاً از IAM استفاده می‌شود، برای مثال برای تنظیم حساب سرویس فراخواننده Cloud Functions و درنتیجه اجازه‌ها، شبیه‌ساز قابل‌پیکربندی نیست و از حساب دردسترس جهانی در ماشین توسعه‌دهنده شما استفاده می‌کند، مشابه اجرای مستقیم اسکریپت محلی.

ازآنجایی‌که در پلاتفرم‌های تلفن همراه، ورود به سیستم با پیوند ایمیل به «پیوندهای پویای Firebase» متکی است، همه این پیوندها در پلاتفرم وب (تلفن همراه) باز خواهند شد.

ورود به سیستم طرف سوم

برای جریان‌های ورود به سیستم طرف سوم، Firebase Authentication به اعتبارنامه‌های امن از ارائه‌دهندگان طرف سوم مانند Twitter و Github متکی است.

شبیه‌ساز Authentication اعتبارنامه‌های واقعی ارائه‌دهندگان OpenID Connect مانند Google و Apple را می‌پذیرد. اعتبارنامه‌های ارائه‌دهندگان غیر OpenID Connect پشتیبانی نمی‌شود.

ورود به سیستم با ایمیل / پیامک

در برنامه‌های تولید، جریان‌های ورود به سیستم با ایمیل و پیامک شامل یک عملیات ناهمگام است که در آن کاربر پیام دریافتی را بررسی می‌کند و کد ورود به سیستم را در میانای ورود به سیستم وارد می‌کند. شبیه‌ساز Authentication هیچ ایمیل یا پیامکی ارسال نمی‌کند، اما همان‌طور که در بالا توضیح داده شد، کدهای ورود به سیستم را تولید می‌کند و آن‌ها را به پایانه ارسال می‌کند تا در آزمایش استفاده شوند.

شبیه‌ساز از قابلیت تعریف شماره تلفن‌های آزمایشی با کدهای ورود ثابت (که بااستفاده از کنسول Firebase قابل انجام است) پشتیبانی نمی‌کند.

اصالت‌سنجی کد سفارشی

شبیه‌ساز Authentication امضا یا انقضای کدهای سفارشی را اعتبارسنجی نمی‌کند. این کار به شما امکان می‌دهد از نشان‌های دست‌ساز استفاده کنید و از نشان‌ها به‌طور نامحدود در سناریوهای نمونه‌سازی و آزمایش استفاده مجدد کنید.

محدود کردن نرخ / ضدسوءاستفاده

شبیه‌ساز Authentication ویژگی‌های محدود کردن نرخ تولید یا ضدسوءاستفاده را تکرار نمی‌کند.

عملکردهای مسدودسازی

در تولید، کاربران یک‌بار پس‌از راه‌اندازی هر دو رویداد beforeCreate و beforeSignIn در فضای ذخیره‌سازی نوشته می‌شوند. بااین‌حال، به‌دلیل محدودیت‌های فنی، شبیه‌ساز Authentication دو بار در فضای ذخیره‌سازی می‌نویسد، یک بار پس‌از ایجاد کاربر و بار دیگر پس‌از ورود به سیستم. این یعنی برای کاربران جدید، می‌توانید با موفقیت getAuth().getUser() را در beforeSignIn در شبیه‌ساز Authentication فراخوانی کنید، اما در تولید با خطا مواجه خواهید شد.

بعد چه می‌شود؟