העברה מכניסה באמצעות חשבון Google

המדריך הזה יעזור לכם להבין את השינויים הנדרשים ואת השלבים שצריך לבצע כדי העברה מוצלחת של ספריות JavaScript מגרסת הכניסה הקודמת באמצעות חשבון Google ספריית הפלטפורמה החדשה לספרייה החדשה יותר של Google Identity Services עבור אימות.

אם הלקוח שלכם משתמש בספריית הלקוח של Google API ל-JavaScript או למטרות אחרות לספריות קודמות של הרשאות, אפשר לעיין במאמר העברה לזהות Google מידע נוסף.

אימות והרשאה

אימות בודק מי המשתמש, ובדרך כלל נקרא הרשמה או כניסה של משתמשים. הרשאה היא התהליך של הענקה או דחיית הגישה לנתונים או למשאבים. לדוגמה, האפליקציה מבקשת הסכמת המשתמש לגישה ל-Google Drive של המשתמש.

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

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

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

אם התרחיש לדוגמה שלכם כולל הרשאה, כדאי לקרוא את המאמר איך הרשאת משתמשים עובדת ולעבור ל-Google Identity Services כדי לוודא שהאפליקציה באמצעות ממשקי ה-API החדשים והמשופרים.

מה השתנה

למשתמשים, הספרייה החדשה של Google Identity Services מציעה שיפורים בנוחות השימוש. הסיכום כולל:

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

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

• האפשרות להוסיף כניסת משתמש לתוכן הסטטי של האתר באמצעות HTML,
• הפרדה בין אימות כניסה לבין הרשאה ושיתוף נתוני משתמשים, המורכבות של שילוב OAuth 2.0 כבר לא נחוצה כדי להכניס משתמשים לאתר שלכם,
• יש תמיכה גם במצב חלון קופץ וגם במצב הפניה, אבל ב-OAuth של Google שתשתית 2.0 מפנה עכשיו לנקודת הקצה (endpoint) של שרת הקצה העורפי,
• איחוד היכולות של אימות הזהות הקודם של Google ואת ספריות ה-JavaScript של Google API בספרייה חדשה אחת,
• לתגובות לכניסה, עכשיו אפשר להחליט אם להשתמש Promise ועקיפה באמצעות פונקציות של getter style הוסרה כדי לשמור על פשטות.

דוגמה להעברת פרטי כניסה

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

ספריות והגדרות

הספרייה הקודמת של הפלטפורמה לכניסה באמצעות חשבון Google: apis.google.com/js/platform.js, וספריית הלקוח של Google APIs עבור JavaScript: gapi.client, לא שנדרשים יותר לצורך אימות והרשאה של משתמשים. הם היו הוחלפה בספריית JavaScript חדשה אחת של Google Identity Services: accounts.google.com/gsi/client

שלושת המודולים של JavaScript הקודמים: api, client ו-platform ששימשו ל- פרטי הכניסה נטענות מ-apis.google.com. כדי לעזור לך לזהות מיקומים שבהם הספרייה הקודמת עשויה להיכלל באתר, בדרך כלל:

• לחצן הכניסה שמוגדר כברירת מחדל טוען את apis.google.com/js/platform.js,
• מתבצעת טעינה של apis.google.com/js/api:client.js בגרפיקה של לחצן מותאם אישית, וגם
• שימוש ישיר ב-gapi.client טוען apis.google.com/js/api.js.

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

• אפליקציות הבדיקה והייצור משתמשות בפרויקטים נפרדים מזהי לקוח,
• הסוג של מזהה הלקוח ב-OAuth 2.0 הוא "Web application",
• HTTPS משמש למקורות JavaScript מורשים ולהפניות URI.

זיהוי הקוד המושפע ובדיקה

קובץ cookie לניפוי באגים יכול לעזור באיתור הקוד המושפע ובודקים אחרי ההוצאה משימוש או התנהגות המשתמשים.

