שיקולים בשילוב

המדריך המפורט הזה יעזור לכם לקבל החלטות לגבי כל הבעיות העיקריות בשילוב.

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

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

  1. משתמשים נכנסים לאתר של Google.

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

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

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

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

    כשיש רק סשן פעיל אחד של Google בדפדפן,

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

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

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

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

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

    מטרת ההחזרה של אסימונים מזהים למטפל בקריאה החוזרת (callback) של JavaScript בצד הלקוח היא לא לפענח אותם בקוד JavaScript, אלא לשלוח אותם לשרת בדרך שלכם. דוגמה טובה לכך היא שימוש ב-XmlHttpRequest כדי למנוע טעינה מחדש של הדף שנגרמת על ידי שליחת הפוסט.

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

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

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

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

גישה לממשקי API ולשירותים של Google

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

הפרדה של חוויית המשתמש לאימות ולהרשאה

אם באתר שלכם צריך להפעיל גם ממשקי API לאימות וגם ממשקי API להרשאה, צריך להפעיל אותם בנפרד ברגעים שונים. הפרדה בין רגעי האימות וההרשאה

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

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

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

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

HTML API לעומת JavaScript API

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

ב-HTML API יש יותר תכונות מובנות. לדוגמה,

  • עיבוד של הקשה אחת או של הלחצן 'כניסה באמצעות חשבון Google' בזמן טעינת הדף.
  • שולחים את פרטי הכניסה שהוחזרו לנקודת הקצה בצד השרת, שצוינה במאפיין data-login_uri, אחרי שמשלימים את תהליך הכניסה בנגיעה אחת, הכניסה האוטומטית או חוויית המשתמש של חלון קופץ או הפניה אוטומטית של כפתור.
  • מניעת התקפות CSRF באמצעות double-submit-cookie.
  • משתמשים במחולל הקוד כדי ליצור את קוד ה-HTML, ואז מעתיקים אותו לדפי ה-HTML.

באמצעות HTML API, אפשר גם לכתוב קצת JavaScript כדי להתאים אישית את ההתנהגות.

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

ב-JavaScript API יש לכם יותר גמישות בתרחישים מסוימים.

  • עיבוד של One Tap והלחצן 'כניסה באמצעות חשבון Google' בשלב מאוחר יותר. לדוגמה, אחרי שהמשתמשים בוחרים באפשרות Login בתפריט.
  • שליחת קריאה ל-API כמה פעמים. לדוגמה, צריך ליצור את הלחצן 'כניסה באמצעות חשבון Google' בכל פעם שרוצים ליצור את תיבת הדו-שיח של הכניסה.
  • יצירת דפי ה-HTML באופן דינמי, מה שמקשה להטמיע בהם קוד של קריאה ל-API.
  • טוענים את ספריית JavaScript של Google Identity Services בשלב מאוחר יותר.

אפשר להפעיל קוד HTML API רק פעם אחת, באירוע ה-onload של הדף או באירוע ה-onload של ספריית JavaScript של Google Identity Services, לפי המאוחר מביניהם. כדאי להשתמש ב-JavaScript API אם ההתנהגות של HTML API לא עומדת בציפיות שלכם.

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

  • אתם משתמשים ב-HTML API אם אחד או יותר מהרכיבים ב-<div id='g_id_onload' ... ><id> או ב-<div class='g_id_signin' ...></div> קיימים בקוד ה-HTML שלכם.
  • אתם משתמשים ב-JavaScript API אם אחד או יותר מה-methods ב-initialize(),‏ prompt() או render() מופעלים בקוד ה-JavaScript שלכם, בין שהם מוטמעים בקוד ובין שהם נטענים מקובץ JavaScript נפרד.

אפשר להשתמש בממשקי ה-API הבאים של JavaScript בנפרד מהפעלת הקוד או מהעיבוד של לחיצה אחת ושל לחצן. לממשקים האלה אין ממשקי API תואמים של HTML:

שיקולים לגבי לחצן הכניסה באמצעות חשבון Google

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

חלון קופץ לעומת הפניה אוטומטית

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

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

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

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

  • בתהליך ההפניה האוטומטית של הלחצן 'כניסה באמצעות חשבון Google', השיטה POST משמשת תמיד לשליחת פרטי הכניסה לשרת האינטרנט, בעוד שבהפניה האוטומטית של OAuth השיטה GET משמשת בדרך כלל.
  • הפרמטרים שנשלחים בתהליך ההפניה האוטומטית של הלחצן 'כניסה באמצעות חשבון Google' שונים מאלה של תהליך ההפניה האוטומטית של OAuth.

