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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הדגמה

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

מזהי פרויקטים של פרויקטים לדוגמה כוללים את הקידומת 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");

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 יתחבר לאמולטור משותף שפועל בסביבה אחרת, צריך לציין את אותו מזהה פרויקט שהגדרתם באמצעות ה-CLI של Firebase. אפשר להעביר מזהה פרויקט ישירות ל-initializeApp או להגדיר את משתנה הסביבה GCLOUD_PROJECT.

SDK של Node.js Admin
admin.initializeApp({ projectId: "your-project-id" });
משתנה סביבה
export GCLOUD_PROJECT="your-project-id"

אסימונים מזהים

מטעמי אבטחה, האמולטור Authentication מנפיק אסימוני מזהה לא חתומים, שרק אמולטורים אחרים של Firebase או ה-SDK של Firebase Admin מקבלים אחרי הגדרה. האסימונים האלה יידחו על ידי שירותי Firebase בסביבת הייצור או על ידי Firebase Admin SDK שפועל במצב הייצור (למשל, התנהגות ברירת המחדל ללא שלבי ההגדרה שמפורטים למעלה).

הפעלת האמולטור

אפשר להשתמש במהדמה של Authentication באופן אינטראקטיבי דרך Emulator Suite UI, ובאופן לא אינטראקטיבי דרך ממשק ה-REST המקומי שלו. בקטעים הבאים מפורטים תרחישים לדוגמה של מודעות אינטראקטיביות ושל מודעות לא אינטראקטיביות.

כדי להפעיל את האמולטור Authentication, את ממשק ה-REST שלו ואת Emulator Suite UI, מריצים את:

firebase emulators:start

לאימות אנונימי, האפליקציה יכולה להשתמש בלוגיקה של הכניסה לפלטפורמה (iOS,‏ Android,‏ אינטרנט).

לאימות באמצעות כתובת אימייל או סיסמה, אפשר להתחיל ליצור אב טיפוס על ידי הוספת חשבונות משתמשים למהדמator של Authentication מהאפליקציה באמצעות שיטות ה-SDK של Authentication, או באמצעות 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. יצירת משתמשים באמצעות נקודת הקצה של ה-REST signUp ב-Authentication.
  2. הכנסת משתמשים באמצעות כתובות האימייל והסיסמאות כדי לבצע בדיקות.
  3. אם הבדיקה שלכם רלוונטית לכך, אפשר לאחזר קודי אימות זמינים מחוץ לתהליך (out-of-band) באימייל מנקודת הקצה הספציפית לאמולטור.
  4. ניקוי רשומות המשתמשים באמצעות נקודת קצה (endpoint) של REST שספציפית לאמולטור, לצורך ניקוי נתונים.

אימות טלפוני/SMS במצב אמולציה

בנוגע לאימות בטלפון, אמולטור האימות לא תומך באפשרויות הבאות:

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

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

באמצעות Emulator Suite UI:

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

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

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

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

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

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

SMS רב-שלבי

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

כשאתם מוסיפים משתמש מדומה למהדר, אתם יכולים להפעיל אימות דו-שלבי ולהגדיר מספר טלפון אחד או יותר שאליו יישלחו הודעות 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 מציג גרסה מקומית של דף הכניסה התואם כדי לעזור לכם לבדוק את האימות מאפליקציות אינטרנט שמפעילות את השיטה signinWithPopup או signInWithRedirect. דף הכניסה הזה, שמוצג באופן מקומי, מופיע גם באפליקציות לנייד, והוא עובר עיבוד על ידי ספריית ה-Webview של הפלטפורמה.

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

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

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

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

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

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

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

  1. צריך לשנות את הקוד או להוסיף לו הערה לגבי החלק שמאחזר את האסימונים מסוג idToken מה-IdP. כך לא תצטרכו להזין שמות משתמשים וסיסמאות אמיתיים במהלך הבדיקות, והבדיקות לא יהיו כפופות למכסות API ולמגבלות קצב שליחה ב-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'), למשל, או בכל מזהה ספק אחר שרוצים לדמות.

אימות טוקן מותאם אישית במהדורה משובחת

במהלך האימות באמצעות אסימוני אינטרנט מותאמים אישית מסוג JSON, במהדורת ה-emulator של Authentication מתבצעות קריאות לשיטה signInWithCustomToken בפלטפורמות נתמכות, כפי שמתואר במסמכי העזרה של Authentication בסביבת הייצור.

ההבדל בין המהדורה לבדיקה של Authentication לבין המהדורה בסביבת הייצור

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

Cloud IAM

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

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

כניסה של צד שלישי

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

פרטי כניסה אמיתיים מספקי OpenID Connect, כמו Google ו-Apple, מקבלים באמולטור Authentication. אין תמיכה בפרטי כניסה מספקים שהם לא OpenID Connect.

כניסה לאימייל או ל-SMS

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

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

אימות אסימונים בהתאמה אישית

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

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

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

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

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

מה הלאה?