באפליקציות גדולות או מורכבות, ייתכן שתתקשו למצוא את כל הקוד המושפע הוצאה משימוש של המודול gapi.auth2. כדי לתעד שימוש קיים ב- בקרוב יכולות שהוצאו משימוש במסוף, הגדרת הערך של G_AUTH2_MIGRATION ל-informational. אופציונלי: אפשר להוסיף נקודתיים ואחריו ערך מפתח כדי להיכנס גם לאחסון הפעלה. לאחר הכניסה לחשבון וקבלת לבדוק את פרטי הכניסה או לשלוח יומנים שנאספו לקצה עורפי לניתוח במועד מאוחר יותר. עבור לדוגמה, הפקודה informational:showauth2use שומרת את המקור ואת כתובת ה-URL באחסון של סשן מפתח בשם showauth2use.

כדי לאמת את התנהגות האפליקציה כשהמודול gapi.auth2 לא נטען יותר, יש להגדיר את של קובץ ה-cookie G_AUTH2_MIGRATION ל-enforced. כך אפשר לבצע בדיקה של התנהגות לאחר ההוצאה משימוש לפני תאריך האכיפה.

ערכים אפשריים של קובצי cookie מסוג G_AUTH2_MIGRATION:

• enforced לא לטעון את המודול gapi.auth2.
• informational לרשום במסוף JS שימוש ביכולות שהוצאו משימוש. אני רוצה גם ביומן לאחסון סשנים, כשמוגדר שם מפתח אופציונלי: informational:key-name

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

HTML ו-JavaScript

בתרחיש זה של כניסה לאימות בלבד, מופיעים הקוד והרינדור של מוצגים לחצן הכניסה הקיים באמצעות חשבון Google. בוחרים באחת מהאפשרויות הבאות: 'חלון קופץ' או 'הפניה אוטומטית' כדי לראות את ההבדלים באופן הטיפול בתגובת האימות קריאה חוזרת (callback) של JavaScript או באמצעות הפניה אוטומטית להתחברות של שרת הקצה העורפי נקודת הקצה.

הדרך המוקדמת יותר

<html>
  <body>
    <script src="https://apis.google.com/js/platform.js" async defer></script>
    <meta name="google-signin-client_id" content="YOUR_CLIENT_ID">
    <div class="g-signin2" data-onsuccess="handleCredentialResponse"></div>
  </body>
</html>

<html>
  <body>
    <script src="https://apis.google.com/js/platform.js" async defer></script>
    <meta name="google-signin-client_id" content="YOUR_CLIENT_ID">
    <div class="g-signin2" data-onsuccess="handleCredentialResponse"></div>
    <script>
      function handleCredentialResponse(googleUser) {
        ...
        var xhr = new XMLHttpRequest();
        xhr.open('POST', 'https://yourbackend.example.com/tokensignin');
        xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
        xhr.onload = function() {
          console.log('Signed in as: ' + xhr.responseText);
        };
        xhr.send('idtoken=' + id_token);
      }
    </script>
  </body>
</html>

הדרך החדשה

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

<html>
  <body>
    <script src="https://accounts.google.com/gsi/client" async defer></script>
    <div id="g_id_onload"
         data-client_id="YOUR_CLIENT_ID"
         data-callback="handleCredentialResponse">
    </div>
    <div class="g_id_signin" data-type="standard"></div>
  </body>
</html>

<html>
  <body>
    <script src="https://accounts.google.com/gsi/client" async defer></script>
    <div id="g_id_onload"
         data-client_id="YOUR_CLIENT_ID"
         data-ux_mode="redirect"
         data-login_uri="https://www.example.com/your_login_endpoint">
    </div>
    <div class="g_id_signin" data-type="standard"></div>
  </body>
</html>

בדוגמה הזו לאימות בלבד, הערך החדש של accounts.google.com/gsi/client ספרייה, מחלקה g_id_signin ואובייקט g_id_onload מחליפים את ספריית apis.google.com/js/platform.js ואובייקט g-signin2.

בנוסף לעיבוד הלחצן המותאם אישית החדש, גם הקוד לדוגמה מציג את החלון הקופץ החדש One Tap. בכל מקום שבו מציגים את הלחצן המותאם אישית, מומלץ מאוד להציג גם את החלון הקופץ One Tap כדי למזער את המשתמש יותר מורכבות במהלך ההרשמה והכניסה.

