חיבור האפליקציה לאמולטור האימות

לפני שמשתמשים באמולטור של Authentication באפליקציה, חשוב להבין את תהליך העבודה הכולל של Firebase Local Emulator Suite, להתקין ולהגדיר את Local Emulator Suite ולעיין בפקודות ה-CLI שלו.

הנושא הזה מניח שאתם כבר מכירים את הפיתוח של פתרונות Firebase Authentication לסביבת הייצור. אם צריך, עיינו במסמכי התיעוד של השילוב של הפלטפורמה ושיטת האימות.

מה אפשר לעשות עם האמולטור של Authentication?

האמולטור של Authentication מספק אמולציה מקומית באיכות גבוהה של שירותי Firebase Authentication, ומספק הרבה מהפונקציונליות שנמצאת בFirebase Authentication בסביבת הייצור. בשילוב עם ערכות ה-SDK של Firebase לפלטפורמות של אפל, ל-Android ול-Web, האמולטור מאפשר לכם:

  • יצירה, עדכון וניהול של חשבונות משתמשים מדומים כדי לבדוק אימות של כתובת אימייל/סיסמה, מספר טלפון/SMS, אימות רב-גורמי ב-SMS וספק זהויות של צד שלישי (למשל Google)
  • הצגה ועריכה של משתמשים מדומים
  • מערכות אימות של אסימונים בהתאמה אישית לאב טיפוס
  • בודקים את ההודעות שקשורות לאימות בכרטיסייה Logs בממשק המשתמש של האמולטור.

בחירת פרויקט ב-Firebase

Firebase Local Emulator Suite מדמה מוצרים לפרויקט Firebase אחד.

כדי לבחור את הפרויקט שבו רוצים להשתמש, לפני שמפעילים את האמולטורים, מריצים את firebase use ב-CLI בספריית העבודה. אפשר גם להעביר את הדגל --project לכל פקודת אמולטור.

Local Emulator Suite תומך באמולציה של פרויקטים אמיתיים ופרויקטים להדגמה ב-Firebase.

סוג הפרויקט תכונות שימוש באמולטורים
ריאל

פרויקט Firebase אמיתי הוא פרויקט שיצרתם והגדרתם (בדרך כלל באמצעות מסוף Firebase).

בפרויקטים אמיתיים יש משאבים פעילים, כמו מכונות של מסדי נתונים, קטגוריות אחסון, פונקציות או כל משאב אחר שהגדרתם לפרויקט Firebase הזה.

כשעובדים עם פרויקטים אמיתיים ב-Firebase, אפשר להריץ אמולטורים לכל אחד מהמוצרים הנתמכים או לכולם.

בכל מוצר שלא מפעילים בו אמולציה, האפליקציות והקוד יתקשרו עם המשאב הפעיל (מכונה של מסד נתונים, קטגוריית אחסון, פונקציה וכו').

הדגמה

לפרויקט הדגמה ב-Firebase אין הגדרות אמיתיות של Firebase ואין משאבים פעילים. בדרך כלל ניגשים לפרויקטים האלה דרך שיעורי Lab ב-Codelabs או מדריכים אחרים.

מזהי הפרויקטים של פרויקטים לדוגמה כוללים את הקידומת 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)
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 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 SDKs יקבלו טוקנים של מזהים לא חתומים וקובצי Cookie זמניים שהונפקו על ידי האמולטור של Authentication (באמצעות השיטות verifyIdToken ו-createSessionCookie בהתאמה) כדי לאפשר פיתוח ובדיקה מקומיים. חשוב לוודא שלא מגדירים את משתנה הסביבה בסביבת הייצור.

אם אתם רוצים שקוד Admin SDK יתחבר לאמולטור משותף שפועל בסביבה אחרת, תצטרכו לציין את מזהה הפרויקט שהגדרתם באמצעות Firebase CLI. אפשר להעביר מזהה פרויקט אל 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, לוחצים על הכרטיסייה Authentication.
  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 או בקוד הלקוח כדי לנהל חשבונות משתמשים עם אימייל וסיסמה, אתם יכולים לכתוב סקריפטים של הגדרות בדיקה שקוראים לממשקי API בארכיטקטורת REST כדי ליצור ולמחוק חשבונות משתמשים, ולאחזר קודי אימות של אימייל מחוץ לתחום כדי לאכלס את כתובת ה-URL לאימות אימייל של האמולטור. כך קוד הפלטפורמה וקוד הבדיקה נשארים נפרדים, ואפשר לבצע בדיקות לא אינטראקטיביות.

בתהליכי בדיקה לא אינטראקטיביים של כתובת אימייל וסיסמה, הרצף הרגיל הוא:

  1. יוצרים משתמשים באמצעות Authentication signUp REST endpoint.
  2. כדי לבצע בדיקות, צריך להיכנס לחשבונות של המשתמשים באמצעות כתובות האימייל והסיסמאות.
  3. אם זה רלוונטי לבדיקות שלכם, אחזרו קודי אימות זמינים של אימייל מחוץ לתחום מנקודת הקצה (endpoint) של REST הספציפית לאמולטור.
  4. מנקים את רשומות המשתמשים באמצעות נקודת הקצה (endpoint) של REST הספציפית לאמולטור כדי למחוק את הנתונים.

