מעבר מערכת הכלים של Google Identity לפלטפורמת Identity Platform של Google Cloud

הגרסה החדשה ביותר של Google Identity Toolkit פורסמה בתור Identity Platform ואימות ב-Firebase. מעכשיו, לא יפותחו תכונות חדשות ב-Identity Toolkit. כל הפיתוח של תכונות חדשות יתבצע ב-Identity Platform ובאימות ב-Firebase. אנחנו ממליצים למפתחים שמשתמשים ב-Identity Toolkit לעבור לפלטפורמות האלה בהקדם האפשרי.

תכונות חדשות

ב-Identity Platform כבר יש שיפורים משמעותיים בתכונות בהשוואה ל-Google Identity Toolkit:

  • מסוף Admin חדש

    ל-Identity Platform יש מסוף מפתחים חדש שמאפשר לכם לראות, לשנות ולמחוק את המשתמשים שלכם. זה יכול לעזור לכם לנפות באגים בתהליכי הכניסה וההרשמה. במסוף אפשר גם להגדיר שיטות אימות ולהתאים אישית תבניות של אימיילים.

  • שיטות אימות חדשות

    ב-Identity Platform יש תמיכה בתקני איחוד ארגוניים, כמו SAML ו-OIDC, שמאפשרים להרחיב את האפליקציות והשירותים של SaaS. ב-Identity Platform יש גם תמיכה בספקים כמו GitHub, ‏Microsoft, ‏Yahoo ועוד. אתם יכולים להשתמש בכניסה אנונימית כדי ליצור מזהה משתמש ייחודי בלי לדרוש מהמשתמש לעבור תהליך כניסה או הרשמה. כך תוכלו לבצע קריאות מאומתות ל-API כמו עם משתמש רגיל. כשהמשתמש מחליט להירשם לחשבון, כל הפעילות נשמרת עם אותו מזהה משתמש. האפשרות הזו שימושית בתרחישים כמו עגלות קניות בצד השרת או אפליקציות אחרות שבהן רוצים לעורר עניין אצל המשתמש לפני ששולחים אותו לתהליך ההרשמה.

  • הרחבת הפעילות בראש שקט בעזרת הסכמי רמת שירות (SLA) ותמיכה ב-Cloud

    פלטפורמת Identity Platform מבוססת על התשתית המהימנה של Google, ומספקת הסכמי רמת שירות (SLA) ותמיכה מ-Google Cloud. זה אומר שאתם יכולים להרחיב את השירות שלכם בביטחון, ולהסתמך על Google שתספק את העמידות, הזמינות והמדרגיות שאתם צריכים.

  • גישה לכל 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. משתמשים עם חשבונות מספקי הזהויות האלה עדיין יכולים להיכנס לאפליקציה באמצעות תהליך שחזור הסיסמה ולהגדיר סיסמה לחשבון שלהם.

  • ספריות של שרתים

    כרגע יש 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.

  • ווידג'ט של ממשק המשתמש

    כל תהליכי ממשק המשתמש שמנהלים את הכניסה, ההרשמה, שחזור הסיסמה וקישור החשבון נבנו מחדש באמצעות ערכות ה-SDK של הלקוח ונארזו כווידג'ט התחברות. הן זמינות כערכות SDK בקוד פתוח ל-iOS, ל-Android ול-Web, ומאפשרות לכם להתאים אישית את התהליכים בדרכים שלא אפשריות ב-Identity Toolkit.

הבדלים נוספים:

  • סשנים והעברה

    הסשנים מנוהלים באופן שונה ב-Identity Toolkit וב-Identity Platform, ולכן הסשנים הקיימים של המשתמשים יסתיימו אחרי שדרוג ה-SDK, והמשתמשים יצטרכו להיכנס שוב.

לפני שמתחילים

