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

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

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

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

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

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

   נקודה חשובה: מטעמי אבטחה, אסור להוסיף סשנים חדשים של Google ב-iframe.

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

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

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

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

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

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

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

   

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. ארגון מחדש של חוויית המשתמש כדי להפריד בין רגעי האימות וההרשאה.

2. מעבר לספריית ה-JavaScript של Google Identity Services.

   נקודה חשובה: נתמקד ב-API של רגע האימות ובתכונות שבהמשך. עיינו במסמך ההרשאות של Authorization API כדי למצוא את הפיצ'רים וה-API של ההרשאה.

API של HTML לעומת JavaScript API

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

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

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

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

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

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

JavaScript API מאפשר לכם גמישות רבה יותר בתרחישים מסוימים, כפי שמתואר בהמשך.

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

אפשר להפעיל קוד HTML API רק פעם אחת באירוע onload של הדף או באירוע הטעינה של ספריית JavaScript של Google Identity Services, המוקדם מביניהם. אם ההתנהגות של HTML API לא עומדת בציפיות שלכם, כדאי להשתמש ב-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 אם אחת או יותר מהשיטות ב-initialize(), ב-prompt() או ב-render() מופעלות בקוד ה-JavaScript, ולא משנה אם הן מודגשות או נטענות מקובץ JavaScript נפרד.

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

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

• revoke
• cancel
• disableAutoSelect
• storeCredential

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אזהרה: אפשר לכלול רק רכיב <div id='g_id_onload' ... ><id> אחד באותו דף אינטרנט. אל תעתיקו מספר רכיבי g_id_onload לדף האינטרנט שלכם.

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

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

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

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

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

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

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

שיקולים בנוגע בהקשה אחת

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

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

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

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

מתי להציג את ממשק המשתמש בהקשה אחת

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

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

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

המלצות

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

לא מומלץ

• אם מציעים רק הקשה אחת, המשתמשים עלולים להיתקל בחוויית כניסה לא תקינה אם התכונה One Tap לא מוצגת.
• שימוש בקריאה חוזרת (callback) של סטטוס ממשק המשתמש כדי להציג ממשק משתמש אחר אם הקשה אחת לא מוצגת. לא מומלץ לעשות זאת, כי יכול להיות שהקריאה החוזרת (callback) של הסטטוס של ממשק המשתמש לא תפעל עם ניהול פרטי כניסה מאוחד בגרסה עתידית.

הקשה אחת על דפדפני ITP

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

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

הערה: חוויית המשתמש ב-One Tap בדפדפני ITP לא תומכת בכניסה אוטומטית.

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

ביטול ההצעה אם המשתמש לוחץ כדי לצאת

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

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

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

שינוי המיקום של ממשק המשתמש בהקשה אחת

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

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

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

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

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

נקודה חשובה: במאמר שינוי ההקשר לכניסה בהקשה אחת מוסבר איך לשנות את ההקשר.

האזנה לסטטוס של ממשק המשתמש בהקשה אחת

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

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

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

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

נקודה חשובה: יש פרטים נוספים במאמר תצוגה בהקשה אחת בתת-דומיינים.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. אחרת (ממשק API של HTML עם מקרה URI של התחברות):

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

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

שיקולי אבטחה

כדי למנוע התקפות זיוף של בקשות חוצות-אתרים (Cross-Site Request Forgery),

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

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

שאלות נפוצות

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

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

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

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

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

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

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

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

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

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

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

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

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

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