מפתחים שמשתמשים ב-HTML API, לא משנה באיזו חוויית משתמש הם משתמשים, תמיד שולחים את פרטי הכניסה אל data-login_uri באמצעות השיטה POST ועם אותם פרמטרים. כך תוכלו להחליף את מצב ממשק המשתמש בלי לבצע שינויים אחרים בקוד. כדי להשתמש בממשק המשתמש של ההפניה האוטומטית, צריך להוסיף את data-login_uri לURI של ההפניה האוטומטית המורשים של הלקוח במסוף Google APIs.

התאמה אישית של הלחצן

אין תמיכה בשימוש בלחצן משלכם. אין ממשק API להפעלה פרוגרמטית של תהליך לחיצה על לחצן.

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

באמצעות Button Rendering API אפשר להתאים אישית את המראה והתחושה של הלחצן 'כניסה באמצעות חשבון Google'. מומלץ להשתמש במחולל הקוד כדי לעצב את הלחצנים באופן אינטראקטיבי. גם אם אתם משתמשים ב-JavaScript API, תוכלו ליצור קודם את קוד ה-HTML ולאחר מכן להעתיק את הקוד לשדות המתאימים ב-JavaScript API.

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

אפשר להוסיף כמה לחצנים לאותו דף אינטרנט. בכל פעם אפשר ליצור רק לחצן אחד באמצעות הכלי ליצירת קודים. אפשר להריץ אותו כמה פעמים ולהעתיק את הקוד שנוצר של <div class='g_id_signin' ...></div> לדף האינטרנט.

שיטות מומלצות לעיבוד לחצנים

מטעמי פרטיות, הלחצן המותאם אישית מוצג ב-iframe מהדומיין accounts.google.com. טעינת iframe עשויה להימשך זמן רב ברשת איטית. כדי לצמצם את זמן האחזור, הלחצנים מוצגים ב-2 שלבים:

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

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

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

שיקולים לגבי One Tap

כניסה אוטומטית

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

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

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

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

מתי להציג את ממשק המשתמש של One Tap

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

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

מומלץ

  • הצגת תיבת הדו-שיח של הכניסה עם כניסה באמצעות סיסמה ולחצן הכניסה באמצעות חשבון Google, תוך כדי קריאה ל-One Tap API. כך תמיד תוכלו להציע למשתמשים שיטת כניסה לאתר.

לא מומלץ

הקשה אחת בדפדפני ITP

בגלל מניעת מעקב חכמה (ITP), חוויית המשתמש הרגילה של One Tap לא פועלת בדפדפנים עם ITP, כמו Chrome ב-iOS, ‏ Safari ו-Firefox. במקום זאת, בדפדפנים האלה מוצגת חוויית משתמש שונה שמתחילה בדף קבלת פנים.

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

אי אפשר להפעיל את חוויית המשתמש הזו בדפדפנים ללא ITP, כמו Chrome ב-Android‏, ב-macOS וב-Linux ו-Edge.

ביטול ההנחיה אם המשתמש לוחץ עליה

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

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

שינוי המיקום של ממשק המשתמש של One Tap

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

שינוי ההקשר של הכניסה

התכונה 'הקשה אחת' צריכה להיות חלק מתהליך UX רחב יותר באתר. כברירת מחדל, ממשק המשתמש של One Tap משמש בהקשר של כניסה לחשבון. השפה בממשק המשתמש מכילה ניסוח ספציפי, כמו 'כניסה'. אפשר לשנות את מאפיין ההקשר כדי ליצור קבוצה אחרת של ניסוח. אתם יכולים לבחור אחת מהכותרות של One Tap שמתאימה ביותר לתהליך חוויית המשתמש.

הקשר
signin 'כניסה באמצעות חשבון Google'
signup 'הרשמה באמצעות חשבון Google'
use 'שימוש ב-Google'

סטטוס ממשק המשתמש של Listen on One Tap

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

הקשה אחת על תתי-דומיינים

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

כניסה בהקשה אחת בדפי HTML סטטיים

כברירת מחדל, ספריית ה-GIS מניחה שדפי האינטרנט שלכם נוצרים באופן דינמי. שרת ה-HTTP בודק את סטטוס ההתחברות של המשתמש בזמן יצירת קוד ה-HTML.

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

במקרה כזה, האחריות להוספה או להסרה של קוד ה-API של One Tap HTML מוטלת על שרת האינטרנט.

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

  • אם קובץ ה-cookie של הסשן לא קיים, תהליך One Tap מופעל.
  • אם קובץ ה-cookie של הסשן קיים, תהליך ההתחברות בנגיעה אחת ינוข้าม.

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

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

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

שיקולים לגבי חוויית המשתמש

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

