אנחנו ב-Chrome מציעים חוויה חדשה לבחירת המשתמש עם קובצי cookie של צד שלישי. אתם צריכים להכין את האתר למשתמשים שבוחרים לגלוש בלי קובצי Cookie של צד שלישי.
בדף הזה מפורט מידע על תרחישי הזהות שסביר להניח שיושפע מהבעיה, וכן הפניות לפתרונות אפשריים.
אם האתר שלכם מטפל רק בתהליכים באותו דומיין ובתת-דומיינים, כמו publisher.example ו-login.publisher.example, הוא לא ישתמש בקובצי cookie בכמה אתרים, ותהליך הכניסה לא אמור להיות מושפע משינויים בקובצי cookie של צד שלישי.
עם זאת, אם האתר שלכם משתמש בדומיין נפרד להתחברות, למשל באמצעות כניסה באמצעות חשבון Google או כניסה באמצעות חשבון Facebook, או אם האתר צריך לשתף את אימות המשתמשים בין כמה דומיינים או תתי-דומיינים, יכול להיות שתצטרכו לבצע שינויים באתר כדי להבטיח מעבר חלק מהפסקת השימוש בקובצי cookie בכמה אתרים.
תהליכים נפוצים שעוברים המשתמשים
בעבר, תהליכי עבודה רבים של אימות זהות הסתמכו על קובצי cookie של צד שלישי. בטבלה מפורטים כמה תהליכי שימוש נפוצים ופתרונות פוטנציאליים לכל אחד מהם, שלא תלויים בקובצי cookie של צד שלישי. בקטעים הבאים נסביר את הנימוקים להמלצות האלה.
ממשקי API חלופיים מומלצים לתרחישים נפוצים לדוגמה
| תהליך שעובר המשתמש | ממשקי API מומלצים |
|---|---|
| כניסה באמצעות חשבון ברשת חברתית |
לספקי זהויות: מטמיעים את FedCM לגורמים מסתמכים על: פונים לספק הזהויות |
| יציאה מהחשבון בערוץ הקדמי | לספקי זהויות: מטמיעים את FedCM |
|
עבור ספקי זהויות או פתרונות מותאמים אישית: קבוצות של אתרים קשורים |
|
| ניהול פרופיל המשתמש |
Storage Access API קבוצות של אתרים קשורים CHIPS FedCM |
|
Storage Access API קבוצות של אתרים קשורים CHIPS FedCM |
|
| אימות |
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 מהדומיין הנוכחי ('באותו אתר'): שינוי התשתית של האתר כך שזרימת הכניסה תתארח באותו דומיין (או תת-דומיין) כמו האתר הראשי, שבו ייכללו רק קובצי cookie מהדומיין הנוכחי. יכול להיות שתצטרכו להשקיע יותר מאמץ, בהתאם לאופן שבו התשתית מוגדרת.
- שימוש בקבוצות של אתרים קשורים (RWS) וב-Storage Access API (SAA): RWS מאפשר גישה מוגבלת לכמה קובצי cookie באתרים שונים בין קבוצה קטנה של דומיינים קשורים. כשמשתמשים ב-RWS, אין צורך לבקש מהמשתמשים אישור כשמבקשים גישה לאחסון באמצעות Storage Access API. כך אפשר להשתמש בכניסה יחידה (SSO) בגורמים המוגבלים (RP) שנמצאים באותו RWS כמו ה-IdP. עם זאת, RWS תומך בגישה לקובצי 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 Premium. הווידג'ט צריך לדעת על כך כדי להשבית את המודעות. אם צריך לגשת לאותו קובץ cookie בכמה אתרים, כדאי להשתמש ב-Storage Access API אם המשתמש ביקר בעבר ב-streaming.example בתור ברמה העליונה, ובקבוצות של אתרים קשורים אם הקבוצה של website.example היא הבעלים של streaming.example.
החל מגרסה 131 של Chrome, FedCM משולב עם Storage Access API. כשהמשתמש מאשר את ההנחיה של FedCM, הדפדפן מעניק ל-IdP המוטמע גישה לאחסון ללא מחיצות.
לקבלת מידע נוסף על איזה API לבחור כדי לטפל בתהליך מסוים שעובר המשתמש עם תוכן מוטמע, אפשר לעיין במדריך ההטמעה.
התנתקות מהערוץ קדמי
יציאה מהחשבון בערוץ חזיתי היא מנגנון שמאפשר למשתמש לצאת מכל האפליקציות הקשורות כשהוא יוצא מחשבון בשירות אחד. כדי לבצע יציאה מהחשבון בערוץ קדמי ב-OIDC, ה-IdP צריך להטמיע כמה iframe של צד נסמך (RP) שמסתמכים על קובצי ה-cookie של ה-RP.
אם הפתרון שלכם מסתמך על ספק זהויות, יכול להיות שתצטרכו לבצע שינויים קלים (כמו שדרוג ספרייה). לקבלת הנחיות נוספות, פנו לספק הזהויות.
כדי לטפל בתרחיש לדוגמה הזה, FedCM ניסו את התכונה logoutRPs. כך ה-IdP יכול היה לגרום ליציאה של כל RP שהמשתמש אישר בעבר את התקשורת בינו לבין ה-IdP. התכונה הזו כבר לא זמינה, אבל מומלץ לעיין בהצעה הראשונית ולשלוח לנו משוב אם התכונה הזו מעניינת אותך או אם יש לך צורך בה.
תהליכים אחרים שעוברים המשתמשים
התהליכים שעוברים המשתמשים שלא מסתמכים על קובצי cookie של צד שלישי לא אמורים להיות מושפעים משינויים באופן הטיפול של Chrome בקובצי cookie של צד שלישי. הפתרונות הקיימים, כמו כניסה, יציאה או שחזור חשבון בהקשר של צד ראשון, 2FA, אמורים לפעול כצפוי. נקודות חולשה פוטנציאליות כבר תוארו קודם. מידע נוסף על ממשק API ספציפי זמין בדף הסטטוס של ה-API. מדווחים על תקלות ב-goo.gle/report-3pc-broken. אתם יכולים גם לשלוח טופס משוב או לדווח על בעיה ב-GitHub דרך מאגר התמיכה למפתחים של ארגז החול לפרטיות.
בדיקת האתר
אם באתר שלכם מוטמע אחד מהתהליכים שעוברים המשתמשים שמתוארים במדריך הזה, עליכם לוודא שהאתרים שלכם מוכנים: בודקים את האתר כדי לזהות שימוש בקובצי cookie של צד שלישי, בודקים אם יש שיבושים ומעבירים את האתרים לפתרונות המומלצים.