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