הגרסה החדשה ביותר של Google Identity Toolkit שוחררה בתור Identity Platform ואימות ב-Firebase. מעכשיו והלאה, העבודה על תכונות ב-Identity Toolkit תוקפא. כל הפיתוח של תכונות חדשות יתבצע ב-Identity Platform וב-Firebase Authentication. אנחנו ממליצים למפתחים של Identity Toolkit לעבור לפלטפורמות האלה ברגע שזה מעשי לאפליקציות שלהם.
תכונות חדשות
כבר יש בפלטפורמת Identity Platform שיפורים משמעותיים בתכונות בהשוואה ל-Google Identity Toolkit:
מסוף Admin חדש
ל-Identity Platform יש מסוף חדש למפתחים שמאפשר להציג, לשנות ולמחוק משתמשים. המסוף הזה יכול לעזור בניפוי באגים בתהליכי הכניסה וההרשמה. במסוף אפשר גם להגדיר שיטות אימות ולהתאים אישית תבניות אימייל.
שיטות אימות חדשות
ב-Identity Platform יש תמיכה בתקני איחוד ארגוניים, כמו SAML ו-OIDC, שמאפשרים להתאים את האפליקציות והשירותים של SaaS לעומס. ב-Identity Platform יש גם תמיכה בספקי שירותים כמו GitHub, Microsoft, Yahoo ועוד. אתם יכולים להשתמש בכניסה אנונימית כדי ליצור מזהה משתמש ייחודי בלי לחייב את המשתמש לעבור תהליך כניסה או הרשמה. כך תוכלו לבצע קריאות API מאומתות כמו שאתם עושים עם משתמש רגיל. כשהמשתמש מחליט להירשם לחשבון, כל הפעילות נשמרת עם אותו מזהה משתמש. האפשרות הזו שימושית בתרחישים כמו עגלות קניות בצד השרת או אפליקציות אחרות שבהן רוצים לעורר עניין בקרב המשתמשים לפני ששולחים אותם לתהליך ההרשמה.
התאמה לעומס בביטחון בעזרת הסכמי רמת שירות ותמיכה ב-Cloud
Identity Platform מבוסס על תשתית מהימנה של Google, ומספק הסכמי רמת שירות ותמיכה מ-Google Cloud. המשמעות היא שתוכלו להרחיב את השירות בביטחון, ולהסתמך על Google כדי לספק את העמידות, הזמינות והתאימות לעומס (scalability) שאתם צריכים.
גישה לכל Firebase
Firebase היא פלטפורמה לנייד שעוזרת לכם לפתח במהירות אפליקציות באיכות גבוהה, להגדיל את בסיס המשתמשים ולהרוויח יותר כסף. Firebase מורכב מתכונות משלימות שאפשר לשלב לפי הצורך, והוא כולל תשתית לניתוח נתונים בנייד, להעברת הודעות בענן, למסדי נתונים בזמן אמת, לאחסון קבצים, לאירוח סטטי, להגדרה מרחוק, לדוחות על קריסות בנייד ולבדיקות ל-Android.
ממשקי משתמש מעודכנים
בנינו מחדש את תהליכי ממשק המשתמש על סמך מחקרי ה-UX העדכניים ביותר של Google. התהליכים האלה כוללים שחזור סיסמה, קישור חשבונות ותהליכים חדשים או קיימים להסרת עמימות של חשבונות, שלרוב נדרשת להם זמן רב כדי לכתוב את הקוד ולפתור באגים. הוא משלב את Smart Lock לסיסמאות ב-Android, שבעקבותיו חלה עלייה משמעותית בהמרות של כניסה ושל הרשמה באפליקציות שמשתתפות בתוכנית. הוא תומך גם בשינויים קלים בעיצוב כדי להתאים לאפליקציה שלכם, וכדי לאפשר התאמה אישית מקסימלית, הגרסאות ל-Android ול-iOS הן בקוד פתוח.
הגדרת שרת פשוטה יותר
ב-Identity Toolkit, ראינו שמפתחים רבים בחרו לא ליישם את תהליך השחזור באימייל, וכתוצאה מכך המשתמשים שלהם לא יכלו לשחזר את החשבונות שלהם אם שכחו את הסיסמה. באמצעות Identity Platform אפשר לשלוח למשתמשים הודעות אימות באימייל, הודעות על איפוס סיסמה ועל שינוי סיסמה, ואפשר להתאים אישית את הטקסט בקלות. בנוסף, כבר לא צריך לארח את ווידג'טים של ממשק המשתמש כדי לארח הפניות אוטומטיות ולהשלים פעולות של שינוי סיסמה.
ערכות SDK חדשות
כל ממשקי ה-API של השרתים של Identity Toolkit זמינים עכשיו באופן מקורי בכל אחת מספריות הלקוח שלנו (Android, iOS, אינטרנט). המפתחים יוכלו להיכנס לחשבון ולרשום משתמשים חדשים וישנים, לגשת לנכסי משתמשים, לקשר חשבונות, לעדכן אותם ולמחוק אותם, לאפס סיסמאות ועוד, בלי להיות קשורים לממשק משתמש קבוע. אם אתם מעדיפים, תוכלו ליצור בעצמכם את תהליך הכניסה ואת חוויית הכניסה המלאה על גבי ה-API הזה.
ניהול סשנים באפליקציות לנייד
באמצעות Identity Toolkit, האפליקציות יצרו מצב סשן משלהם על סמך אירוע האימות הראשוני מ-Identity Toolkit. Identity Platform משתמשת בשירות לקצה העורפי שמקבל אסימון רענון, שנוצר מאירוע האימות, ומחליף אותו באסימוני גישה לטווח שעה ל-Android, ל-iOS ול-JavaScript. כשמשתמש משנה את הסיסמה שלו, אסימוני הרענון לא יוכלו יותר ליצור אסימוני גישה חדשים, וכך משביתים את הגישה עד שהמשתמש יבצע אימות מחדש במכשיר הזה.
הבדלים בין התכונות
חלק מהתכונות של Identity Toolkit לא זמינות כרגע ב-Identity Platform, וחלק מהתכונות עוצבו מחדש ופועלות בצורה שונה. אם התכונות האלה חשובות לאפליקציה שלכם, תוכלו לבחור לא לבצע את ההעברה באופן מיידי. במקרים רבים, יכול להיות שהתכונות האלה לא חשובות לאפליקציה שלכם או שיש חלופות פשוטות שיאפשרו לכם להמשיך בהעברה.
הבדלים בצד השרת
שירות הליבה של Identity Toolkit, עם ממשקי ה-API ל-REST, הלוגיקה לאימות החשבון ומסד הנתונים הראשי של המשתמשים, עברו עדכונים קלים בלבד. עם זאת, חלק מהתכונות והאופן שבו משלבים את Identity Platform בשירות השתנו.
ספקי זהויות
אין תמיכה ב-PayPal וב-AOL. משתמשים שיש להם חשבונות ב-IdPs האלה עדיין יוכלו להיכנס לאפליקציה שלכם באמצעות תהליך שחזור הסיסמה ולהגדיר סיסמה לחשבון שלהם.
ספריות שרת
נכון לעכשיו, יש ערכות Admin SDK זמינות ל-Java, ל-Node.js, ל-Python, ל-Go ול-C#.
אימיילים לניהול החשבון
אפשר לבצע את הפעולות הבאות באמצעות Firebase או דרך שרת האימייל של המפתח: איפוס סיסמה, אימות אימייל והודעות על שינוי כתובת אימייל. בשלב זה, אפשר לבצע התאמה אישית מוגבלת של תבניות האימייל דרך ממשק המשתמש, אבל אפשר לבצע התאמה אישית נוספת באמצעות ערכות ה-SDK לניהול.
אישור שינוי כתובת האימייל
ב-Identity Toolkit, כשמשתמש מחליט לשנות את כתובת האימייל שלו, נשלחת לכתובת החדשה הודעת אימייל עם קישור להמשך תהליך שינוי כתובת האימייל.
מערכת Firebase מאשרת את שינוי כתובת האימייל על ידי שליחת הודעת אימייל עם ביטול לכתובת האימייל הישנה, עם קישור להחזרת השינוי.
השקה של IDP
ב-Identity Toolkit הייתה אפשרות להוסיף ספקי זהויות למערכת הכניסה בהדרגה, כדי שתוכלו להתנסות בהשפעה על בקשות התמיכה. התכונה הזו הוסרה מאימות ב-Firebase.
הבדלים בצד הלקוח
ב-Identity Platform, התכונות ש-Google Identity Toolkit מספק מחולקות לשני רכיבים:
ערכות SDK ללקוח ולשרת
ב-Identity Platform, הפונקציונליות שסופקו על ידי ה-API ל-REST של Identity Toolkit ארוזה ב-SDK של לקוחות שזמין ל-Android, ל-iOS ול-JavaScript. אפשר להשתמש ב-SDK כדי להתחבר ולרשום משתמשים, לגשת למידע בפרופיל המשתמש, לקשר, לעדכן ולמחוק חשבונות ולאפס סיסמאות באמצעות ה-SDK של הלקוח, במקום לתקשר עם שירות הקצה העורפי באמצעות קריאות REST.
UI Widget
כל תהליכי ממשק המשתמש שמנהלים את הכניסה, ההרשמה, שחזור הסיסמה וקישור החשבון נבנו מחדש באמצעות ערכות ה-SDK ללקוח וארזו כווידג'ט כניסה. הן זמינות כערכות SDK בקוד פתוח ל-iOS, ל-Android ול-אינטרנט, ומאפשרות להתאים אישית את התהליכים באופן שלא ניתן לעשות באמצעות Identity Toolkit.
הבדלים נוספים כוללים:
סשנים והעברה
מכיוון שהסשנים מנוהלים באופן שונה ב-Identity Toolkit וב-Identity Platform, הסשנים הקיימים של המשתמשים יופסקו אחרי שתשדרגו את ה-SDK, והמשתמשים יצטרכו להיכנס שוב.
לפני שמתחילים
כדי שתוכלו לעבור מ-Identity Toolkit ל-Identity Platform, עליכם:
פותחים את מסוף Cloud ובוחרים את הפרויקט של Identity Toolkit.
ב-Marketplace, עוברים אל Identity Platform ובוחרים באפשרות 'Enable Identity Platform' (הפעלת Identity Platform).
פותחים את הדף Service accounts. כאן תוכלו לראות את חשבון השירות שהגדרתם בעבר ל-Identity Toolkit.
לצד חשבון השירות, לוחצים על more_vert > Create key. לאחר מכן, בתיבת הדו-שיח Create private key, מגדירים את סוג המפתח כ-JSON ולוחצים על Create. קובץ JSON שמכיל את פרטי הכניסה של חשבון השירות שלכם יורד. תצטרכו את המפתח הזה כדי לאתחל את ה-SDK בשלב הבא.
חוזרים למסוף Cloud. בקטע 'ספקים', בתוך שיטת הכניסה 'אימייל/סיסמה', פותחים את הדף תבניות אימייל. לאחר מכן תוכלו להתאים אישית את התבניות של האפליקציה.
ב-Identity Toolkit, כשמשתמשים איפסו סיסמאות, שינו כתובות אימייל או אימתו את כתובות האימייל שלהם, צריך היה לקבל קוד OOB משרת Identity Toolkit ולאחר מכן לשלוח את הקוד למשתמשים באימייל. פלטפורמת Identity Platform שולחת אימיילים על סמך התבניות שאתם מגדירים, בלי צורך לבצע פעולות נוספות.
אופציונלי: אם אתם צריכים לגשת לשירותי Identity Platform בשרת, צריך להתקין את Firebase SDK.
אפשר להתקין את Node.js Admin SDK באמצעות
npm
:$ npm init $ npm install --save firebase-admin
בקוד, אפשר לגשת ל-Firebase באמצעות:
var admin = require('firebase-admin'); var app = admin.initializeApp({ credential: admin.credential.cert('path/to/serviceAccountCredentials.json') });
בשלב הבא, מבצעים את שלבי ההעברה לפלטפורמה של האפליקציה: Android, iOS, אינטרנט.
שרתים ו-JavaScript
שינויים בולטים
יש כמה הבדלים נוספים בהטמעה באינטרנט של Identity Platform בהשוואה ל-Identity Toolkit.
ניהול סשנים באינטרנט
בעבר, כשמשתמש ביצע אימות באמצעות ווידג'ט של Identity Toolkit, הוגדר לו קובץ cookie ששימש להפעלת הסשן. ל-cookie הזה היה משך חיים של שבועיים, והוא שימש כדי לאפשר למשתמש להשתמש בווידג'ט לניהול החשבון כדי לשנות את הסיסמה וכתובת האימייל. בחלק מהאתרים נעשה שימוש בקובץ ה-cookie הזה כדי לאמת את כל שאר הבקשות לדפים באתר. אתרים אחרים השתמשו בקובץ ה-cookie כדי ליצור קובצי cookie משלהם באמצעות מערכת ניהול קובצי ה-cookie של המסגרת שלהם.
ערכות ה-SDK של לקוחות Identity Platform מנהלות עכשיו אסימוני מזהה ופועלות עם הקצה העורפי של Identity Platform כדי לשמור על עדכניות הסשן. תוקף הסשנים בצד העורפי פג כשמתרחשים שינויים חשובים בחשבון (למשל, שינויים בסיסמה של משתמשים). אסימוני מזהה לא מוגדרים באופן אוטומטי כקובצי cookie בלקוח האינטרנט, ומשך החיים שלהם הוא שעה בלבד. אלא אם אתם רוצים סשנים של שעה בלבד, לא כדאי להשתמש באסימוני מזהה בתור קובץ ה-cookie לאימות כל בקשות הדפים. במקום זאת, תצטרכו להגדיר מאזין לזמן הכניסה של המשתמש, לקבל את אסימון המזהה, לאמת את האסימון וליצור קובץ cookie משלכם באמצעות מערכת ניהול קובצי ה-cookie של המסגרת.
תצטרכו להגדיר את משך החיים של הסשן של קובץ ה-cookie בהתאם לצורכי האבטחה של האפליקציה.
תהליך הכניסה לאינטרנט
בעבר, המשתמשים הופנו אוטומטית אל
accountchooser.com
כשהם ניסו להיכנס לחשבון, כדי לברר באיזה מזהה הם רוצים להשתמש. תהליך ממשק המשתמש של Identity Platform מתחיל עכשיו ברשימת שיטות כניסה, כולל אפשרות אימייל שמעבירה את המשתמש אלaccountchooser.com
לאינטרנט ומשתמשת ב-hintRequest API ב-Android. בנוסף, כתובות אימייל כבר לא נדרשות בממשק המשתמש. כך יהיה קל יותר לתמוך במשתמשים אנונימיים, במשתמשים עם אימות מותאם אישית או במשתמשים מספקים שבהם לא נדרשות כתובות אימייל.ווידג'ט לניהול החשבון
הווידג'ט הזה מספק ממשק משתמש שמאפשר למשתמשים לשנות כתובות אימייל, לשנות סיסמאות או לבטל את הקישור של החשבונות שלהם לספקי זהויות. התכונה הזו נמצאת כרגע בפיתוח.
לחצן/ווידג'ט כניסה
ווידג'טים כמו לחצן הכניסה וכרטיס המשתמש לא זמינים יותר. אפשר ליצור אותם בקלות רבה באמצעות Firebase Authentication API.
No signOutUrl
תצטרכו להתקשר למספר
firebase.auth.signOut()
ולטפל בקריאה החוזרת.No oobActionUrl
שליחת האימיילים מטופלת עכשיו על ידי Identity Platform ומוגדר במסוף Firebase.
התאמה אישית של CSS
הווידג'ט של ממשק המשתמש משתמש בסגנון Material Design Lite, שמוסיף אנימציות של Material Design באופן דינמי.
שלב 1: שינוי קוד השרת
אם השרת שלכם מסתמך על אסימון של Identity Toolkit (תקף למשך שבועיים) כדי לנהל סשנים של משתמשי אינטרנט, תצטרכו להמיר את השרת כך שישתמש בקובץ cookie משלו לסשנים.
- מטמיעים נקודת קצה לאימות אסימון המזהה ולהגדרת קובץ ה-cookie הזמני של המשתמש. אפליקציית הלקוח שולחת את אסימון המזהה של Firebase לנקודת הקצה הזו.
- אם הבקשה הנכנסת מכילה את קובץ ה-cookie של הסשן שלכם, תוכלו להתייחס למשתמש כאל משתמש מאומת. אחרת, הבקשה נחשבת כבקשה לא מאומתת.
- אם אתם לא רוצים שהמשתמשים שלכם יאבדו את הסשנים הקיימים שלהם בחשבון, עליכם להמתין שבועיים עד שתוקף כל האסימונים של Identity Toolkit יפוג, או לבצע גם אימות של שני האסימונים באפליקציית האינטרנט, כפי שמתואר בהמשך בשלב 3.
לאחר מכן, מכיוון שאסימונים מזהים שונים מאסימונים של Identity Toolkit, צריך לעדכן את הלוגיקה של אימות האסימונים. מתקינים את Admin SDK בשרת. אם אתם משתמשים בשפה שלא נתמכת על ידי Admin SDK, מורידים ספריית אימות של אסימון JWT לסביבה שלכם ומאמתים את האסימון בצורה נכונה.
אחרי ביצוע העדכונים שלמעלה, יכול להיות שעדיין יהיו לכם נתיבים של קוד שמסתמכים על אסימונים של Identity Toolkit. אם יש לכם אפליקציות ל-iOS או ל-Android, המשתמשים יצטרכו לשדרג לגרסה החדשה של האפליקציה כדי שנתיבי הקוד החדשים יפעלו. אם אתם לא רוצים לאלץ את המשתמשים לעדכן את האפליקציה, תוכלו להוסיף לוגיקה נוספת לאימות השרת שבודקת את האסימון ומחליטה אם צריך להשתמש ב-Firebase SDK או ב-Identity Toolkit SDK כדי לאמת את האסימון. אם יש לכם רק אפליקציית אינטרנט, כל בקשות האימות החדשות יועברו ל-Identity Platform, ולכן תצטרכו להשתמש רק בשיטות האימות של אסימון מזהה.
שלב 2: מעדכנים את ה-HTML
מוסיפים את קוד האתחול לאפליקציה:
- פותחים את הפרויקט במסוף Cloud.
- בדף providers, לוחצים על Application Setup Details. יוצג קטע קוד שמפעיל את Identity Platform.
- מעתיקים ומדביקים את קטע הקוד להפעלה בדף האינטרנט.
מוסיפים את ווידג'ט האימות לאפליקציה:
<script src="https://www.gstatic.com/firebasejs/ui/live/0.4/firebase-ui-auth.js"></script> <link type="text/css" rel="stylesheet" href="https://www.gstatic.com/firebasejs/ui/live/0.4/firebase-ui-auth.css" /> <!-- ******************************************************************************************* * TODO(DEVELOPER): Paste the initialization snippet from: * Firebase Console > Overview > Add Firebase to your web app. * ***************************************************************************************** --> <script type="text/javascript"> // FirebaseUI config. var uiConfig = { 'signInSuccessUrl': '<url-to-redirect-to-on-success>', 'signInOptions': [ // Leave the lines as is for the providers you want to offer your users. firebase.auth.GoogleAuthProvider.PROVIDER_ID, firebase.auth.FacebookAuthProvider.PROVIDER_ID, firebase.auth.TwitterAuthProvider.PROVIDER_ID, firebase.auth.GithubAuthProvider.PROVIDER_ID, firebase.auth.EmailAuthProvider.PROVIDER_ID ], // Terms of service url. 'tosUrl': '<your-tos-url>', }; // Initialize the FirebaseUI Widget using Firebase. var ui = new firebaseui.auth.AuthUI(firebase.auth()); // The start method will wait until the DOM is loaded. ui.start('#firebaseui-auth-container', uiConfig); </script>
מסירים את Identity Toolkit SDK מהאפליקציה.
אם השתמשתם באסימון המזהה של Identity Toolkit לניהול סשנים, עליכם לבצע את השינויים הבאים בצד הלקוח:
אחרי שנכנסים לחשבון באמצעות Identity Platform, צריך לקרוא ל-
firebase.auth().currentUser.getToken()
כדי לקבל אסימון מזהה.שולחים את אסימון המזהה לשרת הקצה העורפי, מאמתים אותו ומנפקים קובץ cookie משלכם של סשן.
אל תסתמכו רק על קובץ ה-cookie של הסשן כשאתם מבצעים פעולות רגישות או שולחים לשרת בקשות עריכה מאומתות. תצטרכו לספק הגנה נוספת מפני זיוף בקשות בין אתרים (CSRF).
אם המסגרת לא מספקת הגנה מפני CSRF, אחת מהדרכים למנוע התקפה היא לקבל אסימון מזהה של המשתמש שמחובר באמצעות
getToken()
ולכלול את האסימון בכל בקשה (קובץ ה-cookie של הסשן יישלח גם הוא כברירת מחדל). לאחר מכן, צריך לאמת את האסימון באמצעות Admin SDK, בנוסף לבדיקת קובץ ה-cookie של הסשן שהשלימה מסגרת הקצה העורפי. כך יהיה קשה יותר לבצע התקפות CSRF, כי אסימון המזהה נשמר רק באמצעות אחסון באינטרנט, אף פעם בקובץ cookie.אסימונים של Identity Toolkit תקפים למשך שבועיים. מומלץ להמשיך להנפיק אסימונים לתקופה של שבועיים, או להאריך או לקצר את התקופה הזו בהתאם לדרישות האבטחה של האפליקציה. כשמשתמש יוצא מהחשבון, צריך למחוק את קובץ ה-cookie של הסשן.
שלב 3: מעדכנים את כתובות ה-URL להפניה אוטומטית של ה-IdP
במסוף Cloud, פותחים את הקטע Providers.
לכל ספק כניסה מאוחד שאתם תומכים בו, מבצעים את הפעולות הבאות:
- לוחצים על השם של ספק הכניסה.
- מעתיקים את ה-URI של ההפניה האוטומטית ב-OAuth.
- במסוף הפיתוח של ספק הכניסה, מעדכנים את ה-URI של ההפניה האוטומטית ב-OAuth.
Android
שלב 1: מוסיפים את Identity Platform לאפליקציה באמצעות Firebase
פותחים את מסוף Cloud ובוחרים את הפרויקט ב-Identity Toolkit.
בדף Providers (ספקים), לוחצים על Application setup details (פרטי הגדרת האפליקציה), בוחרים בכרטיסייה Android ואז לוחצים על Get Started in Firebase (תחילת העבודה ב-Firebase). בתיבת הדו-שיח Add Firebase, מזינים את שם החבילה ואת טביעת האצבע של אישור החתימה של האפליקציה ולוחצים על Add App. לאחר מכן, קובץ התצורה
google-services.json
מוריד למחשב.מעתיקים את קובץ התצורה לתיקיית השורש של מודול האפליקציה ל-Android. קובץ התצורה הזה מכיל פרטים על הפרויקט ועל לקוח OAuth של Google.
בקובץ
build.gradle
ברמת הפרויקט (<var>your-project</var>/build.gradle
), מציינים את שם החבילה של האפליקציה בקטעdefaultConfig
:defaultConfig { ….. applicationId "com.your-app" }
בנוסף, בקובץ
build.gradle
ברמת הפרויקט, מוסיפים תלות שכוללת את הפלאגין google-services:buildscript { dependencies { // Add this line classpath 'com.google.gms:google-services:3.0.0' } }
בקובץ
build.gradle
ברמת האפליקציה (<var>my-project</var>/<var>app-module</var>/build.gradle
), מוסיפים את השורה הבאה אחרי הפלאגין של Android Gradle כדי להפעיל את הפלאגין google-services:apply plugin: 'com.android.application' // Add this line apply plugin: 'com.google.gms.google-services'
הפלאגין google-services משתמש בקובץ
google-services.json
כדי להגדיר את האפליקציה לשימוש ב-Firebase.בנוסף, בקובץ
build.gradle
ברמת האפליקציה, מוסיפים את התלות באימות ב-Firebase:compile 'com.google.firebase:firebase-auth:23.1.0' compile 'com.google.android.gms:play-services-auth:21.3.0'
שלב 2: מסירים את Identity Toolkit SDK
- מסירים את ההגדרה של Identity Toolkit מהקובץ
AndroidManifest.xml
. המידע הזה נכלל בקובץgoogle-service.json
ומשוחרר על ידי הפלאגין google-services. - מסירים את Identity Toolkit SDK מהאפליקציה.
שלב 3: מוסיפים את FirebaseUI לאפליקציה
מוסיפים לאפליקציה את FirebaseUI Auth.
באפליקציה, מחליפים את הקריאות ל-Identity Toolkit SDK בקריאות ל-FirebaseUI.
iOS
שלב 1: מוסיפים את Firebase לאפליקציה
מוסיפים את ה-SDK של הלקוח לאפליקציה על ידי הפעלת הפקודות הבאות:
$ cd your-project directory $ pod init $ pod 'Firebase'
פותחים את מסוף Cloud ובוחרים את הפרויקט ב-Identity Toolkit.
בדף Providers (ספקים), לוחצים על Application setup details (פרטי הגדרת האפליקציה), בוחרים בכרטיסייה iOS ואז לוחצים על Get Started in Firebase (תחילת העבודה ב-Firebase). בתיבת הדו-שיח Add Firebase, מזינים את שם החבילה ואת טביעת האצבע של אישור החתימה של האפליקציה ולוחצים על Add App. לאחר מכן, קובץ התצורה
google-services.json
יורד למחשב. בתיבת הדו-שיח Add Firebase (הוספת Firebase), מזינים את מזהה החבילה ואת מזהה App Store של האפליקציה ולוחצים על Add App (הוספת אפליקציה). לאחר מכן, קובץ התצורהGoogleService-Info.plist
יוריד למחשב. אם יש לכם כמה מזהי חבילות בפרויקט, כל מזהה חבילה צריך להיות מחובר במסוף Firebase כדי שיהיה לו קובץGoogleService-Info.plist
משלו.מעתיקים את קובץ התצורה לרמה הבסיסית (root) של פרויקט Xcode ומוסיפים אותו לכל יעדי הטרגוט.
שלב 2: הסרת Identity Toolkit SDK
- מסירים את
GoogleIdentityToolkit
מ-Podfile של האפליקציה. - מריצים את הפקודה
pod install
.
שלב 3: מוסיפים את FirebaseUI לאפליקציה
מוסיפים לאפליקציה את FirebaseUI Auth.
באפליקציה, מחליפים את הקריאות ל-Identity Toolkit SDK בקריאות ל-FirebaseUI.