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

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

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

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 מאובטחים מסוג HTTPS בלבד) כשמשתמשים יוצאים מהחשבון, אין צורך לחשוש שמידע אישי רגיש יישמר במטמון לדף הקודם/הבא. אכן, התכונה 'מטמון לדף הקודם/הבא' תוציא דפים מאותו מקור שמוצגים עם כותרת 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();
    }
  });
  

• The Broadcast Channel 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.
      // ...
    }
  }
  

סיכום

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