חוויית המשתמש בפועל שתקבלו מתוארת בהמשך.

  1. במצב ממשק המשתמש של הלחצן 'כניסה באמצעות חשבון Google' להפניה אוטומטית:

    • בין אם משתמשים ב-HTML API ובין אם ב-JavaScript API, צריך להגדיר את ה-URI של ההתחברות. אי אפשר להשתמש בפונקציית קריאה חוזרת של JavaScript כדי לטפל בתגובה, כי המשתמשים כבר הופנו לדף אחר.
    • סיכום חוויית המשתמש: אחרי שלוחצים על הלחצן 'כניסה באמצעות חשבון Google', המשתמשים מופנים לדף מלא של ממשק משתמש של Google לבחירה ולאישור של סשן. בסיום, POST של דף מלא נשלח לכתובת ה-URI להתחברות שציינתם.
  2. במצב UX של הקשה אחת או של חלון קופץ עם הלחצן 'כניסה באמצעות חשבון Google', אם נעשה שימוש ב-JavaScript API או ב-HTML API וסופקת פונקציית קריאה חוזרת (callback) של JavaScript:

    • תגובות האימות מועברות חזרה לפונקציית ה-callback של JavaScript.
    • סיכום חוויית המשתמש: ההנחיה להקשה אחת או חלון קופץ מוצגים מעל דף האינטרנט. אחרי שהמשתמשים מסיימים את חוויית המשתמש בהנחיה או בחלון הקופץ לבחירה ולאישור של סשן, התשובות מתקבלות בפונקציית ה-callback של JavaScript. חוויית המשתמש הבאה נקבעת לפי האופן שבו פונקציית ה-callback שולחת את התשובות לשרת.
  3. אחרת (במקרה של HTML API עם URI להתחברות):

    • תשובות האימות נשלחות לכתובת ה-URI של ההתחברות.
    • סיכום חוויית המשתמש: ההנחיה להקשה אחת או חלון קופץ מוצגים מעל דף האינטרנט. אחרי שהמשתמשים מסיימים את חוויית המשתמש בהנחיה או בחלון הקופץ לבחירת סשן ולאישור, התשובות לאימות נשלחות באמצעות שליחת POST של דף מלא לכתובת ה-URL להתחברות שציינתם.

מומלץ להשתמש בדרך עקבית לשליחת התשובות מהלחצן 'הקשה אחת לכניסה באמצעות חשבון Google'.

שיקולי אבטחה

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

  • לשליחת הודעות שמופעל על ידי ספריית ה-JavaScript של לקוח Google Identity Service, אפשר להשתמש בתבנית המובנית של שליחת קובץ cookie כפול. למידע נוסף, ראו אימות אסימון מזהה Google בצד השרת.
  • כדי לשלוח בקשה למקור שלכם באמצעות XmlHttpRequest, תוכלו להשתמש בכותרת HTTP בהתאמה אישית או באמצעי אבטחה אחרים שאושרו על ידי צוות האבטחה שלכם.

כדי לאמת את האסימונים המזהים בתשובות האימות, מומלץ מאוד להשתמש בספריית לקוח של Google API לפלטפורמה שלכם, או בספריית JWT לשימוש כללי.

שאלות נפוצות

  • האם הלחצן 'כניסה בהקשה אחת' ו'כניסה באמצעות חשבון Google' זמינים בתצוגות אינטרנט?

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

  • האם אפשר להשתמש בלחצן 'כניסה באמצעות חשבון Google' משלכם? לא. באמצעות התהליך של OAuth בצד השרת או הגרסה הקודמת של ספריית JavaScript של Google Sign In, צדדים נסמכים יכלו להשתמש בהנחיות למיתוג של הכניסה כדי ליצור גרסאות משלהם של לחצני Google Sign In.

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

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

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

  • מה קורה אם באתר מופעל רק One Tap אבל לא הלחצן 'כניסה באמצעות חשבון Google'?

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

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

  • מתי מתבצע ניתוח של קוד ה-API ב-HTML? האם אפשר לשנות את קוד ה-HTML API מאוחר יותר?

    ספריית JavaScript של Google Identity Services מנתחת ומריצה את קוד ה-HTML API באירוע הטעינה של ספריית JavaScript או באירוע DomContentLoaded, המאוחר מביניהם.

    • אם האירוע DOMContentLoaded מופעל כשספריית JavaScript נטענת, קוד ה-HTML API מנותח ומופעל באופן מיידי.
    • אחרת, ספריית JavaScript מוסיפה מאזין לאירוע DomContentLoaded. כשהאזן מופעל, הוא מנתח ומריץ את קוד ה-API ב-HTML.

    חשוב גם לזכור שניתוח הקוד של ה-API ב-HTML והפעלה שלו הם פעולות נפרדות.

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