לפני שמעבירים מ-Identity Toolkit ל-Identity Platform, צריך:

  1. פותחים את מסוף Cloud ובוחרים את הפרויקט ב-Identity Toolkit.

  2. ב-Marketplace, עוברים אל Identity Platform ובוחרים באפשרות Enable Identity Platform.

  3. פותחים את הדף Service accounts. כאן אפשר לראות את חשבון השירות שהגדרתם קודם ל-Identity Toolkit.

  4. ליד חשבון השירות, לוחצים על > Create key. בתיבת הדו-שיח Create private key, מגדירים את סוג המפתח ל-JSON ולוחצים על Create. קובץ JSON שמכיל את פרטי הכניסה של חשבון השירות יורד למחשב. תצטרכו את המזהה הזה כדי להפעיל את ה-SDK בשלב הבא.

  5. חוזרים למסוף Cloud. בקטע Providers, בשיטת התחברות Email/Password, פותחים את הדף Email Templates. אחר כך אתם יכולים להתאים אישית את התבניות של האפליקציה.

    ב-Identity Toolkit, כשמשתמשים איפסו סיסמאות, שינו כתובות אימייל או אימתו את כתובות האימייל שלהם, הייתם צריכים לקבל קוד OOB משרת Identity Toolkit, ואז לשלוח את הקוד למשתמשים באימייל. ‫Identity Platform שולחת אימיילים על סמך התבניות שהגדרתם, בלי שנדרשות פעולות נוספות.

  6. אופציונלי: אם אתם צריכים לגשת לשירותי Identity Platform בשרת, התקינו את Firebase SDK.

    1. אפשר להתקין את ה-SDK לאדמינים ל-Node.js באמצעות npm:

      $ npm init
$ npm install --save firebase-admin

    2. בקוד, אתם יכולים לגשת ל-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 של המסגרת שלהם.

    ערכות ה-SDK של הלקוח ב-Identity Platform מנהלות עכשיו טוקנים של מזהה ופועלות עם הקצה העורפי של Identity Platform כדי לשמור על הסשן עדכני. ה-backend מסיים סשנים כשיש שינויים חשובים בחשבון (כמו שינוי סיסמה של משתמש). טוקנים של מזהים לא מוגדרים באופן אוטומטי כקובצי Cookie בלקוח האינטרנט, והם תקפים רק למשך שעה. אם אתם לא רוצים סשנים של שעה בלבד, טוקנים של מזהים לא מתאימים לשימוש כקובץ ה-cookie לאימות כל הבקשות לדפים. במקום זאת, תצטרכו להגדיר מאזין שיופעל כשהמשתמש יתחבר, לקבל את טוקן המזהה, לאמת את הטוקן וליצור קובץ Cookie משלכם באמצעות מערכת ניהול קובצי ה-Cookie של המסגרת.

    תצטרכו להגדיר את משך הסשן של קובץ ה-Cookie בהתאם לצורכי האבטחה של האפליקציה.

  • תהליך הכניסה לאתר

    בעבר, המשתמשים הופנו אל accountchooser.com כשהכניסה התחילה כדי ללמוד באיזה מזהה המשתמש רצה להשתמש. תהליך ממשק המשתמש של Identity Platform מתחיל עכשיו ברשימה של שיטות התחברות, כולל אפשרות של אימייל שמובילה אל accountchooser.com באינטרנט ומשתמשת ב-hintRequest API ב-Android. בנוסף, כבר לא צריך להזין כתובות אימייל בממשק המשתמש. כך קל יותר לתמוך במשתמשים לא רשומים, במשתמשים עם אימות בהתאמה אישית או במשתמשים מספקים שלא דורשים כתובות אימייל.

  • ווידג'ט לניהול החשבון

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

  • כפתור/ווידג'ט כניסה

    ווידג'טים כמו כפתור הכניסה וכרטיס המשתמש כבר לא זמינים. אפשר ליצור אותם בקלות רבה באמצעות Firebase Authentication API.

  • אין signOutUrl

    צריך לשלוח קריאה אל firebase.auth.signOut() ולטפל בקריאה החוזרת.

  • אין oobActionUrl

    שליחת האימיילים מטופלת עכשיו על ידי Identity Platform ומוגדרת במסוף Firebase.

  • התאמה אישית של CSS

    הווידג'ט של ממשק המשתמש משתמש בעיצוב של Material Design Lite, שמוסיף באופן דינמי אנימציות של Material Design.