למרות שהדבר לא מומלץ עקב חיכוך מוגבר בכניסה, הממשק החדש ניתן להציג לחצן מותאם אישית בלבד, מבלי להציג בו-זמנית תיבת דו-שיח בהקשה אחת. כדי לעשות זאת, צריך להגדיר את המאפיין data-auto_prompt כ-false.

ממשקי API של HTML ו-JavaScript

הדוגמה הקודמת מראה איך להשתמש ב-HTML API החדש כדי להוסיף כניסה אל באתר שלך. לחלופין, אפשר להשתמש בפונקציה המקבילה מבחינה פונקציונלית JavaScript API, או שילוב של ממשקי API של HTML ו-JavaScript ברחבי .

כדי להציג באופן אינטראקטיבי אפשרויות התאמה אישית של לחצנים כמו סוג הקריאה החוזרת (callback) מאפיינים כמו: צבע, גודל, צורה, טקסט ועיצוב, תשלום הקוד שלנו Generator. אפשר להשתמש בו כדי להשוות במהירות בין אפשרויות שונות וליצור קטעי קוד HTML לשימוש באתר.

אפשר להיכנס לחשבון מכל דף בהקשה אחת

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

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

מומלץ גם להוסיף את g_id_signin, שבו מוצג תהליך הכניסה בהתאמה אישית רק בדפי ההתחברות או ניהול חשבון המשתמשים שלך. נותנים למשתמשים אפשרויות להרשמה או לכניסה באמצעות הצגת הלחצן לצד הלחצנים של ספק הזהויות והשדות של הזנת שם משתמש וסיסמה.

תגובת אסימון

כדי להשתמש ב-OAuth 2.0, כבר לא צריך להבין אותו או לעבוד עם כניסת משתמשים קודי הרשאה, אסימוני גישה או אסימוני רענון. במקום זאת, אסימון רשת מסוג JSON אסימון המזהה (JWT) משמש לשיתוף סטטוס הכניסה ופרופיל המשתמש. בתור פישוט נוסף, לא צריך יותר להשתמש ב-"getter" בסגנון שיטות גישה לעבודה עם נתונים של פרופיל משתמש.

פרטי כניסה של אסימון JWT מאובטח בחתימה של Google מוחזרים:

• ל-API של קריאה חוזרת ב-JavaScript המבוסס על הדפדפן של המשתמש במצב חלון קופץ, או
• לשרת הקצה העורפי שלכם דרך הפניה אוטומטית של Google לנקודת הקצה (endpoint) שלכם להתחברות הגדרת הלחצן 'כניסה באמצעות חשבון Google' ux_mode היא redirect.

בשני המקרים, מעדכנים את ה-handlers הקיימים של קריאה חוזרת על ידי הסרת:

• שיחות אל googleUser.getBasicProfile(),
• הפניות אל BasicProfile ושיחות משויכות אל getId(), getName(), getGivenName(), getFamilyName(), getImageUrl(), getEmail(), וגם
• שימוש באובייקט AuthResponse.

במקום זאת, צריך להשתמש בהפניות ישירות ל-credential שדות משנה בקובץ ה-JWT החדש אובייקט CredentialResponse כדי לעבוד עם נתונים של פרופיל משתמש.

בנוסף, ובמצב 'הפניה אוטומטית' בלבד, יש להקפיד למנוע 'בקשה בין אתרים' זיוף (CSRF) ואימות אסימון מזהה של Google בשרת הקצה העורפי שלכם.

כדי להבין טוב יותר את האינטראקציה של המשתמשים עם האתר שלכם, ניתן להשתמש בשדה select_by ב-CredentialResponse כדי לקבוע את המשתמש תהליך קבלת ההסכמה ותהליך הכניסה הספציפי שבו נעשה שימוש.

הסכמת המשתמש וביטול ההרשאה

כשמשתמש נכנס לאתר בפעם הראשונה, Google מבקשת ממנו הסכמה כדי לשתף את פרופיל החשבון שלהם עם האפליקציה. רק לאחר מתן ההסכמה פרופיל המשתמש שותף לאפליקציה שלכם במטען ייעודי (payload) של פרטי כניסה של אסימון מזהה. ביטול הגישה לפרופיל הזה מקביל לביטול אסימון הגישה ספריית כניסה מוקדמת יותר.

