אנחנו ב-Chrome מציעים חוויה חדשה לבחירת המשתמש עם קובצי cookie של צד שלישי. עליכם להכין את האתר למשתמשים שבוחרים לגלוש ללא קובצי Cookie של צד שלישי.
בדף הזה תמצאו מידע על תרחישי הכניסה שסביר להניח מושפעות מכך, וגם התייחסויות לפתרונות אפשריים.
אם האתר שלכם מטפל רק בתהליכים בתוך אותו דומיין ותת-דומיינים, למשל
בתור publisher.example ו-login.publisher.example, לא ייעשה שימוש במעבר בין אתרים
לא צפויים שינויים בקובצי cookie של צד שלישי ובתהליך הכניסה שלכם.
עם זאת, אם האתר משתמש בדומיין נפרד להתחברות, כמו כניסה באמצעות חשבון Google או Facebook Login, אחרת צריך לשתף משתמש באתר לבצע אימות בכמה דומיינים או תת-דומיינים, יש סיכוי תצטרכו לבצע שינויים באתר כדי להבטיח מעבר חלק מ- קובצי Cookie בין אתרים.
בדיקת התהליכים שעוברים המשתמשים שקשורים לזהות
הדרך הטובה ביותר לבדוק אם תהליך הכניסה מושפע מקובץ cookie של צד שלישי הוא לעבור בתהליך הרישום, שחזור הסיסמה, הכניסה מתבצעת יציאה עם הסימון לבדיקת קובצי cookie של צד שלישי מופעל.
זו רשימת משימות שצריך לבדוק אחרי שמגבילים צדדים שלישיים קובצי Cookie:
- רישום משתמשים: יצירת חשבון חדש פועלת כצפוי. אם משתמשים ספקי זהויות מצד שלישי, ודאו שהרישום של חשבונות חדשים פועל לכל שילוב,
- שחזור סיסמה: שחזור הסיסמאות פועל כצפוי, דרך ממשק המשתמש באינטרנט, אל CAPTCHA, כדי לקבל את אימייל שחזור הסיסמה.
- כניסה: תהליך הכניסה פועל באותו דומיין ובזמן ניווט לדומיינים אחרים. חשוב לבדוק כל שילוב של תהליך הכניסה.
- יציאה: תהליך היציאה פועל כצפוי, והמשתמש נשאר לאחר תהליך היציאה.
כמו כן, כדאי לבדוק שתכונות אחרות באתר שמחייבות כניסה של משתמש ממשיכות להופיע לפעול ללא קובצי cookie מאתרים שונים, במיוחד אם הם כוללים טעינה בין אתרים. לדוגמה, אם משתמשים ב-CDN כדי לטעון תמונות פרופיל של משתמשים, כדי להבטיח שזה עדיין יפעל. אם יש לכם התהליכים החשובים שעוברים המשתמשים, כמו מוגבל בזמן הכניסה, כדי לוודא שהם ימשיכו לפעול.
בקטעים הבאים תמצאו מידע ספציפי יותר על תהליכים אלו עשויה להיות מושפעת.
זהות מאוחדת
לחצני כניסה כמו כניסה באמצעות חשבון Google, Facebook Login וגם התחברות באמצעות 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: Federated Credentials Management (FedCM) מאפשר לספקי זהויות להסתמך על Chrome לטיפול בתהליכים הקשורים לזהות, שמחייב קובצי Cookie של צד שלישי. במקרה שלך, "דומיין לכניסה" יכול לפעול בתור ספק הזהויות של FedCM וישמש לאימות משתמשים דומיינים.
דומיינים מרובים
אם לעסק יש מספר מוצרים שמתארחים בדומיינים או בתת-דומיינים שונים, לשתף את הסשן של המשתמש במוצרים האלה, תרחיש שעשוי מחייבים גישה לקובצי cookie של צד שלישי בין דומיינים מרובים.
בתרחיש הזה, במקרים רבים אירוח כל המוצרים באותו דומיין הן לא פרקטיות. פתרונות אפשריים במקרה זה הם:
- שימוש בקבוצות של אתרים קשורים: כשנדרשת גישה לקובצי Cookie של אתרים שונים בין קבוצה קטנה של דומיינים קשורים.
- משתמשים ב-Federation Credential Management (FedCM): כשמספר גדול, אפשר להשתמש בדומיין כניסה נפרד כדי להזדהות לספק ולאמת משתמשים באתרים באמצעות FedCM.
פתרונות כניסה לחשבון
כניסה יחידה (SSO) של צד שלישי
עקב המורכבות של הטמעת פתרון SSO, חברות רבות בוחרות להצטרף באמצעות ספק פתרונות של צד שלישי, כדי לשתף את מצב הכניסה בין מקורות. דוגמאות לספקים כוללות את Okta, Ping Identity, Google Cloud IAM או Microsoft Entra ID.
במקרה של שימוש בספק צד שלישי, הגישה הטובה ביותר היא לבקש עזרה לספק לגבי האופן שבו שינויים בקובצי Cookie של צד שלישי ישפיעו על הפתרון, איזו גישה הם ממליצים על השירות שלהם.
פתרונות SSO בקוד פתוח
חברות רבות שמתחזקות פתרונות SSO משלהן יעשו זאת באמצעות בהתאם לתקנים המקובלים בתחום, כגון OpenID Connect, OAuth או SAML, או הגדרות פתוחות בפרויקטי מקור, כמו Keycloak, WSO2, Auth.js או Hydra.
מומלץ לבדוק את המסמכים של הספק כדי להבין איך עשויים להשפיע על הפתרון שלהם, ועל נתיב ההעברה הטוב ביותר לפתרון הספציפי הזה.
פתרונות פנימיים בהתאמה אישית
אם פתרון הכניסה שלכם מתאים לאחד מהתרחישים לדוגמה שצוינו קודם, והוא מפותח להתכונן להוצאה משימוש בהדרגה של קובצי Cookie של צד שלישי, להסביר מפורט כיצד לבדוק את הקוד ולהתכונן לשינויים בקובצי cookie של צד שלישי.
נקיטת פעולה עכשיו!
אם אחד מהתרחישים לדוגמה מתאים לאתר שלכם, יש כמה פתרונות זמין לטיפול בכל השפעה אפשרית, החל מהעברת תהליך האימות אל בדומיין הראשי כך שהוא ישתמש רק בקובצי cookie מהדומיין הנוכחי, באמצעות קבוצות של אתרים קשורים כדי לאפשר שיתוף קובצי cookie בין מספר קטן או שימוש בניהול פרטי כניסה של איחוד.
הזמן לבדוק את השירות שלך ולהתכונן לקובץ ה-cookie של הצד השלישי הם עכשיו!