מה הופך חוויית יציאה מהחשבון לטובה?

Kenji Baheux

יציאה

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

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

שיקולים מרכזיים

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

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

משימות

• אם ביטלתם קובץ cookie בשרת כחלק מתהליך יציאה מהחשבון (או בתהליכים אחרים של ביטול גישה), הקפידו למחוק את קובץ ה-cookie גם במכשיר של המשתמש.
• ניקוי מידע אישי רגיש שאחסנתם במכשיר של המשתמש: קובצי Cookie, localStorage, sessionStorage, indexedDB, CacheStorage וכל מאגר נתונים מקומי אחר.
• מוודאים שמשאבים שמכילים מידע אישי רגיש – במיוחד מסמכי HTML – מוחזרים עם כותרת ה-HTTP Cache-control: no-store, כדי שהדפדפן לא יאחסן את המשאבים האלה באחסון קבוע (למשל, בדיסק). באופן דומה, קריאות XHR/fetch שמחזירות מידע אישי רגיש צריכות גם להגדיר את כותרת ה-HTTP Cache-Control: no-store כדי למנוע שמירה במטמון.
• עליך לוודא שכל הכרטיסיות הפתוחות במכשיר של המשתמש מעודכנות עם ביטולי הגישה בצד השרת.

ניקוי מידע אישי רגיש אחרי שיוצאים מהחשבון

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

איך לנקות קובצי Cookie

בתגובה שמאשרת את הסטטוס של 'יציאה מהחשבון', מצרפים Set-Cookie כותרות HTTP כדי למחוק כל קובץ cookie שקשור למידע אישי רגיש או מכיל מידע כזה. מגדירים את הערך expires כתאריך שחל בעבר הרחוק, ומגדירים את ערך קובץ ה-cookie כמחרוזת ריקה כדי לקבל מדידה טובה.

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

Set-Cookie: sensitivecookie1=; expires=Thu, 01 Jan 1970 00:00:00 GMT; secure
Set-Cookie: sensitivecookie2=; expires=Thu, 01 Jan 1970 00:00:00 GMT; secure
...

תרחיש שימוש במצב אופליין

הגישה שמתוארת למעלה מתאימה בתרחישים לדוגמה, אבל היא לא עובדת אם המשתמש עובד במצב אופליין. כדאי לדרוש שני קובצי cookie כדי לעקוב אחרי מצב הכניסה לחשבון: קובץ cookie מאובטח אחד מסוג HTTPS בלבד, וקובץ cookie רגיל אחד שניתן לגשת אליו באמצעות JavaScript. אם המשתמש מנסה לצאת מהחשבון כשהוא במצב אופליין, אפשר למחוק את קובץ ה-cookie של JavaScript ולהמשיך בפעולות ניקוי אחרות, אם אפשר. אם יש לכם קובץ שירות (service worker) כדאי גם לנצל את ה-Background Fetch API כדי לנסות לשלוח שוב בקשה לניקוי המצב בשרת כשהמשתמש יהיה מחובר לאינטרנט במועד מאוחר יותר.

איך מפנים מקום באחסון

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

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

  // Remove sensitive data from sessionStorage
  sessionStorage.removeItem('sensitiveSessionData1');
  // ...
  
  // Or if everything in sessionStorage is sensitive, clear it all
  sessionStorage.clear();
  

• ממשקי API של localStorage, indexedDB, מטמון/Service Worker: כשהמשתמש יוצא מהחשבון, צריך לנקות מידע אישי רגיש שאחסנתם באמצעות ממשקי ה-API האלה, כי הנתונים האלה יישמרו בכל הסשנים.

  // Remove sensitive data from localStorage:
  localStorage.removeItem('sensitiveData1');
  // ...
  
  // Or if everything in localStorage is sensitive, clear it all:
  localStorage.clear();
  

  // Delete sensitive object stores in indexedDB:
  const name = 'exampleDB';
  const version = 1;
  const request = indexedDB.open(name, version);
  
  request.onsuccess = (event) => {
    const db = request.result;
    db.deleteObjectStore('sensitiveStore1');
    db.deleteObjectStore('sensitiveStore2');
  
    // ...
  
    db.close();
  }
  

  // Delete sensitive resources stored via the Cache API:
  caches.open('cacheV1').then((cache) => {
    await cache.delete("/personal/profile.png");
  
    // ...
  }
  
  // Or better yet, clear a cache bucket that contains sensitive resources:
  caches.delete('personalizedV1');
  

איך לנקות מטמון

• מטמון HTTP: כל עוד מגדירים Cache-control: no-store במשאבים עם מידע אישי רגיש, במטמון ה-HTTP לא יישמר מידע רגיש.
• מטמון לדף הקודם/הבא: באופן דומה, אם פעלתם בהתאם להמלצות לגבי Cache-control: no-store ולגבי ניקוי קובצי cookie רגישים (למשל, קובצי cookie מאובטחים הקשורים לאימות בלבד) כשהמשתמשים יוצאים מהחשבון, לא צריך לחשוש שמידע אישי רגיש יישמר במטמון לדף הקודם/הבא. אכן, התכונה 'מטמון לדף הקודם/הבא' תסיר דפים מאותו מקור שמוצגים עם כותרת HTTP Cache-control: no-store אם היא תזוהה או יותר מהאותות הבאים:
  • לפחות אחד מקובצי ה-cookie מאובטחים מסוג HTTPS בלבד השתנה או נמחק.
  • תגובה אחת או יותר לקריאות XHR/fetch – שהונפקו על ידי הדף – כללה את כותרת ה-HTTP Cache-control: no-store.

חוויית משתמש עקבית בכרטיסיות

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

כיצד לבצע

כדי לשמור על מצב כניסה עקבי בכל הכרטיסיות, כדאי להשתמש בשילוב של אירועי pageshow מתוך pagehide עם Broadcast Channel API.

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

  window.addEventListener('pageshow', (event) => {
    if (event.persisted && !document.cookie.match(/my-cookie)) {
      // The user has logged out.
      // Force a reload, or otherwise clear sensitive information right away.
      body.innerHTML = '';
      location.reload();
    }
  });
  

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

  // Upon logout, broadcast new login state so that other tabs can clean up too:
  const bc = new BroadcastChannel('login-state');
  bc.postMessage('logged out');
  
  // [...]
  const bc = new BroadcastChannel('login-state');
  bc.onMessage = (msgevt) => {
    if (msgevt.data === 'logged out') {
      // Clean up, reload or navigate to the sign-out page.
      // ...
    }
  }
  

סיכום

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