האובייקט Firebase user מייצג חשבון משתמש שנרשם לאפליקציה בפרויקט. לאפליקציות יש בדרך כלל משתמשים רשומים רבים, וכל אפליקציה משתף את מסד הנתונים של המשתמשים.
מכונות של משתמשים הן עצמאיות ממכונות של Firebase Authentication, כך שאפשר ליצור כמה הפניות למשתמשים שונים באותו הקשר ועדיין להפעיל כל אחת מהשיטות שלהם.
מאפייני משתמש
למשתמשי Firebase יש קבוצה קבועה של מאפיינים בסיסיים – מזהה ייחודי, כתובת אימייל ראשית, שם וכתובת URL של תמונה – שמאוחסנים במסד הנתונים של המשתמשים בפרויקט, והמשתמשים יכולים לעדכן אותם (iOS, Android, אינטרנט). אי אפשר להוסיף מאפיינים אחרים לאובייקט המשתמש באופן ישיר. במקום זאת, אתם יכולים לאחסן את המאפיינים הנוספים בכל שירותי אחסון אחרים, כמו Google Cloud Firestore.
בפעם הראשונה שמשתמש נרשם לאפליקציה, נתוני הפרופיל שלו מאוכלסים באמצעות המידע הזמין:
- אם המשתמש נרשם עם כתובת אימייל וסיסמה, רק החשבון הראשי המאפיין של כתובת האימייל מאוכלס
- אם המשתמש נרשם באמצעות ספק זהויות של איחוד שירותי אימות הזהות, כמו Google או Facebook, פרטי החשבון שהספק מספקים משמשים לאכלס את הפרופיל של המשתמש
- אם המשתמש נרשם באמצעות מערכת האימות המותאמת אישית, צריך להוסיף באופן מפורש המידע שאתם רוצים לפרופיל המשתמש
אחרי שיוצרים חשבון משתמש, אפשר לטעון מחדש את הפרטים של המשתמש כדי לכלול שינויים שהמשתמש ביצע במכשיר אחר.
ספקי כניסה
אתם יכולים לאפשר למשתמשים להיכנס לאפליקציות שלכם בכמה שיטות: כתובת אימייל וסיסמה, ספקי זהויות מאוחדים ומערכת האימות בהתאמה אישית. אפשר לשייך למשתמש יותר משיטת כניסה אחת: לדוגמה, משתמש יכול להיכנס לאותו חשבון באמצעות כתובת אימייל וסיסמה, או באמצעות כניסה באמצעות חשבון Google.
המופעים של המשתמשים עוקבים אחרי כל ספק שמקושר למשתמש. כך אפשר כדי לעדכן מאפייני פרופיל ריקים באמצעות המידע שסופק על ידי ספק. למידע על 'ניהול משתמשים' (iOS, Android, אתר).
המשתמש הנוכחי
כאשר משתמש נרשם או נכנס, הוא הופך למשתמש הנוכחי מופע אימות. המופע שומר על מצב המשתמש, כך שרענון (בדפדפן) או הפעלה מחדש של האפליקציה לא מאבדים את מידע.
כשהמשתמש יוצא מהחשבון, מופע האימות מפסיק לשמור הפניה למשתמש. ולא עומד יותר במצב שלו. אין משתמש נוכחי. אבל, המופע של המשתמש ממשיך להיות פעיל באופן מלא: אם שומרים הפניה עדיין אפשר לגשת לנתוני המשתמש ולעדכן אותם.
מחזור החיים של המשתמש
הדרך המומלצת למעקב אחרי המצב הנוכחי של מכונת האימות היא באמצעות מאזינים (נקראים גם "צופים" ב-JavaScript). מאזין של Auth מקבל התראה בכל פעם שמשהו רלוונטי קורה לאובייקט Auth. להצגת הניהול משתמשים (iOS, Android, אתר).
אוזן Auth מקבל התראות במצבים הבאים:
- האתחול של אובייקט Auth מסתיים ומשתמש כבר נכנס לחשבון סשן קודם, או שהופנתה באופן אוטומטי מכניסה של ספק זהויות זרימה
- משתמש נכנס לחשבון (המשתמש הנוכחי מוגדר)
- משתמש יוצא מהחשבון (המשתמש הנוכחי הופך ל-null)
- אסימון הגישה של המשתמש הנוכחי עובר רענון. מקרה כזה יכול להתרחש
את התנאים הבאים:
- התוקף של אסימון הגישה פג: זהו מצב נפוץ. אסימון הרענון הוא ששימשו לקבלת קבוצה חוקית חדשה של אסימונים.
- המשתמש משנה את הסיסמה: Firebase מנפיק גישה חדשה ואסימוני רענון ועיבוד האסימונים הישנים שהתוקף שלהם פג. הפעולה הזו מתבצעת באופן אוטומטי שהתוקף של האסימון של המשתמש יפוג ו/או יבצע יציאה מהחשבון של המשתמש בכל מכשיר, מטעמי אבטחה.
- המשתמש מבצע אימות מחדש: פעולות מסוימות מחייבות את פרטי כניסה שהונפקו לאחרונה, פעולות כאלה כוללות מחיקת חשבון, הגדרת כתובת אימייל ראשית ושינוי סיסמה. במקום לנתק את המשתמש ואז להיכנס שוב למשתמש, לקבל גישה של המשתמש, ולהעביר את פרטי הכניסה החדשים אימות מחדש של אובייקט המשתמש.
שירות עצמי של משתמש
כברירת מחדל, Firebase מאפשר למשתמשים להירשם ולמחוק את החשבונות שלהם ללא התערבות ניהולית. במקרים רבים, הפעולות האלה מאפשרות עבור משתמשי הקצה לגלות את האפליקציה או השירות שלכם ולהצטרף (או להפסיק) עם חיכוך מינימלי.
עם זאת, יש מצבים שבהם רוצים שהמשתמשים ייוצרו באופן ידני או פרוגרמטי על ידי אדמין, באמצעות Admin SDK או מסוף Firebase. במקרים כאלה, אפשר להשבית את הפעולות של המשתמשים מתוך הגדרות Firebase Authentication שמונע ממשתמשי הקצה ליצור ולמחוק חשבונות. אם משתמשים בריבוי דיירים, צריך לשלוח בקשת HTTP כדי להשבית את התכונות האלה לכל דייר (tenant).
אם משתמש קצה מנסה ליצור או למחוק חשבון בתוך המערכת שלך,
השירות Firebase יחזיר קוד שגיאה:
auth/admin-restricted-operation לקריאות ל-Web API או ERROR_ADMIN_RESTRICTED_OPERATION ל-Android ול-iOS. עליך לעשות זאת בצורה חיננית
תטפל בשגיאה בקצה הקדמי באמצעות בקשה מהמשתמש לבצע את
פעולות לשירות שלך.
אסימוני אימות
כשמבצעים אימות באמצעות Firebase, יש שלושה סוגים סוגים של אסימוני אימות שאתם עשויים להיתקל בהם:
| Firebase אסימונים מזהים | נוצר על ידי Firebase כשמשתמש נכנס לאפליקציה. האלה הם אסימונים JWT חתומים שמזהים באופן מאובטח משתמש פרויקט אחד (Firebase). האסימונים האלה מכילים פרטי פרופיל בסיסיים כולל מחרוזת הזיהוי של המשתמש, הייחודית פרויקט אחד (Firebase). כי התקינות של אסימונים מזהים אפשר לאמת אותם, אפשר לשלוח אותם לשרת עורפי כדי לזהות המשתמש שמחובר כרגע. |
| אסימונים של ספקי זהויות | נוצר על ידי ספקי זהויות מאוחדים, כמו Google ו-Facebook. לאסימונים האלה יכולים להיות פורמטים שונים, אבל בדרך כלל הם אסימוני גישה מסוג OAuth 2.0. אפליקציות משתמשות באסימונים האלה כדי לאמת שהמשתמשים עברו בהצלחה מאומתים עם ספק הזהויות, ואז ממירים אותם פרטי הכניסה שניתנים לשימוש על ידי שירותי Firebase. |
| Firebase אסימונים מותאמים אישית | נוצרה על ידי מערכת האימות המותאמת אישית כדי לאפשר למשתמשים להיכנס לאפליקציה באמצעות מערכת האימות שלך. אסימונים בהתאמה אישית הם אסימונים JWT נחתם באמצעות מפתח פרטי של חשבון שירות. האפליקציות משתמשות באסימונים האלה באופן דומה לאופן שבו הן משתמשות באסימונים שמוחזרים מספקי זהויות מאוחדים. |
כתובות אימייל מאומתות
Firebase מחשיב כתובת אימייל כמאומתת אם היא עומדת בשני תנאים:
- המשתמש משלים את תהליך האימות של Firebase
- האימייל מאומת על ידי ספק זהויות מהימן, או IdP, בקיצור.
לא מהימנים ספקי IdP שמאמתים את כתובת האימייל פעם אחת, אבל מאפשרים למשתמשים לשנות את כתובות האימייל בלי לדרוש אימות מחדש. מזהי IdP שהם הבעלים של הדומיין או שנדרשים להם תמיד אימות נחשבים כמהימנים.
ספקים מהימנים:
- Google (לכתובות @gmail.com)
- Yahoo! (לכתובות עם הסיומת @yahoo.com)
- Microsoft (לכתובות @outlook.com ו- @hotmail.com)
- Apple (תמיד מאומת, כי החשבונות תמיד מאומתים ומאומתים על ידי גורמים מרובים)
ספקים לא מהימנים:
- GitHub
- Google, Yahoo ו-Microsoft לדומיינים שלא הונפקו על ידי ספק הזהויות הזה
- אימייל / סיסמה ללא אימות אימייל
במצבים מסוימים, Firebase יקשר בין החשבונות באופן אוטומטי כאשר משתמש ייכנס לספקים שונים באמצעות אותה כתובת אימייל. עם זאת, מצב זה עשוי להתרחש רק כאשר עומדים בקריטריונים מסוימים. כדי להבין את הסיבה לכך, כדאי לקחת בחשבון את המצב הבא: משתמש נכנס באמצעות חשבון Google עם חשבון @gmail.com, וגורם זדוני יוצר חשבון באמצעות אותה כתובת @gmail.com, אבל נכנס דרך Facebook. אם שני החשבונות האלה קושרו באופן אוטומטי, הגורם הזדוני יקבל גישה לחשבונות של המשתמש.
בתרחישים הבאים מתוארים המקרים שבהם אנחנו מקשרים חשבונות באופן אוטומטי ומקרים שבהם אנחנו זורקים הודעת שגיאה שמחייבת פעולה מצד המשתמש או המפתח:
- המשתמש נכנס לחשבון בעזרת ספק לא מהימן, ואז נכנס דרך ספק לא מהימן אחר באמצעות אותו אימייל (לדוגמה: Facebook ואחריו GitHub). תופיע שגיאה עם דרישה לקישור החשבון.
- המשתמש נכנס לחשבון בעזרת ספק מהימן, ואז נכנס באמצעות אותו אימייל של ספק לא מהימן (לדוגמה: Google ואחריה Facebook). הפעולה הזו גורמת לשגיאה שדורשת קישור חשבון.
- המשתמש נכנס לחשבון בעזרת ספק לא מהימן, ואז נכנס אצל ספק מהימן באמצעות אותו אימייל (לדוגמה: Facebook ואחריה Google). הספק המהימן מחליף את הספק הלא מהימן. אם המשתמש ינסה להיכנס שוב באמצעות Facebook, תופיע שגיאה עם דרישה לקשר את החשבון.
- המשתמש נכנס באמצעות ספק מהימן, ואז נכנס באמצעות ספק מהימן אחר עם אותה כתובת אימייל (לדוגמה, Apple ואז Google). שני הספקים יקושרו ללא שגיאות.
אפשר להגדיר הודעת אימייל כמאומתת באופן ידני באמצעות Admin SDK, אבל מומלץ לעשות זאת רק אם ידוע לך שהמשתמש באמת הבעלים של האימייל.