לקובצי cookie של צד שלישי יש שימושים חוקיים, אך הם מאפשרים גם מעקב בין אתרים. ב-Chrome מתכננים להגביל קובצי Cookie של צד שלישי ל-1% מהמשתמשים מהרבעון הראשון של 2024 כדי לאפשר בדיקות, ואחר כך להוציא משימוש קובצי Cookie של צד שלישי ל-100% מהמשתמשים בתחילת 2025, תוך התייחסות לבעיות נוספות שקשורות לתחרות של רשות התחרות והשווקים (CMA) בבריטניה. אם באתר שלכם יש תהליך כניסה שמסתמך על קובצי cookie של צד שלישי, יכול להיות שהוא יושפע מהשינוי הזה. עליך לוודא שהאתר שלך מוכן.
בדף הזה מופיעים מידע על תרחישי הכניסה שסביר להניח שיושפעו, והפניות לפתרונות אפשריים.
אם האתר שלכם מטפל בזרימות רק בתוך אותו דומיין ותת-דומיינים, כמו publisher.example ו-login.publisher.example, הוא לא ישתמש בקובצי cookie בין אתרים, ושירות הכניסה לא צפוי להיות מושפע מהביטול ההדרגתי.
עם זאת, אם האתר משתמש בדומיין נפרד לצורך התחברות, כמו כניסה באמצעות Google או Facebook Login, או אם האתר צריך לשתף את אימות המשתמשים בכמה דומיינים או תת-דומיינים, ייתכן שתצטרכו לבצע שינויים באתר כדי להבטיח מעבר חלק מקובצי cookie בין אתרים.
בדיקת התהליכים שקשורים לזהות
הדרך הטובה ביותר לבדוק אם תהליך הכניסה לחשבון מושפע מהשלב הזה של שימוש בקובצי cookie של צד שלישי הוא לבצע את תהליך הרישום, שחזור הסיסמה, הכניסה והיציאה, כאשר מופעל הסימון של בדיקת הפסקת ההדרגתיות של קובצי cookie של צד שלישי.
זוהי רשימה של דברים שצריך לבדוק לאחר שהגבלת את קובצי ה-cookie של צד שלישי:
- רישום משתמש: יצירת חשבון חדש פועלת כצפוי. אם אתם משתמשים בספקי זהויות של צד שלישי, כדאי לוודא שהרישום של חשבונות חדשים מתאים לכל שילוב.
- שחזור סיסמה: שחזור הסיסמה פועל כצפוי, מממשק המשתמש באינטרנט, מקובצי CAPTCHA ועד לקבלת האימייל לשחזור הסיסמה.
- כניסה: תהליך הכניסה פועל באותו דומיין וכשמנווטים לדומיינים אחרים. חשוב לבדוק כל שילוב של כניסה לחשבון.
- יציאה: תהליך היציאה מהחשבון פועל כצפוי, והמשתמש נשאר מנותק אחרי תהליך היציאה.
כדאי גם לבדוק שתכונות אחרות באתר שמחייבות כניסה של משתמשים ימשיכו לפעול בלי קובצי Cookie מאתרים, במיוחד אם הם כוללים טעינה של משאבים בין אתרים. לדוגמה, אם אתם משתמשים ב-CDN כדי לטעון תמונות פרופיל של משתמשים, ודאו שזה עדיין פועל. אם יש מסלולים קריטיים שעוברים המשתמשים, כמו תשלום בקופה, רק לאחר כניסה לחשבון, ודאו שהם ממשיכים לפעול.
בקטעים הבאים תמצאו מידע ספציפי על ההשפעה האפשרית על תהליכי העבודה האלה.
זהות מאוחדת
לחצני כניסה כמו Sign in with Google, Facebook Login ו-Log in with Twitter הם סימן ברור לכך שהאתר שלכם משתמש בספק זהויות מאוחד. מכיוון שלכל ספק זהויות מאוחד יש הטמעה משלו, הפתרון הטוב ביותר הוא לבדוק את התיעוד של הספק או לפנות אליו לקבלת הנחיות נוספות.
אם אתם משתמשים בספרייה של פלטפורמת JavaScript לכניסה באמצעות חשבון Google שהוצאה משימוש, תוכלו למצוא מידע על המעבר לספרייה החדשה יותר של Google Identity Services לצורך אימות והרשאה.
רוב האתרים שמשתמשים בספרייה החדשה יותר של Google Identity Services מוכנים להוצאה משימוש של קובצי Cookie של צד שלישי, כי הספרייה תעבור באופן שקט לשימוש ב-FedCM לצורך תאימות. מומלץ לבדוק את האתר כאשר מופעל סימון הבדיקה ההדרגתית של קובצי ה-cookie של צד שלישי, ואם צריך, להשתמש ברשימת המשימות להעברה של FedCM כדי להתכונן לכך.
דומיין נפרד לכניסה
אתרים מסוימים משתמשים בדומיין אחר רק כדי לאמת משתמשים שלא מתאימים לקובצי cookie של אותו אתר, כמו אתר שמשתמש ב-example.com עבור האתר הראשי ו-login.example לתהליך ההתחברות, דבר שעשוי לחייב גישה לקובצי cookie של צד שלישי כדי לוודא שהמשתמש מאומת בשני הדומיינים.
נתיבי ההעברה האפשריים לתרחיש הזה הם:
- עדכון לשימוש בקובצי cookie מאינטראקציה ישירה ("אותו אתר"): שינוי התשתית של האתר כך שתהליך ההתחברות יתארח באותו דומיין (או תת-דומיין) כמו האתר הראשי, שבו ייעשה שימוש רק בקובצי cookie של הדומיין. יכול להיות שיהיה צורך במאמץ רב יותר, בהתאם לאופן שבו התשתית מוגדרת.
- שימוש בקבוצות של אתרים קשורים (RWS): קבוצות של אתרים קשורים מאפשרות גישה מוגבלת לקובצי cookie באתרים שונים בין קבוצה קטנה של דומיינים קשורים. RWS הוא API לארגז חול לפרטיות שמיועד לתמוך בתרחיש לדוגמה הזה. עם זאת, RWS תומך בגישה לקובצי cookie בין אתרים רק במספר מוגבל של דומיינים.
- אם אתם מאמתים משתמשים ביותר מ-5 דומיינים משויכים, כדאי לעיין במאמר FedCM: ניהול פרטי כניסה מאוחדים (FedCM) מאפשר לספקי זהויות להסתמך על Chrome כדי לטפל בתהליכים שקשורים לזהויות, בלי לדרוש קובצי cookie של צד שלישי. במקרה שלכם, 'דומיין הכניסה' יכול לשמש כספק הזהויות של FedCM ולשמש לאימות משתמשים בדומיינים האחרים שלכם.
דומיינים מרובים
אם לעסק יש כמה מוצרים שמתארחים בדומיינים או בתת-דומיינים שונים, יכול להיות שהלקוח ירצה לשתף את הסשן של המשתמש במוצרים האלה – תרחיש שעשוי לדרוש גישה לקובצי cookie של צד שלישי בין מספר דומיינים.
בתרחיש הזה, אירוח כל המוצרים באותו דומיין הוא לעיתים קרובות לא פרקטי. פתרונות אפשריים במקרה הזה הם:
- שימוש בקבוצות של אתרים קשורים: כשנדרשת גישה לקובצי cookie בין אתרים בין קבוצה קטנה של דומיינים קשורים.
- שימוש בניהול פרטי כניסה לאיחוד (FedCM): כשמספר הדומיינים גדול, אפשר להשתמש בדומיין נפרד לכניסה בתור ספק זהויות ולאמת משתמשים בכל האתרים שלכם באמצעות FedCM.
פתרונות כניסה
כניסה יחידה (SSO) של צד שלישי
בגלל המורכבות של הטמעת פתרון SSO, חברות רבות בוחרות להשתמש בספק פתרונות של צד שלישי כדי לשתף את מצב הכניסה בין מספר מקורות. דוגמאות לספקים: Okta, Ping Identity, Google Cloud IAM או מזהה Microsoft Entra.
כאשר משתמשים בספק צד שלישי, הדרך הטובה ביותר היא לבקש מהספק הנחיות לגבי ההשפעה ההדרגתית של קובצי cookie של צד שלישי על הפתרון ואיזו גישה הוא ממליץ עליו בשירות שלו.
פתרונות SSO בקוד פתוח
הרבה חברות שמתחזקות פתרונות SSO משלהן עושות זאת באמצעות תקנים המקובלים בתחום, כמו OpenID Connect, OAuth או SAML, או פרויקטים מבוססים של קוד פתוח, כמו Keycloak, WSO2, Auth.js או Hydra.
מומלץ לעיין במסמכי התיעוד של הספק כדי להבין איך ביטול ההדרגתיות של קובצי ה-cookie עשוי להשפיע על הפתרון שלו, ומהו נתיב ההעברה הטוב ביותר לפתרון הספציפי הזה.
פתרונות פנימיים בהתאמה אישית
אם פתרון הכניסה שלכם נכלל בתרחישי השימוש הקודמים, והוא מובנה באופן פנימי, במאמר הכנה להוצאה משימוש של קובצי Cookie של צד שלישי תוכלו לקרוא בפירוט רב יותר איך לבדוק את הקוד ולהתכונן לקראת הסגירה ההדרגתית של קובצי ה-Cookie של צד שלישי.
נקוט פעולה עכשיו!
אם האתר שלכם שייך לאחד מהתרחישים לדוגמה, יש כמה פתרונות שיכולים לטפל בכל השפעה אפשרית, החל מהעברת תהליך האימות לדומיין הראשי כך שישתמש רק בקובצי cookie מהדומיין הנוכחי, באמצעות קבוצות של אתרים קשורים כדי לאפשר שיתוף קובצי cookie בין מספר קטן של דומיינים או באמצעות ניהול פרטי הכניסה של האיחוד.
עכשיו עליכם לבדוק את השירות שלכם ולהתכונן לשלב של קובצי ה-cookie של צד שלישי.