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

הגרסה החדשה ביותר של Google Identity Toolkit הושקה כ-Identity Platform וכ-Firebase Authentication. בעתיד, פיתוח התכונות ב-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 כמו במקרה של משתמש רגיל. כשהמשתמש מחליט להירשם לחשבון, כל הפעילות נשמרת עם אותו User-ID. האפשרות הזו שימושית בתרחישים כמו עגלות קניות בצד השרת או אפליקציות אחרות שבהן רוצים לעודד את המשתמשים להירשם לפני ששולחים אותם לתהליך הרשמה.

  • התרחבות בביטחון בעזרת הסכמי רמת שירות ותמיכה בענן

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

  • גישה לכל השירותים של Firebase

    ‫Firebase היא פלטפורמה לניידים שעוזרת לכם לפתח במהירות אפליקציות באיכות גבוהה, להגדיל את בסיס המשתמשים ולהרוויח יותר כסף. ‫Firebase מורכב מתכונות משלימות שאפשר לשלב ביניהן כדי להתאים אותן לצרכים שלכם, והוא כולל תשתית ל:Analytics לנייד, העברת הודעות בענן, מסד נתונים בזמן אמת, אחסון קבצים, אירוח סטטי, הגדרת תצורה מרחוק, דיווח על קריסות בנייד ובדיקות ב-Android.

  • ממשקי משתמש מעודכנים

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

  • הגדרה פשוטה יותר של השרת

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

  • ערכות SDK חדשות

    כל ממשקי ה-API של השרת של Identity Toolkit זמינים עכשיו באופן מקורי בכל אחת מספריות הלקוח שלנו (Android, ‏ iOS, ‏ web). מפתחים יוכלו להיכנס ולרשום משתמשים חדשים וישנים, לגשת למאפייני משתמש, לקשר, לעדכן ולמחוק חשבונות, לאפס סיסמאות ועוד, בלי להיות קשורים לממשק משתמש קבוע. אם אתם מעדיפים, אתם יכולים ליצור באופן ידני תהליך כניסה מלא משלכם על בסיס ה-API הזה.

  • ניהול סשנים באפליקציות לנייד

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

הבדלים בתכונות

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

הבדלים בצד השרת

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

  • ספקי זהויות

    אין תמיכה ב-PayPal וב-AOL. משתמשים עם חשבונות מספקי הזהויות האלה עדיין יכולים להיכנס לאפליקציה שלכם באמצעות תהליך שחזור הסיסמה ולהגדיר סיסמה לחשבון שלהם.

  • ספריות שרת

    נכון לעכשיו, יש Admin SDKs זמינים ל-Java, ל-Node.js, ל-Python, ל-Go ול-C#.

  • אימיילים לניהול החשבון

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

  • UI Widget

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

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

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

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

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

כדי להעביר נתונים מ-Identity Toolkit אל Identity Platform, צריך:

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

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

  3. פותחים את הדף חשבונות שירות. כאן אפשר לראות את חשבון השירות שהגדרתם בעבר עבור Identity Toolkit.

  4. לצד חשבון השירות, לוחצים על > יצירת מפתח. לאחר מכן, בתיבת הדו-שיח 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. אפשר להתקין את Node.js Admin SDK באמצעות 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, ‏ web.

שרתים ו-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: שינוי קוד השרת

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

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

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

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

מידע נוסף מופיע בהפניית Web API.

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

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

    1. פותחים את הפרויקט במסוף Cloud.
    2. בדף ספקים, לוחצים על פרטי הגדרת האפליקציה. מוצג קטע קוד שמבצע אתחול של 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. שולחים את טוקן ה-ID לשרת הקצה העורפי, מאמתים אותו ומנפיקים קובץ cookie משלכם של סשן.

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

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

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

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

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

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

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

Android

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

  1. פותחים את Cloud Console ובוחרים את הפרויקט של Identity Toolkit.

  2. בדף 'ספקי זהויות', לוחצים על פרטי הגדרת האפליקציה, בוחרים בכרטיסייה Android ואז לוחצים על תחילת העבודה ב-Firebase. בתיבת הדו-שיח Add Firebase (הוספת 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 ברמת הפרויקט, מוסיפים תלות (dependency) כדי לכלול את הפלאגין 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 Authentication:

    compile 'com.google.firebase:firebase-auth:24.0.1'
compile 'com.google.android.gms:play-services-auth:21.4.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 Console ובוחרים את הפרויקט של Identity Toolkit.

  3. בדף 'ספקים', לוחצים על פרטי הגדרת האפליקציה, בוחרים בכרטיסייה iOS ואז לוחצים על תחילת העבודה ב-Firebase. בתיבת הדו-שיח 'הוספת Firebase', מזינים את שם החבילה של האפליקציה ואת טביעת האצבע של אישור החתימה ולוחצים על הוספת אפליקציה. קובץ ההגדרות google-services.json יורד למחשב. בתיבת הדו-שיח 'הוספת Firebase', מזינים את מזהה החבילה ואת המזהה של App Store של האפליקציה, ואז לוחצים על הוספת אפליקציה. קובץ ההגדרות 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.