אובייקט המשתמש של Firebase מייצג חשבון משתמש שנרשם לאפליקציה בפרויקט שלך. לאפליקציות יש בדרך כלל משתמשים רשומים רבים, וכל אפליקציה בפרויקט חולקת מסד נתונים של משתמשים.
מופעי משתמשים אינם תלויים במופעי אימות Firebase, כך שתוכל לקבל מספר הפניות למשתמשים שונים באותו הקשר ועדיין לקרוא לכל אחת מהשיטות שלהם.
מאפייני משתמש
למשתמשי Firebase יש קבוצה קבועה של מאפיינים בסיסיים - מזהה ייחודי, כתובת דוא"ל ראשית, שם וכתובת URL של תמונה - המאוחסנת במסד הנתונים של המשתמשים של הפרויקט, שניתן לעדכן על ידי המשתמש ( iOS , אנדרואיד , אינטרנט ). לא ניתן להוסיף מאפיינים אחרים לאובייקט המשתמש ישירות; במקום זאת, אתה יכול לאחסן את הנכסים הנוספים בכל שירותי אחסון אחרים, כמו Google Cloud Firestore.
בפעם הראשונה שמשתמש נרשם לאפליקציה שלך, נתוני הפרופיל של המשתמש מאוכלסים באמצעות המידע הזמין:
- אם המשתמש נרשם עם כתובת דוא"ל וסיסמה, רק מאפיין כתובת הדוא"ל הראשי מאוכלס
- אם המשתמש נרשם עם ספק זהות מאוחד, כגון גוגל או פייסבוק, פרטי החשבון שזמינים על ידי הספק משמשים לאכלוס הפרופיל של המשתמש
- אם המשתמש נרשם למערכת ההרשאה המותאמת אישית שלך, עליך להוסיף במפורש את המידע הרצוי לפרופיל המשתמש
לאחר יצירת חשבון משתמש, אתה יכול לטעון מחדש את המידע של המשתמש כדי לכלול את כל השינויים שהמשתמש עשה במכשיר אחר.
ספקי כניסה
אתה יכול להיכנס משתמשים לאפליקציות שלך באמצעות מספר שיטות: כתובת דוא"ל וסיסמה, ספקי זהות מאוחדים ומערכת ההרשאה המותאמת אישית שלך. אתה יכול לשייך יותר משיטת כניסה אחת למשתמש: לדוגמה, משתמש יכול להיכנס לאותו חשבון באמצעות כתובת אימייל וסיסמה, או באמצעות Google Sign-In.
מופעי משתמשים עוקבים אחר כל ספק המקושר למשתמש. זה מאפשר לך לעדכן את המאפיינים של פרופיל ריק באמצעות המידע שניתן על ידי ספק. ראה ניהול משתמשים ( iOS , Android , אינטרנט ).
המשתמש הנוכחי
כאשר משתמש נרשם או נכנס, משתמש זה הופך למשתמש הנוכחי של מופע האימות. המופע ממשיך את מצב המשתמש, כך שרענון הדף (בדפדפן) או הפעלה מחדש של האפליקציה לא יאבדו את המידע של המשתמש.
כאשר המשתמש יוצא, מופע ה-Auth מפסיק לשמור הפניה לאובייקט המשתמש ואינו ממשיך במצבו; אין משתמש נוכחי. עם זאת, מופע המשתמש ממשיך להיות פונקציונלי לחלוטין: אם תשמור עליו הפניה, אתה עדיין יכול לגשת ולעדכן את נתוני המשתמש.
מחזור החיים של המשתמש
הדרך המומלצת לעקוב אחר המצב הנוכחי של מופע ה-Auth היא באמצעות מאזינים (הנקראים גם "צופים" ב-JavaScript). מאזין Auth מקבל הודעה בכל פעם שקורה משהו רלוונטי לאובייקט Auth. ראה ניהול משתמשים ( iOS , Android , אינטרנט ).
מאזין Auth מקבל התראה במצבים הבאים:
- האובייקט Auth מסיים את האתחול ומשתמש כבר היה מחובר מהפעלה קודמת, או הופנה מחדש מתהליך הכניסה של ספק זהות
- משתמש נכנס (המשתמש הנוכחי מוגדר)
- משתמש יוצא (המשתמש הנוכחי הופך לריק)
- אסימון הגישה של המשתמש הנוכחי רענן. מקרה זה יכול לקרות בתנאים הבאים:
- תוקף אסימון הגישה יפוג: זהו מצב שכיח. אסימון הרענון משמש כדי לקבל קבוצה חוקית חדשה של אסימונים.
- המשתמש משנה את הסיסמה שלו: Firebase מנפיק גישה חדשה ורענון אסימונים וגורם לאסימונים הישנים לפוג. פעולה זו מפיגה אוטומטית את האסימון של המשתמש ו/או יוצאת מהמשתמש בכל מכשיר, מטעמי אבטחה.
- המשתמש מאמת מחדש: חלק מהפעולות מחייבות את הנפקת האישורים של המשתמש לאחרונה; פעולות כאלה כוללות מחיקת חשבון, הגדרת כתובת דוא"ל ראשית ושינוי סיסמה. במקום לצאת מהמשתמש ואז להיכנס שוב למשתמש, קבל אישורים חדשים מהמשתמש, והעביר את האישורים החדשים לשיטת האימות מחדש של אובייקט המשתמש.
שירות עצמי למשתמש
כברירת מחדל, Firebase מאפשר למשתמשים להירשם ולמחוק את החשבונות שלהם ללא התערבות מנהלתית. בנסיבות רבות, זה מאפשר למשתמשי קצה לגלות את האפליקציה או השירות שלך ומשולב (או מחוץ למטוס) עם חיכוך מינימלי.
עם זאת, ישנם מצבים שבהם אתה רוצה שמשתמשים ייצרו באופן ידני או פרוגרמטי על ידי מנהל מערכת, באמצעות ה-Admin SDK או מסוף Firebase. במקרים אלה, תוכל להשבית את פעולות המשתמש מהדף הגדרות אימות Firebase , המונע יצירת ומחיקה של חשבון על ידי משתמשי קצה. אם אתה משתמש בריבוי דירות, תצטרך להגיש בקשת HTTP כדי להשבית את התכונות הללו על בסיס דייר.
אם משתמש קצה ינסה ליצור או למחוק חשבון במערכת שלך, שירות Firebase יחזיר קוד שגיאה: auth/admin-restricted-operation עבור קריאות Web API, או ERROR_ADMIN_RESTRICTED_OPERATION עבור Android ו-iOS. עליך לטפל בשגיאה בחזית שלך בחן על ידי בקשה מהמשתמש לבצע את הפעולות המתאימות עבור השירות שלך.
אסימוני אישור
כאשר אתה מבצע אימות עם Firebase, ישנם שלושה סוגים של אסימוני אימות שאתה עלול להיתקל בהם:
| אסימוני מזהה של Firebase | נוצר על ידי Firebase כאשר משתמש נכנס לאפליקציה. האסימונים האלה הם JWTs חתומים המזהים באופן מאובטח משתמש בפרויקט Firebase. האסימונים האלה מכילים מידע בסיסי על הפרופיל של משתמש, כולל מחרוזת המזהה של המשתמש, שהיא ייחודית לפרויקט Firebase. מכיוון שניתן לאמת את תקינותם של אסימוני זיהוי , אתה יכול לשלוח אותם לשרת קצה כדי לזהות את המשתמש המחובר כעת. |
| אסימוני ספק זהות | נוצר על ידי ספקי זהות מאוחדים, כגון גוגל ופייסבוק. לאסימונים אלה יכולים להיות פורמטים שונים, אך הם לרוב אסימוני גישה של OAuth 2.0. אפליקציות משתמשות באסימונים אלה כדי לוודא שמשתמשים אומתו בהצלחה מול ספק הזהות, ולאחר מכן ממירים אותם לאישורים הניתנים לשימוש על ידי שירותי Firebase. |
| אסימונים מותאמים אישית של Firebase | נוצר על ידי מערכת ההרשאה המותאמת אישית שלך כדי לאפשר למשתמשים להיכנס לאפליקציה באמצעות מערכת ההרשאה שלך. אסימונים מותאמים אישית הם JWTs החתומים באמצעות המפתח הפרטי של חשבון שירות . אפליקציות משתמשות באסימונים האלה כמו שהם משתמשים באסימונים המוחזרים מספקי זהות מאוחדים. |
כתובות אימייל מאומתות
Firebase רואה באימייל מאומת אם הוא עומד בשני תנאים:
- המשתמש משלים את זרימת האימות של Firebase
- האימייל מאומת על ידי ספק זהות מהימן, או בקיצור 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, אך אנו ממליצים לעשות זאת רק אם אתה יודע שהמשתמש באמת הבעלים של האימייל.