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

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

תכונות חדשות

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

  • מסוף Admin החדש

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

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

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

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

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

  • גישה לכל הפלטפורמות של Firebase

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

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

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

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

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

  • ספקי זהויות

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

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

    בשלב הזה יש ערכות SDK לניהול זמין ל-Java, Node.js, Python, Go ו-C#.

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

    הודעות איפוס סיסמה, אימות אימייל ושינוי אימייל מבוצעת על ידי Firebase או שרת דואר משלנו. בשלב הזה, ההצעות לתבניות אימייל מוגבלות בלבד להתאמה אישית של ממשק המשתמש, אבל ניתן לבצע התאמה אישית נוספת באמצעות ערכות SDK לניהול

  • אישור השינוי של כתובת האימייל

    בערכת הכלים לניהול זהויות, כשמשתמש מחליט לשנות את כתובת האימייל שלו, שולח אימייל לכתובת החדשה עם קישור להמשך האימייל תהליך שינוי כתובת.

    מערכת Firebase מאשרת את השינוי של כתובת האימייל על ידי שליחת הודעת אימייל לביטול אל את כתובת האימייל הישנה עם קישור לביטול השינוי.

  • השקת ה-IdP

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

הבדלים בצד הלקוח

ב-Identity Platform, התכונות של Google Identity Toolkit מחולקות לשני רכיבים:

  • ערכות SDK של לקוחות ושרתים

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

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

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

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

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

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

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

לפני שתוכלו לעבור מ-Identity Toolkit ל-Identity Platform, חייב:

  1. פותחים את מסוף Cloud ובוחרים פרויקט ערכת הכלים לניהול זהויות (IAM).

  2. מ-Marketplace, מנווטים אל פלטפורמת Identity ובוחרים באפשרות 'Enable Identity Platform'

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

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

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

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

שרתים ו-JavaScript

שינויים חשובים

יש כמה הבדלים נוספים באופן ההטמעה של האינטרנט Identity Platform מתוך Identity Toolkit.

  • ניהול סשנים באינטרנט

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

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

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

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

    בעבר, המשתמשים נותבו אל accountchooser.com כשהכניסה בוצעה כדי ללמוד באיזה מזהה המשתמש רצה להשתמש. פלטפורמת זהויות תהליך העבודה בממשק המשתמש מתחיל עכשיו ברשימה של שיטות כניסה, כולל אימייל שמפנה אל 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 (תקף לשבועיים) כדי לנהל הפעלות של משתמשים באינטרנט, עליך להמיר את השרת כדי להשתמש של סשן.

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

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

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

מידע נוסף זמין בחומר העזר בנושא Web API.

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

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

    1. פותחים את הפרויקט ב מסוף Cloud.
    2. אצל הספקים לוחצים על 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. צריך להסיר את ה-SDK של Identity Toolkit מהאפליקציה.

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

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

    2. שליחת אסימון המזהה לשרת העורפי, אימות שלו ופתרון הבעיה של סשן משלכם.

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

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

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

שלב 3: עדכון כתובות ה-URL להפניה אוטומטית של ה-IdP

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

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

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

Android

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

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

  2. בדף 'ספקים', לוחצים על פרטי הגדרת אפליקציה, בוחרים את Android ולאחר מכן לוחצים על תחילת העבודה ב-Firebase. בתיבת הדו-שיח 'הוספת Firebase', מציינים את שם החבילה ואת החתימה של האפליקציה טביעת אצבע לאישור ולוחצים על הוספת אפליקציה. google-services.json לאחר מכן תתבצע הורדה של קובץ התצורה למחשב.

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

  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:23.0.0'
compile 'com.google.android.gms:play-services-auth:21.2.0'

שלב 2: הסרת ה-SDK של Identity Toolkit

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

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

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

שלב 2: הסרת ה-SDK של Identity Toolkit

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

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

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

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