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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הדגמה

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

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

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 SDKs מתחברים אוטומטית לאמולטור 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 או על ידי Firebase Admin SDK כשמבצעים הגדרה. שירותי Firebase בייצור או Firebase Admin SDK שפועל במצב ייצור ידחו את האסימונים האלה (לדוגמה, התנהגות ברירת המחדל ללא שלבי ההגדרה שמתוארים למעלה).

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

אפשר להשתמש ב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, לוחצים על הכרטיסייה אימות.
  2. לוחצים על הלחצן הוספת משתמש.
  3. פועלים לפי ההוראות באשף ליצירת חשבון משתמש וממלאים את השדות של אימות האימייל.

אחרי שיוצרים משתמש בדיקה, האפליקציה יכולה להכניס ולהוציא את המשתמש באמצעות לוגיקת ה-SDK של הפלטפורמה (iOS,‏ Android,‏ web).

כדי לבדוק תהליכי אימות אימייל או כניסה באמצעות קישור באימייל, האמולטור מדפיס כתובת 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 APIs כדי ליצור ולמחוק חשבונות משתמשים, ולאחזר קודי אימות של כתובות אימייל מחוץ לפס כדי לאכלס את כתובת ה-URL לאימות כתובת האימייל באמולטור. כך אפשר להפריד בין הקוד של הפלטפורמה לבין קוד הבדיקה, ולבדוק בלי אינטראקציה.

בזרימות בדיקה לא אינטראקטיביות של כתובת אימייל וסיסמה, הרצף האופייני הוא כדלקמן.

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

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

באימות טלפון, אמולטור האימות לא תומך ב:

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

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

שימוש ב-Emulator Suite UI:

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

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

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

כדי לבדוק אימות טלפוני לא אינטראקטיבי, אפשר להשתמש ב-REST API של 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 של אותו צד, ומעבירה את פרטי הכניסה האלה ל-Authentication SDK.

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

בדיקת תהליכי אימות של ספקי זהויות (IDP) שמבוססים על Firebase SDK

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

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

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

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

הערה: האמולטור תומך רק בsignInWithCredentialאימות של פרטי כניסה שאוחזרו מ'כניסה באמצעות חשבון Google', מ-Apple ומספקים אחרים שמשתמשים באסימוני מזהה שהוטמעו כאסימוני אינטרנט מסוג JSON‏ (JWT). אין תמיכה בטוקנים של גישה (למשל, אלה שמסופקים על ידי פייסבוק או 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'), למשל, או בכל מזהה ספק אחר שרוצים ליצור לו מוקאפ.

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

האימות באמולטור 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.

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

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

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

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

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

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

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

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

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

מה הלאה?