چه چیزی باعث ایجاد یک تجربه خروج خوب می شود؟، چه چیزی یک تجربه خروج از سیستم را خوب می کند؟

کنجی باهوکس
Kenji Baheux

وقتی کاربری از یک وب‌سایت خارج می‌شود، در واقع نیاز خود را برای خروج کامل از یک تجربه کاربری شخصی‌سازی‌شده ابراز می‌کند. بنابراین، بسیار مهم است که تا حد امکان به مدل ذهنی کاربر پایبند باشید. به عنوان مثال، یک تجربه خروج مناسب باید هر تبی را که کاربر ممکن است قبل از تصمیم به خروج باز کرده باشد، در نظر بگیرد.

کلید یک تجربه عالی خروج از سیستم را می‌توان در ثبات در جنبه‌های بصری و حالت تجربه کاربر خلاصه کرد. این راهنما توصیه‌های مشخصی در مورد آنچه باید به آن توجه کرد و نحوه دستیابی به یک تجربه خوب خروج از سیستم ارائه می‌دهد.

ملاحظات کلیدی

هنگام پیاده‌سازی قابلیت خروج از سیستم در وب‌سایت خود، به جنبه‌های زیر توجه کنید تا از یک فرآیند خروج روان، ایمن و کاربرپسند اطمینان حاصل کنید:

  • تجربه کاربری خروج واضح و یکپارچه : یک دکمه یا لینک خروج واضح و یکپارچه ارائه دهید که به راحتی در سراسر وب‌سایت قابل شناسایی و دسترسی باشد. از استفاده از برچسب‌های مبهم یا پنهان کردن قابلیت خروج در منوها، زیرصفحه‌ها یا سایر مکان‌های مبهم و نامفهوم خودداری کنید.
  • درخواست تأیید: قبل از نهایی کردن فرآیند خروج، یک درخواست تأیید پیاده‌سازی کنید . این کار می‌تواند به جلوگیری از خروج تصادفی کاربران کمک کند و به کاربران اجازه می‌دهد در صورت نیاز به خروج، تجدیدنظر کنند - مثلاً اگر دستگاه خود را با یک رمز عبور قوی یا سایر مکانیسم‌های احراز هویت قفل کنند.
  • مدیریت چندین تب : اگر کاربری چندین صفحه از یک وب‌سایت را در تب‌های مختلف باز کرده باشد، مطمئن شوید که خروج از یک تب، تمام تب‌های باز دیگر از آن وب‌سایت را نیز به‌روزرسانی می‌کند.
  • هدایت به یک صفحه فرود امن : پس از خروج موفقیت‌آمیز، کاربر را به یک صفحه فرود امن هدایت کنید که به وضوح نشان دهد دیگر وارد سیستم نشده است. از هدایت کاربران به صفحاتی که حاوی اطلاعات شخصی هستند، خودداری کنید. به طور مشابه، مطمئن شوید که سایر تب‌ها نیز دیگر حالت ورود به سیستم را نشان نمی‌دهند. همچنین، مطمئن شوید که در حال ایجاد یک تغییر مسیر باز نیستید که مهاجمان بتوانند از آن سوءاستفاده کنند.
  • پاکسازی جلسه : پس از خروج کاربر، هرگونه اطلاعات حساس جلسه کاربر، کوکی‌ها یا فایل‌های موقت مرتبط با جلسه کاربر را به طور کامل حذف کنید. این کار از دسترسی غیرمجاز به اطلاعات کاربر یا فعالیت حساب جلوگیری می‌کند و همچنین مانع از بازیابی صفحات حاوی اطلاعات حساس توسط مرورگر از حافظه‌های پنهان مختلف خود، به ویژه حافظه پنهان back/forward ، می‌شود.
  • مدیریت خطا و بازخورد : در صورت بروز هرگونه مشکل هنگام خروج از سیستم، پیام‌های خطا یا بازخورد واضحی را در اختیار کاربران قرار دهید. در صورت عدم موفقیت فرآیند خروج، آنها را از هرگونه خطرات امنیتی احتمالی یا نشت داده‌ها مطلع کنید.
  • ملاحظات دسترسی : اطمینان حاصل کنید که مکانیزم خروج برای کاربران دارای معلولیت، از جمله افرادی که از فناوری‌های کمکی مانند صفحه‌خوان یا پیمایش صفحه‌کلید استفاده می‌کنند، قابل دسترسی است.
  • سازگاری با مرورگرهای مختلف : قابلیت خروج از سیستم را در مرورگرها و دستگاه‌های مختلف آزمایش کنید تا از عملکرد مداوم و قابل اعتماد آن اطمینان حاصل شود.
  • نظارت و به‌روزرسانی مداوم : به‌طور منظم فرآیند خروج از سیستم را برای یافتن هرگونه آسیب‌پذیری یا حفره امنیتی بالقوه رصد کنید. به‌روزرسانی‌ها و وصله‌های امنیتی را به موقع اجرا کنید تا هرگونه مشکل شناسایی‌شده را برطرف کنید.
  • فدراسیون هویت : اگر کاربر با استفاده از یک هویت فدرال وارد سیستم شده است، بررسی کنید که آیا خروج از ارائه‌دهنده هویت نیز پشتیبانی می‌شود و مورد نیاز است یا خیر. همچنین، اگر ارائه‌دهنده هویت از ورود خودکار پشتیبانی می‌کند، فراموش نکنید که از آن جلوگیری کنید .

