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

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

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

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

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

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

בחירת פרויקט ב-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");
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 SDKs יקבלו אסימוני מזהה לא חתומים וקובצי cookie של סשנים שהונפקו על ידי אמולטור 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 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. כדי לנקות את הנתונים, צריך לנקות את רשומות המשתמשים באמצעות נקודת הקצה הספציפית ל-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. מזינים את הקוד הזה באפליקציה כדי לדמות משתמשים שבודקים את הודעות הטקסט שלהם.

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

כדי לבדוק אימות טלפון לא אינטראקטיבי, משתמשים ב-Authentication emulator API ל-REST כדי לאחזר קודי 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.

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

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

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

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

אימות טוקנים בהתאמה אישית

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

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

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

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

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

מה הלאה?