משתמשים בפרויקטים של Firebase

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

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

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

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

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

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

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

ספקי כניסה

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

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

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

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

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

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

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

מאזין Auth מקבל הודעה במצבים הבאים:

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

אסימוני אימות

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

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

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

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

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

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

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

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

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

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

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

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

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