Check out what’s new from Firebase at Google I/O 2022. Learn more

משתמשים ב-Firebase Projects

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

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

מאפייני משתמש

למשתמשי Firebase יש קבוצה קבועה של מאפיינים בסיסיים - מזהה ייחודי, כתובת דוא"ל ראשית, שם וכתובת URL של תמונה - המאוחסנת במסד הנתונים של המשתמשים של הפרויקט, שניתן לעדכן על ידי המשתמש ( iOS , Android , אינטרנט ). לא ניתן להוסיף מאפיינים אחרים לאובייקט המשתמש ישירות; במקום זאת, אתה יכול לאחסן את הנכסים הנוספים בכל שירותי אחסון אחרים, כמו Google Cloud Firestore.

בפעם הראשונה שמשתמש נרשם לאפליקציה שלך, נתוני הפרופיל של המשתמש מאוכלסים באמצעות המידע הזמין:

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

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

ספקי כניסה

אתה יכול להיכנס משתמשים לאפליקציות שלך באמצעות מספר שיטות: כתובת דוא"ל וסיסמה, ספקי זהות מאוחדים ומערכת ההרשאה המותאמת אישית שלך. אתה יכול לשייך יותר משיטת כניסה אחת למשתמש: לדוגמה, משתמש יכול להיכנס לאותו חשבון באמצעות כתובת אימייל וסיסמה, או באמצעות Google Sign-In.

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

המשתמש הנוכחי

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

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

מחזור החיים של המשתמש

הדרך המומלצת לעקוב אחר המצב הנוכחי של מופע ה-Auth היא באמצעות מאזינים (הנקראים גם "צופים" ב-JavaScript). מאזין Auth מקבל הודעה בכל פעם שקורה משהו רלוונטי לאובייקט Auth. ראה ניהול משתמשים ( iOS , אנדרואיד , אינטרנט ).

מאזין Auth מקבל התראה במצבים הבאים:

  • האובייקט Auth מסיים את האתחול ומשתמש כבר היה מחובר מהפעלה קודמת, או הופנה מחדש מתהליך הכניסה של ספק זהות
  • משתמש נכנס (המשתמש הנוכחי מוגדר)
  • משתמש יוצא (המשתמש הנוכחי הופך לריק)
  • אסימון הגישה של המשתמש הנוכחי רענן. מקרה זה יכול לקרות בתנאים הבאים:
    • תוקף אסימון הגישה יפוג: זהו מצב שכיח. אסימון הרענון משמש כדי לקבל קבוצה חוקית חדשה של אסימונים.
    • המשתמש משנה את הסיסמה שלו: Firebase מנפיק גישה חדשה ורענון אסימונים וגורם לאסימונים הישנים לפוג. זה יפוג אוטומטית את האסימון של המשתמש ו/או מוציא את המשתמש מכל מכשיר, מטעמי אבטחה.
    • המשתמש מאמת מחדש: חלק מהפעולות מחייבות את הנפקת האישורים של המשתמש לאחרונה; פעולות כאלה כוללות מחיקת חשבון, הגדרת כתובת דוא"ל ראשית ושינוי סיסמה. במקום לצאת מהמשתמש ואז להיכנס שוב למשתמש, קבל אישורים חדשים מהמשתמש, והעביר את האישורים החדשים לשיטת האימות מחדש של אובייקט המשתמש.

אסימוני אישור

כאשר אתה מבצע אימות עם Firebase, ישנם שלושה סוגים של אסימוני אימות שאתה עלול להיתקל בהם:

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

כתובות אימייל מאומתות

Firebase מחשיב דוא"ל מאומת אם הוא עומד בשני תנאים: 1. המשתמש משלים את זרימת האימות של Firebase 2. האימייל מאומת על ידי ספק זהות מהימן, או בקיצור IdP.

IdPs שמאמתים דוא"ל פעם אחת, אך לאחר מכן מאפשרים למשתמשים לשנות כתובות דוא"ל מבלי לדרוש אימות מחדש, אינם מהימנים. IdPs שבבעלותם הדומיין או שתמיד דורשים אימות נחשבים מהימנים.

ספקים מהימנים:

  • Google (עבור כתובות @gmail.com)
  • Yahoo (עבור כתובות @yahoo.com)
  • Microsoft (עבור כתובות @outlook.com ו-@hotmail.com)
  • אפל (מאומת תמיד, מכיוון שחשבונות תמיד מאומתים ומאומתים עם ריבוי גורמים)

ספקים לא מהימנים:

  • פייסבוק
  • טוויטר
  • GitHub
  • Google, Yahoo ו-Microsoft עבור דומיינים שלא הונפקו על ידי אותו ספק זהות
  • דואר אלקטרוני / סיסמא ללא אימות דוא"ל

במצבים מסוימים, Firebase יקשר אוטומטית חשבונות כאשר משתמש נכנס עם ספקים שונים באמצעות אותה כתובת אימייל. עם זאת, זה יכול לקרות רק כאשר מתקיימים קריטריונים ספציפיים. כדי להבין מדוע, שקול את המצב הבא: משתמש נכנס באמצעות Google עם חשבון @gmail.com ושחקן זדוני יוצר חשבון באמצעות אותה כתובת @gmail.com, אך נכנס דרך Facebook. אם שני החשבונות הללו היו מקושרים אוטומטית, השחקן הזדוני יקבל גישה לחשבון המשתמש.

המקרים הבאים מתארים מתי אנו מקשרים אוטומטית חשבונות ומתי אנו זורקים שגיאה הדורשת פעולה של משתמש או מפתח:

  • משתמש נכנס עם ספק לא מהימן, ואז נכנס עם ספק לא מהימן אחר עם אותו דוא"ל (לדוגמה, פייסבוק ואחריו GitHub). זה משליך שגיאה המחייבת קישור חשבון.
  • משתמש נכנס עם ספק מהימן, ואז נכנס עם ספק לא מהימן עם אותו דוא"ל (לדוגמה, גוגל ואחריו פייסבוק). זה משליך שגיאה המחייבת קישור חשבון.
  • משתמש נכנס עם ספק לא מהימן, ואז נכנס עם ספק מהימן עם אותו דוא"ל (לדוגמה, פייסבוק ואחריו גוגל). הספק המהימן מחליף את הספק הלא מהימן. אם המשתמש ינסה להיכנס שוב עם פייסבוק, הדבר יגרום לשגיאה המחייבת קישור חשבון.
  • המשתמש נכנס עם ספק מהימן, ואז נכנס עם ספק מהימן אחר עם אותו דוא"ל (לדוגמה, אפל ואחריו גוגל). שני הספקים יהיו מקושרים ללא שגיאות.

אתה יכול להגדיר באופן ידני אימייל כאומת על ידי שימוש ב-Admin SDK, אך אנו ממליצים לעשות זאת רק אם אתה יודע שהמשתמש באמת הבעלים של האימייל.