انجام می‌دهد

  • اگر به عنوان بخشی از جریان خروج (یا سایر جریان‌های لغو دسترسی)، کوکی روی سرور را نامعتبر می‌کنید، حتماً کوکی را روی دستگاه کاربر نیز حذف کنید.
  • هرگونه داده حساسی که ممکن است روی دستگاه کاربر ذخیره کرده باشید را پاک کنید: کوکی‌ها، localStorage ، sessionStorage ، indexedDB ، CacheStorage و هرگونه محل ذخیره‌سازی داده محلی دیگر.
  • اطمینان حاصل کنید که هر منبعی که حاوی داده‌های حساس است - به ویژه اسناد HTML - با هدر HTTP از نوع Cache-control: no-store برگردانده شود تا مرورگر این منابع را در حافظه دائمی (مثلاً روی دیسک) ذخیره نکند. به طور مشابه، فراخوانی‌های XHR/ fetch که داده‌های حساس را برمی‌گردانند نیز باید هدر HTTP از نوع Cache-Control: no-store را تنظیم کنند تا از هرگونه ذخیره‌سازی در حافظه پنهان جلوگیری شود.
  • مطمئن شوید که هر تب باز شده در دستگاه کاربر، به‌روزرسانی شده و لغو دسترسی سمت سرور در آن فعال باشد.

پاکسازی داده‌های حساس پس از خروج از سیستم

هنگام خروج، پاک کردن داده‌های حساس موقت و ذخیره شده محلی را در نظر بگیرید. تمرکز روی داده‌های حساس از این واقعیت ناشی می‌شود که پاک کردن همه چیز منجر به تجربه کاربری به مراتب بدتری می‌شود زیرا این کاربر ممکن است دوباره برگردد. به عنوان مثال، اگر قرار باشد تمام داده‌های ذخیره شده محلی را پاک کنید، کاربران شما مجبور خواهند بود دوباره درخواست‌های رضایت کوکی را تأیید کنند و فرآیندهای دیگری را طی کنند، گویی که اصلاً از وب‌سایت شما بازدید نکرده‌اند.

نحوه پاک کردن کوکی‌ها

در پاسخ صفحه‌ای که وضعیت خروج از سیستم را تأیید می‌کند، هدرهای HTTP Set-Cookie را پیوست کنید تا هر کوکی مرتبط یا حاوی داده‌های حساس را پاک کند. مقدار expires را روی تاریخی در گذشته دور تنظیم کنید و برای اطمینان، مقدار کوکی را روی یک رشته خالی تنظیم کنید.

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
...

سناریوی آفلاین