המשתמשים יכולים לבטל הרשאות ולנתק את האפליקציה שלך מחשבון Google שלהם בכתובת https://myaccount.google.com/permissions. לחלופין, הם עשויים להתנתק ישירות מהאפליקציה על ידי הפעלת API קריאה שתטמיעו, ה-method הקודם של disconnect הוחלף בשיטה החדשה יותר revoke.

כשמשתמש מוחק את החשבון שלו בפלטפורמה שלך, השיטה המומלצת היא revoke כדי לנתק את האפליקציה שלך מחשבון Google.

בעבר, ניתן היה להשתמש באפליקציה auth2.signOut() כדי לנהל את היציאה של משתמשים מהאפליקציה. יש להסיר כל שימוש ב-auth2.signOut(), וכן את האפליקציה צריך לנהל ישירות את מצב ההתחברות ואת סטטוס הכניסה לכל משתמש.

מצב הסשן ומאזינים

בספרייה החדשה לא נשמרים סטטוס הכניסה או מצב הסשן של האתר אפליקציה.

סטטוס הכניסה של חשבון Google, מצב הסשן של האפליקציה סטטוס מחובר הם מושגים נפרדים ונפרדים.

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

כשכניסה באמצעות חשבון Google, הקשה אחת או כניסה אוטומטית נכללות המשתמשים באתר חייבים להיכנס תחילה לחשבון Google שלהם כדי:

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

יכול להיות שהמשתמשים יישארו מחוברים, לצאת מהחשבון או לעבור לחשבון Google אחר תוך שמירה על פעילות פעילה ומחוברת באתר שלך.

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

צריך להסיר את כל ההפניות אל auth2.attachClickHandler() ולרשום אותו של קריאות חוזרות (callback).

בעבר, נעשה שימוש ב'מאזינים' כדי לשתף שינויים בסטטוס 'מחובר' של לחשבון Google של המשתמש. אין יותר תמיכה במאזינים.

מסירים את כל ההפניות אל listen(), auth2.currentUser ואל auth2.isSignedIn.

עוגיות

בכניסה באמצעות חשבון Google נעשה שימוש מוגבל בקובצי Cookie, התיאור של קובצי ה-Cookie האלה עוקבים. איך Google משתמשת בקובצי cookie לקבלת מידע נוסף על הסוגים האחרים של קובצי cookie שבהם Google משתמשת.

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

הספרייה החדשה של Google Identity Services יכולה גם להגדיר את הדומיינים של הדומיינים השונים קובצי Cookie שמבוססים על אפשרויות ההגדרה שלכם:

• סטטוס היציאה של המשתמש נשמר על ידי g_state, והוא מוגדר כשמשתמשים בהקשה אחת חלון קופץ או כניסה אוטומטית,

• g_csrf_token הוא קובץ Cookie לשליחה כפולה המשמש למניעת התקפות CSRF והיא מוגדרת כשמתבצעת קריאה לנקודת הקצה להתחברות. הערך של ה-URI להתחברות ניתן להגדיר במפורש או להשתמש ב-URI של הדף הנוכחי כברירת מחדל. שלך ניתן לקרוא לנקודת הקצה להתחברות בתנאים הבאים כשמשתמשים:

  • HTML API עם data-ux_mode=redirect או כאשר data-login_uri הוא להגדיר, או

  • JavaScript API עם ux_mode=redirect וכאשר google.accounts.id.prompt() לא משמש להצגת 'הקשה אחת' או כניסה אוטומטית.

אם יש לכם שירות שמנהל קובצי cookie, חשוב להוסיף את שני קובצי ה-cookie החדשים ולהסיר את קובץ ה-cookie הקודם לאחר השלמת ההעברה.

אם יש לך מספר דומיינים או תת-דומיינים, עליך לעיין במאמר Display One Tap בכל תת-דומיינים כדי לקבל הוראות נוספות לעבודה עם קובץ ה-cookie g_state.

מסמך עזר בנושא העברת אובייקטים לכניסת משתמשים