אימות מדומה באמצעות טלפון או SMS

לאימות טלפוני, אמולטור Auth לא תומך ב:

  • תהליכי reCAPTCHA ו-APN. אחרי שמגדירים את ערכות ה-SDK של הלקוח לאינטראקציה עם הסימולטור, הן משביתות את שיטות האימות האלה באופן דומה לזה שמתואר לבדיקות שילוב (iOS,‏ Android, אינטרנט).
  • מספרי טלפון לבדיקה עם קודים שהוגדרו מראש במסוף Firebase.

אחרת, מבחינת קוד הלקוח, תהליך האימות באמצעות טלפון או SMS זהה לזה שמתואר בסביבת הייצור (iOS,‏ Android, אינטרנט).

באמצעות Emulator Suite UI:

  1. בEmulator Suite UI, לוחצים על הכרטיסייה Authentication.
  2. לוחצים על הכפתור הוספת משתמש.
  3. פועלים לפי ההוראות באשף ליצירת חשבון משתמש וממלאים את השדות של אימות הטלפון.

עם זאת, בתהליכי אימות באמצעות הטלפון, האמולטור לא יפעיל שליחה של הודעות SMS, כי יצירת קשר עם ספק היא מחוץ להיקף ולא מתאימה לבדיקה מקומית. במקום זאת, האמולטור מדפיס את הקוד שהיה נשלח ב-SMS לאותו מסוף שבו הפעלתם את firebase emulators:start. הזינו את הקוד הזה באפליקציה כדי לדמות משתמשים שבודקים את הודעות הטקסט שלהם.

בדיקה לא אינטראקטיבית

כדי לבדוק אימות טלפוני לא אינטראקטיבי, צריך להשתמש ב-API בארכיטקטורת REST של אמולטור Authentication כדי לאחזר קודי SMS זמינים. שימו לב שהקוד משתנה בכל פעם שמתחילים את התהליך.

זהו הרצף הרגיל:

  1. כדי להתחיל את תהליך האימות, צריך להתקשר לפלטפורמה signInWithPhoneNumber.
  2. מאחזרים את קוד האימות באמצעות נקודת הקצה (endpoint) של REST הספציפית לאמולטור.
  3. מתקשרים אל confirmationResult.confirm(code) כרגיל עם קוד האימות.

אימות רב-שלבי באמצעות SMS

האמולטור של Authentication תומך ביצירת אב טיפוס ובבדיקה של תהליכי האימות הרב-שלבי (MFA) באמצעות SMS שזמינים בסביבת הייצור ל-iOS, ל-Android ולאינטרנט.

כשמוסיפים משתמש מדומה לאמולטור, אפשר להפעיל MFA ולהגדיר מספר טלפון אחד או יותר שאליו יישלחו הודעות SMS עם הגורם השני. ההודעות נשלחות לאותו מסוף שבו הפעלתם את firebase emulators:start, והן זמינות מממשק ה-REST.

אימות מדומה של ספק זהויות (IDP) מצד שלישי

האמולטור של Authentication מאפשר לבדוק תהליכי אימות רבים של צד שלישי באפליקציות ל-iOS, ל-Android או לאינטרנט, בלי לשנות את קוד הייצור. לדוגמאות של תהליכי אימות, עיינו במסמכי התיעוד של השילובים השונים של ספקים ופלטפורמות שבהם אתם יכולים להשתמש באפליקציה.

באופן כללי, אפשר להשתמש ב-Firebase SDK כדי לבצע אימות באחת משתי דרכים:

  • האפליקציה מאפשרת ל-SDK לטפל בכל התהליך מקצה לקצה, כולל כל האינטראקציות עם ספקי IDP של צד שלישי כדי לאחזר את פרטי הכניסה.
  • האפליקציה מאחזרת באופן ידני את פרטי הכניסה מספק צד שלישי באמצעות ה-SDK של אותו ספק, ומעבירה את פרטי הכניסה האלה ל-SDK של Authentication.

שוב, כדאי לעיין בקישור למסמכי התיעוד שלמעלה ולוודא שאתם מכירים את התהליך שבו אתם רוצים להשתמש – ניהול באמצעות Firebase SDK או אחזור ידני של פרטי הכניסה. האמולטור של Authentication תומך בבדיקה של שתי הגישות.

בדיקת תהליכי IDP שמבוססים על Firebase SDK