‫שלב 1: משנים את קוד השרת

  1. אם השרת שלכם מסתמך על האסימון של Identity Toolkit (תקף לשבועיים) כדי לנהל סשנים של משתמשים באינטרנט, אתם צריכים להמיר את השרת כך שישתמש בקובץ Cookie זמני משלו.

    1. מטמיעים נקודת קצה (endpoint) כדי לאמת את טוקן המזהה ולהגדיר את קובץ ה-Cookie הזמני של המשתמש. אפליקציית הלקוח שולחת את טוקן המזהה של Firebase לנקודת הקצה הזו.
    2. אם הבקשה הנכנסת מכילה קובץ Cookie זמני משלכם, אתם יכולים להניח שהמשתמש מאומת. אחרת, צריך להתייחס לבקשה כלא מאומתת.
    3. אם אתם לא רוצים שהמשתמשים יאבדו את הסשנים הקיימים שלהם, אתם צריכים לחכות שבועיים עד שיפוג התוקף של כל האסימונים של Identity Toolkit, או לבצע אימות כפול של האסימונים באפליקציית האינטרנט, כמו שמתואר בשלב 3 בהמשך.

  2. בשלב הבא, מכיוון שטוקנים של מזהה שונים מאסימונים של Identity Toolkit, צריך לעדכן את לוגיקת האימות של הטוקנים. מתקינים את ה-SDK לאדמינים בשרת. אם אתם משתמשים בשפה שלא נתמכת ב-SDK לאדמינים, אתם צריכים להוריד ספרייה לאימות אסימוני JWT לסביבה שלכם ולאמת את האסימון כמו שצריך.

  3. בפעם הראשונה שתבצעו את העדכונים שלמעלה, יכול להיות שעדיין יהיו לכם נתיבי קוד שמסתמכים על אסימונים של Identity Toolkit. אם יש לכם אפליקציות ל-iOS או ל-Android, המשתמשים יצטרכו לשדרג לגרסה החדשה של האפליקציה כדי שנתיבי הקוד החדשים יפעלו. אם אתם לא רוצים לאלץ את המשתמשים לעדכן את האפליקציה, אתם יכולים להוסיף לוגיקה נוספת לאימות בשרת שבודקת את האסימון וקובעת אם צריך להשתמש ב-Firebase SDK או ב-Identity Toolkit SDK כדי לאמת את האסימון. אם יש לכם רק אפליקציית אינטרנט, כל בקשות האימות החדשות יועברו ל-Identity Platform, ולכן תצטרכו להשתמש רק בשיטות לאימות טוקן של מזהה.

לעיון במאמרי העזרה של Web API

שלב 2: מעדכנים את ה-HTML

  1. מוסיפים את קוד האיניציאליזציה לאפליקציה:

    1. פותחים את הפרויקט במסוף Cloud.
    2. בדף providers, לוחצים על Application Setup Details. מוצג קטע קוד שמפעיל את Identity Platform.
    3. מעתיקים את קטע הקוד של האתחול ומדביקים אותו בדף האינטרנט.

  2. מוסיפים את ווידג'ט האימות לאפליקציה:

    <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>

  3. מסירים את Identity Toolkit SDK מהאפליקציה.

  4. אם הסתמכתם על אסימון המזהה של Identity Toolkit לניהול סשנים, אתם צריכים לבצע את השינויים הבאים בצד הלקוח:

    1. אחרי שנכנסים לחשבון באמצעות Identity Platform, מקבלים טוקן של מזהה באמצעות קריאה ל-firebase.auth().currentUser.getToken().

    2. שולחים את טוקן המזהה לשרת בק-אנד, מאמתים אותו ומנפיקים קובץ Cookie זמני משלכם.

      אל תסתמכו רק על קובץ ה-Cookie הזמני כשאתם מבצעים פעולות רגישות או שולחים בקשות עריכה מאומתות לשרת. תצטרכו לספק הגנה נוספת מפני זיוף בקשות בין אתרים (CSRF).

      אם המסגרת שלכם לא מספקת הגנה מפני CSRF, דרך אחת למנוע מתקפה היא לקבל טוקן של מזהה למשתמש המחובר באמצעות getToken() ולכלול את הטוקן בכל בקשה (קובץ ה-Cookie של הסשן יישלח גם כברירת מחדל). לאחר מכן, תאמתו את הטוקן הזה באמצעות SDK לאדמינים, בנוסף לבדיקת קובץ ה-Cookie הזמני שבוצעה על ידי ה-framework של ה-בק-אנד. כך יהיה קשה יותר לבצע מתקפות CSRF, כי טוקן של מזהה מאוחסן רק באמצעות אחסון באינטרנט ולא בקובץ Cookie.

    3. האסימונים של Identity Toolkit תקפים למשך שבועיים. אפשר להמשיך להנפיק אסימונים שתקפים לשבועיים, או להאריך או לקצר את משך הזמן בהתאם לדרישות האבטחה של האפליקציה. כשמשתמש יוצא מהחשבון, צריך למחוק את קובץ ה-Cookie הזמני של הסשן.