اگرچه رویکرد شرح داده شده در بالا برای موارد استفاده عمومی کافی است، اما اگر کاربر آفلاین کار کند، کار نمی‌کند. می‌توانید برای ردیابی وضعیت ورود به سیستم، دو کوکی را در نظر بگیرید: یک کوکی امن فقط HTTPS و یک کوکی معمولی که از طریق جاوا اسکریپت قابل دسترسی باشد. اگر کاربر شما سعی دارد در حالت آفلاین از سیستم خارج شود، می‌توانید کوکی جاوا اسکریپت را پاک کنید و در صورت امکان سایر عملیات پاکسازی را ادامه دهید. اگر یک سرویس ورکر دارید، می‌توانید از API Background Fetch نیز برای امتحان مجدد درخواست پاک کردن وضعیت روی سرور، زمانی که کاربر بعداً آنلاین شد، استفاده کنید.

نحوه تمیز کردن فضای ذخیره‌سازی

در پاسخ صفحه‌ای که وضعیت خروج از سیستم را تأیید می‌کند، مراقب باشید که داده‌های حساس را از انبارهای داده مختلف پاک کنید:

  • sessionStorage : اگرچه این اطلاعات با پایان یافتن جلسه کاربر با وب‌سایت شما پاک می‌شود، اما هنگام خروج کاربر از سیستم، به صورت پیشگیرانه داده‌های حساس را پاک کنید، برای مواقعی که کاربر فراموش کند تمام تب‌های باز شده در وب‌سایت شما را ببندد.

    // Remove sensitive data from sessionStorage
sessionStorage.removeItem('sensitiveSessionData1');
// ...

// Or if everything in sessionStorage is sensitive, clear it all
sessionStorage.clear();

  • APIهای localStorage ، indexedDB ، Cache / 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 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 هیچ چیز حساسی را ذخیره نمی‌کند.
  • حافظه پنهان Back/forward : به طور مشابه، اگر توصیه‌های مربوط به Cache-control: no-store و پاک کردن کوکی‌های حساس (به عنوان مثال، کوکی‌های امن HTTPS-only مربوط به احراز هویت) را هنگام خروج کاربران رعایت کرده باشید، دیگر نیازی به نگرانی در مورد حفظ داده‌های حساس در حافظه پنهان back/forward نخواهید داشت. در واقع، ویژگی حافظه پنهان back/forward در صورت مشاهده یک یا چند مورد از سیگنال‌های زیر، صفحات با مبدا یکسان که با هدر HTTP Cache-control: no-store ارائه شده‌اند را حذف می‌کند:
    • یک یا چند کوکی امنِ فقط HTTPS تغییر یافته یا حذف شده‌اند.
    • یک یا چند پاسخ برای فراخوانی‌های XHR/ fetch - که توسط صفحه صادر شده است - شامل هدر HTTP با عنوان Cache-control: no-store بوده است.

تجربه کاربری یکسان در تب‌های مختلف

ممکن است کاربران شما قبل از تصمیم به خروج، تب‌های زیادی را برای وب‌سایت شما باز کرده باشند. تا آن زمان، ممکن است تب‌های دیگر یا حتی پنجره‌های مرورگر دیگر را فراموش کرده باشند. بهتر است از تکیه بر کاربران برای بستن تمام تب‌ها و پنجره‌های مربوطه خودداری کنید. در عوض، با اطمینان از اینکه وضعیت ورود کاربر در بین تب‌ها یکسان است، یک موضع پیشگیرانه اتخاذ کنید.

چگونه

برای دستیابی به یک حالت ورود به سیستم ثابت در بین تب‌ها، استفاده از ترکیبی از رویدادهای pageshow / pagehide و API کانال پخش (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.
    // ...
  }
}

نتیجه‌گیری

با پیروی از راهنمایی‌های این سند، شما قادر خواهید بود یک تجربه کاربری عالی برای خروج از سیستم طراحی کنید که از خروج‌های ناخواسته جلوگیری کرده و از اطلاعات شخصی کاربر محافظت کند.