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

Kenji Baheux
Kenji Baheux

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

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

שיקולים עיקריים

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

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

DOs

  • אם מבטלים את התוקף של קובץ 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-only וקובץ 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();

  • ‫localStorage, ‏ indexedDB, ‏ Cache/Service Worker APIs: כשמשתמש מתנתק, צריך לנקות את כל הנתונים הרגישים שאולי שמרתם באמצעות ממשקי ה-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 with 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 event: כשמתרחש אירוע 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();
  }
});

  • ‫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.
    // ...
  }
}

סיכום

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