שלב 3: מעדכנים את כתובות ה-URL להפניה אוטומטית של ספק הזהויות (IDP)

  1. במסוף Cloud, פותחים את הקטע Providers.

  2. לכל ספק של כניסה מאוחדת שאתם תומכים בו, בצעו את הפעולות הבאות:

    1. לוחצים על השם של ספק הכניסה.
    2. מעתיקים את ה-URI להפניה אוטומטית ב-OAuth.
    3. במסוף למפתחים של ספק הכניסה, מעדכנים את כתובת ה-URI להפניה אוטומטית של OAuth.

Android

שלב 1: מוסיפים את Identity Platform לאפליקציה באמצעות Firebase

  1. פותחים את מסוף Cloud ובוחרים את הפרויקט ב-Identity Toolkit.

  2. בדף Providers, לוחצים על Application setup details, בוחרים בכרטיסייה Android ולוחצים על Get Started in Firebase. בתיבת הדו-שיח Add Firebase, מזינים את שם החבילה של האפליקציה ואת טביעת האצבע לאישור החתימה, ולוחצים על Add App. קובץ התצורה google-services.json יורד למחשב.

  3. מעתיקים את קובץ התצורה לתיקיית השורש של מודול האפליקציה ל-Android. קובץ התצורה הזה מכיל מידע על הפרויקט ועל לקוח Google OAuth.

  4. בקובץ build.gradle ברמת הפרויקט (<var>your-project</var>/build.gradle), מציינים את שם החבילה של האפליקציה בקטע defaultConfig:

    defaultConfig {
   …..
  applicationId "com.your-app"
}

  5. בקובץ build.gradle ברמת הפרויקט, מוסיפים תלות כדי לכלול את הפלאגין של google-services:

    buildscript {
 dependencies {
   // Add this line
   classpath 'com.google.gms:google-services:3.0.0'
 }
}

  6. בקובץ 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.

  7. גם בקובץ build.gradle ברמת האפליקציה, מוסיפים את התלות של אימות ב-Firebase:

    compile 'com.google.firebase:firebase-auth:25.0.0'
compile 'com.google.android.gms:play-services-auth:22.0.0'

שלב 2: מסירים את Identity Toolkit SDK

  1. מסירים את ההגדרה של Identity Toolkit מהקובץ AndroidManifest.xml. המידע הזה נכלל בקובץ google-service.json ונטען על ידי הפלאגין google-services.
  2. מסירים את Identity Toolkit SDK מהאפליקציה.

שלב 3: מוסיפים את FirebaseUI לאפליקציה

  1. מוסיפים את FirebaseUI Auth לאפליקציה.

  2. באפליקציה, מחליפים את הקריאות ל-Identity Toolkit SDK בקריאות ל-FirebaseUI.

iOS

שלב 1: מוסיפים את Firebase לאפליקציה

  1. כדי להוסיף את ה-SDK של הלקוח לאפליקציה, מריצים את הפקודות הבאות:

    $ cd your-project directory
$ pod init
$ pod 'Firebase'

  2. פותחים את מסוף Cloud ובוחרים את הפרויקט ב-Identity Toolkit.

  3. בדף Providers, לוחצים על Application setup details, בוחרים בכרטיסייה iOS ולוחצים על Get Started in Firebase. בתיבת הדו-שיח Add Firebase, מזינים את שם החבילה של האפליקציה ואת טביעת האצבע לאישור החתימה, ולוחצים על Add App. קובץ התצורה google-services.json יורד למחשב. בתיבת הדו-שיח Add Firebase, מזינים את מזהה החבילה ואת מזהה האפליקציה ב-App Store, ולוחצים על Add App. קובץ התצורה GoogleService-Info.plist יורד למחשב. אם יש לכם כמה מזהי חבילות בפרויקט, צריך לקשר כל מזהה חבילה במסוף Firebase כדי שיהיה לו קובץ GoogleService-Info.plist משלו.

  4. מעתיקים את קובץ התצורה לרמה הבסיסית (root) של פרויקט Xcode ומוסיפים אותו לכל יעדי הטרגוט.

שלב 2: מסירים את Identity Toolkit SDK

  1. מסירים את GoogleIdentityToolkit מה-Podfile של האפליקציה.
  2. מריצים את הפקודה pod install.

שלב 3: מוסיפים את FirebaseUI לאפליקציה

  1. מוסיפים את FirebaseUI Auth לאפליקציה.

  2. באפליקציה, מחליפים את הקריאות ל-Identity Toolkit SDK בקריאות ל-FirebaseUI.