אם האפליקציה שלכם משתמשת בתהליך מקצה לקצה של Firebase SDK, כמו OAuthProvider לכניסה באמצעות Microsoft,‏ GitHub או Yahoo, לצורך בדיקה אינטראקטיבית, האמולטור של Authentication מציג גרסה מקומית של דף הכניסה המתאים כדי לעזור לכם לבדוק את האימות מאפליקציות אינטרנט שקוראות ל-method‏ signinWithPopup או signInWithRedirect. דף הכניסה הזה, שמוצג באופן מקומי, מופיע גם באפליקציות לנייד, ומוצג על ידי ספריית ה-WebView של הפלטפורמה.

האמולטור יוצר חשבונות משתמשים ופרטי כניסה מדומים של צד שלישי לפי הצורך, ככל שהתהליכים מתקדמים.

בדיקת תהליכי IDP עם אחזור ידני של פרטי כניסה

אם אתם משתמשים בשיטות כניסה "ידניות" וקוראים ל-method‏ signInWithCredentials של הפלטפורמה, האפליקציה תבקש כניסה אמיתית של צד שלישי ותאחזר פרטי כניסה אמיתיים של צד שלישי, כרגיל.

שימו לב שהאמולטור תומך רק באימות signInWithCredential עבור פרטי כניסה שאוחזרו מ-כניסה באמצעות חשבון Google, מ-אפל ומספקים אחרים שמשתמשים בטוקנים של מזהה המוטמעים כאסימוני אינטרנט מסוג JSON‏ (JWT). אין תמיכה בטוקני גישה (למשל, אלה שסופקו על ידי פייסבוק או טוויטר, שהם לא JWT). בקטע הבא נדון באפשרות חלופית למקרים כאלה.

בדיקה לא אינטראקטיבית

גישה אחת לבדיקה לא אינטראקטיבית היא להפוך לאוטומטיים את הקליקים של המשתמשים בדף הכניסה שמוצג על ידי האמולטור. באפליקציות אינטרנט, משתמשים בממשק בקרה כמו WebDriver. בניידים, משתמשים בכלי לבדיקת ממשק המשתמש מהפלטפורמה, כמו Espresso או Xcode.

לחלופין, אתם יכולים לעדכן את הקוד כך שישתמש ב-signInWithCredential (למשל, בהסתעפות קוד) ולהשתמש בתהליך אימות של טוקנים עם טוקנים מדומים של טוקנים של מזהים עבור חשבונות במקום פרטי כניסה אמיתיים.

  1. לשנות את החיווט או לסמן כהערה את החלק בקוד שמאחזר את idTokens מספק הזהויות. כך לא תצטרכו להזין שמות משתמשים וסיסמאות אמיתיים במהלך הבדיקות, ולא תצטרכו להגביל את הבדיקות למכסות ה-API ולהגבלת קצב של יצירת בקשות של ספק הזהויות.
  2. שנית, משתמשים במחרוזת JSON מילולית במקום בטוקן של signInWithCredential. לדוגמה, ב-Web SDK אפשר לשנות את הקוד כך:
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 בהתאמה אישית, באמצעות קריאות ל-method‏ 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.

כניסה באמצעות אימייל או SMS

באפליקציות בסביבת הייצור, תהליכי הכניסה באמצעות אימייל ו-SMS כוללים פעולה אסינכרונית שבה המשתמש בודק הודעה שהתקבלה ומזין קוד כניסה בממשק הכניסה. האמולטור של Authentication לא שולח אימיילים או הודעות SMS, אבל כמו שמתואר למעלה, הוא יוצר קודי התחברות ומוציא אותם למסוף כדי להשתמש בהם בבדיקות.

האמולטור לא תומך ביכולת להגדיר מספרי טלפון לבדיקה עם קודי התחברות קבועים, כמו שאפשר לעשות באמצעות מסוף Firebase.

אימות באמצעות טוקן מותאם אישית

האמולטור של Authentication לא מאמת את החתימה או את התפוגה של טוקנים בהתאמה אישית. כך אפשר להשתמש בטוקנים שנוצרו באופן ידני ולהשתמש בהם שוב ושוב בתרחישים של יצירת אב טיפוס ובדיקה.

הגבלת קצב של יצירת בקשות / מניעת התנהלות פוגעת

האמולטור של Authentication לא משכפל את התכונות של הגבלת קצב של יצירת בקשות או מניעת ניצול לרעה בסביבת הייצור.

פונקציות חסימה

בסביבת הייצור, המשתמשים נכתבים לאחסון פעם אחת אחרי שמופעלים גם האירוע beforeCreate וגם האירוע beforeSignIn. עם זאת, בגלל מגבלות טכניות, האמולטור של Authentication כותב למאגר פעמיים: פעם אחת אחרי יצירת המשתמש ופעם נוספת אחרי הכניסה. כלומר, למשתמשים חדשים אפשר לקרוא ל-getAuth().getUser() ב-beforeSignIn באמולטור של Authentication, אבל תופיע שגיאה אם תנסו לעשות את זה בסביבת הייצור.

מה הלאה?