לבדוק את ההשפעה של שינויים בקובצי cookie של צד שלישי על תהליכי הכניסה שלכם לחשבון.

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

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

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

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

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

תהליכים נפוצים שעוברים המשתמשים

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

ממשקי API חלופיים מומלצים לתרחישי שימוש נפוצים

בטבלה נמצאים בשלבי פיתוח מוקדמים. המשוב שלכם חשוב לנו מאוד, והוא יעזור לנו לתכנן את העתיד של התוכנית. נשמח לשמוע מה דעתך על ממשקי ה-API האלה: Partitioned Popins.

התהליך שעובר המשתמש	ממשקי API מומלצים
כניסה באמצעות חשבון ברשתות חברתיות	לספקי זהויות: מטמיעים את FedCM לצדדים מסתמכים: פונים לספק הזהויות
כניסה יחידה (SSO)	לספקי זהויות או לפתרונות בהתאמה אישית: קבוצות של אתרים קשורים
ניהול פרופיל המשתמש	‫Storage Access API Related Website Sets CHIPS FedCM + SAA
ניהול מינויים	‫Storage Access API Related Website Sets CHIPS FedCM + SAA
אימות	Storage Access API FedCM Web Authentication API sciencePartitioned Popins
תהליכי משתמש אחרים	בדרך כלל, התרחישים האלה לא תלויים בקובצי Cookie של צד שלישי, ולא צפויים להיות מושפעים.

בדיקת התהליכים שעוברים המשתמשים שקשורים לזהות

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

זו רשימת משימות שכדאי לבדוק אחרי שמגבילים את קובצי ה-Cookie של צד שלישי:

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

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

פתרונות לכניסה לחשבון

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

כניסה יחידה (SSO) של צד שלישי

כניסה יחידה (SSO) דרך צד שלישי מאפשרת למשתמש לעבור אימות באמצעות קבוצה אחת של פרטי כניסה בפלטפורמה אחת, ואז לגשת לכמה אפליקציות ואתרים בלי להזין מחדש את פרטי הכניסה. בגלל המורכבות של הטמעת פתרון SSO, חברות רבות בוחרות להשתמש בספק פתרונות חיצוני כדי לשתף את מצב הכניסה בין מקורות שונים. דוגמאות לספקים: Okta, ‏ Ping Identity, ‏ Google Cloud IAM או Microsoft Entra ID.

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

דומיינים מרובים

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

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

הדרכים האפשריות להעברה בתרחיש הזה הן:

• עדכון לשימוש בקובצי Cookie מהדומיין הנוכחי (SameSite): שינוי התשתית של האתר כך שתהליך הכניסה יתארח באותו דומיין (או בתת-דומיין) כמו האתר הראשי, ויוגדרו בו רק קובצי Cookie מהדומיין הנוכחי. יכול להיות שיידרש מאמץ רב יותר, בהתאם לאופן ההגדרה של התשתית.
• שימוש בקבוצות של אתרים קשורים (RWS) וב-Storage Access API‏ (SAA): קבוצות של אתרים קשורים מאפשרות גישה מוגבלת לקובצי Cookie באתרים שונים בין קבוצה קטנה של דומיינים קשורים. כשמשתמשים ב-RWS, לא צריך להציג למשתמש בקשה כשמבקשים גישה לאחסון באמצעות Storage Access API. כך אפשר להשתמש ב-SSO באותם RPs שנמצאים באותו RWS כמו ה-IdP. עם זאת, קבוצת אתרים קשורים תומכת רק בגישה לקובצי Cookie באתרים שונים במספר מוגבל של דומיינים.
• שימוש ב-Web Authentication API: ה-Web Authentication API מאפשר לצדדים מסתמכים (RP) לרשום קבוצה מוגבלת של מקורות קשורים שבהם אפשר ליצור ולהשתמש בפרטי כניסה.
• אם אתם מאמתים משתמשים ביותר מ-5 דומיינים משויכים, כדאי לכם לבדוק את ניהול אישורים מאוחדים (FedCM): FedCM מאפשר לספקי זהויות להסתמך על Chrome כדי לטפל בתהליכים שקשורים לזהויות בלי להסתמך על קובצי Cookie של צד שלישי. במקרה שלכם, 'דומיין הכניסה' יכול לשמש כספק זהויות של FedCM, ואפשר להשתמש בו כדי לאמת משתמשים בדומיינים האחרים.

אימות מהטמעות

נניח ש-iframe של 3-party-app.example מוטמע ב-top-level.example. ב-3-party-app.example, המשתמש יכול להתחבר באמצעות פרטי הכניסה של 3-party-app.example או באמצעות ספק צד שלישי אחר.

המשתמש לוחץ על 'כניסה' ומבצע אימות בחלון הקופץ 3-party-app.example. 3-party-app.exampleהחלון הקופץ מגדיר קובץ Cookie מהדומיין הנוכחי. עם זאת, ה-iframe‏ 3-party-app.example שמוטמע ב-top-level.example מחולק למחיצות ולא יכול לגשת לקובץ ה-Cookie שהוגדר בהקשר של הדומיין הנוכחי ב-3-party-app.example.

אותה בעיה תתרחש כשמשתמש יופנה אוטומטית מ-top-level.example ל-3-party-app.example ובחזרה. קובץ ה-Cookie נכתב בהקשר של צד ראשון באתר 3-party-app.example, אבל הוא מחולק למחיצות ולא ניתן לגשת אליו ב-iframe של 3-party-app.example.

במקרים שבהם המשתמש ביקר במקור המוטמע בהקשר ברמה העליונה, Storage Access API הוא פתרון טוב.

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

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

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

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

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

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

גישה לנתוני משתמשים ושינוי שלהם מהטמעות

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

לדוגמה, משתמש עשוי להתחבר ל-website.example, שמוטמע בה ווידג'ט של subscriptions.example. הווידג'ט הזה מאפשר למשתמשים לנהל את הנתונים שלהם, למשל להירשם לתוכן פרימיום או לעדכן את פרטי החיוב. כדי לשנות את נתוני המשתמש, יכול להיות שהווידג'ט המוטמע יצטרך לגשת לקובצי ה-Cookie שלו בזמן שהוא מוטמע ב-website.example. בתרחיש שבו הנתונים האלה צריכים להיות מבודדים ל-website.example, CHIPS יכול לעזור להבטיח שההטמעה תוכל לגשת למידע שהיא צריכה. עם CHIPS, לווידג'ט שמוטמע ב-subscriptions.example website.example לא תהיה גישה לנתוני המינוי של המשתמש באתרים אחרים.

דוגמה נוספת: סרטון מ-streaming.example מוטמע ב-website.example, ולמשתמש יש מינוי פרימיום ל-streaming.example, והווידג'ט צריך לדעת על כך כדי להשבית את המודעות. אם צריך לגשת לאותו קובץ Cookie בכמה אתרים, כדאי להשתמש ב-Storage Access API אם המשתמש ביקר בעבר ב-streaming.example כאתר ברמה העליונה, וב-Related Website Sets אם קבוצת website.example היא הבעלים של streaming.example.

החל מגרסה Chrome 131, ‏ FedCM משולב עם Storage Access API. במסגרת השילוב הזה, כשהמשתמש מאשר את ההנחיה של FedCM, הדפדפן מעניק לספק הזהויות גישה להטמעה לאחסון לא מחולק.

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

תהליכים אחרים שעוברים המשתמשים

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

ביקורת באתר

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