ما الذي يجعل تجربة تسجيل الخروج جيدة؟

Kenji Baheux
Kenji Baheux

عندما يسجّل المستخدم خروجه من موقع إلكتروني، يكون بذلك يعبّر عن حاجته إلى الخروج تمامًا من تجربة المستخدم المخصّصة. لذلك، من المهم الالتزام بالنموذج الذهني للمستخدم قدر الإمكان. على سبيل المثال، يجب أن تأخذ تجربة تسجيل الخروج المناسبة في الاعتبار أيضًا أي علامات تبويب ربما فتحها المستخدم قبل أن يقرر تسجيل الخروج.

يمكن تلخيص مفتاح تجربة تسجيل الخروج الرائعة في الحفاظ على الاتساق في جميع الجوانب المرئية وجوانب الحالة لتجربة المستخدم. يقدّم هذا الدليل نصائح ملموسة حول ما يجب الانتباه إليه وكيفية تقديم تجربة تسجيل خروج جيدة.

الاعتبارات الأساسية

عند تنفيذ وظيفة تسجيل الخروج على موقعك الإلكتروني، يُرجى الانتباه إلى الجوانب التالية لضمان عملية تسجيل خروج سلسة وآمنة وسهلة الاستخدام:

  • تجربة مستخدم واضحة ومتّسقة لتسجيل الخروج: يجب توفير زر أو رابط واضحَين وظاهرَين باستمرار لتسجيل الخروج، ويسهل التعرّف عليهما والوصول إليهما في جميع أنحاء الموقع الإلكتروني. تجنَّب استخدام تصنيفات غامضة أو إخفاء وظيفة تسجيل الخروج في قوائم أو صفحات فرعية أو مواقع أخرى غير بديهية.
  • طلب التأكيد: يجب تنفيذ طلب التأكيد قبل إكمال عملية تسجيل الخروج. يمكن أن يساعد ذلك في منع المستخدمين من تسجيل الخروج عن طريق الخطأ، كما يتيح لهم إعادة التفكير في ما إذا كانوا بحاجة إلى تسجيل الخروج فعلاً، مثلاً إذا كانوا يقفلون أجهزتهم بانتظام باستخدام كلمة مرور قوية أو آلية مصادقة أخرى.
  • التعامل مع علامات تبويب متعددة: إذا فتح المستخدم عدة صفحات من الموقع الإلكتروني نفسه في علامات تبويب مختلفة، تأكَّد من أنّ تسجيل الخروج من علامة تبويب واحدة يؤدي إلى تعديل جميع علامات التبويب الأخرى المفتوحة من هذا الموقع الإلكتروني أيضًا.
  • إعادة التوجيه إلى صفحة مقصودة آمنة: بعد تسجيل الخروج بنجاح، أعِد توجيه المستخدم إلى صفحة مقصودة آمنة توضّح بشكلٍ واضح أنّه لم يعُد مسجّلاً الدخول. تجنَّب إعادة توجيه المستخدمين إلى صفحات تتضمّن أي معلومات مخصّصة. وبالمثل، تأكَّد من أنّ علامات التبويب الأخرى لم تعُد تعرض حالة تسجيل الدخول أيضًا. تأكَّد أيضًا من أنّك لا تنشئ عملية إعادة توجيه مفتوحة يمكن للمهاجمين الاستفادة منها.
  • تنظيف الجلسة: بعد تسجيل خروج المستخدم، يجب إزالة أي بيانات حساسة لجلسة المستخدم أو ملفات تعريف الارتباط أو الملفات المؤقتة المرتبطة بجلسة المستخدم بشكل كامل. يمنع ذلك الوصول غير المصرّح به إلى معلومات المستخدم أو نشاط الحساب، كما يمنع المتصفّح من استعادة الصفحات التي تتضمّن معلومات حسّاسة من ذاكرات التخزين المؤقت المختلفة، وخاصةً ذاكرة التخزين المؤقت للصفحات السابقة/التالية.
  • التعامل مع الأخطاء وتقديم الملاحظات: قدِّم رسائل خطأ أو ملاحظات واضحة للمستخدمين في حال حدوث أي مشاكل عند تسجيل الخروج. أبلِغهم بأي مخاطر أمنية محتملة أو عمليات تسرُّب للبيانات في حال تعذُّر عملية تسجيل الخروج.
  • اعتبارات تسهيل الاستخدام: تأكَّد من أنّ آلية تسجيل الخروج متاحة للمستخدمين ذوي الاحتياجات الخاصة، بما في ذلك أولئك الذين يستخدمون تكنولوجيات مساعِدة، مثل برامج قراءة الشاشة أو التنقّل باستخدام لوحة المفاتيح.
  • التوافق مع المتصفّحات المختلفة: اختبِر وظيفة تسجيل الخروج على متصفّحات وأجهزة مختلفة للتأكّد من أنّها تعمل بشكلٍ متّسق وموثوق.
  • المراقبة والتحديثات المستمرة: راقِب عملية تسجيل الخروج بانتظام لرصد أي ثغرات أمنية محتملة. تطبيق التحديثات والتصحيحات في الوقت المناسب لمعالجة أي مشاكل تم رصدها
  • اتحاد الهوية: إذا سجّل المستخدم الدخول باستخدام هوية موحّدة، تحقَّق مما إذا كان تسجيل الخروج من موفِّر الهوية متاحًا ومطلوبًا أيضًا. بالإضافة إلى ذلك، إذا كان موفّر الهوية يتيح ميزة "تسجيل الدخول تلقائيًا"، لا تنسَ منعها.

DOs

  • إذا أبطلت ملف تعريف ارتباط على الخادم كجزء من عملية تسجيل الخروج (أو عمليات إبطال الوصول الأخرى)، احرص على حذف ملف تعريف الارتباط على جهاز المستخدم أيضًا.
  • نظِّف أي بيانات حساسة ربما خزّنتها على جهاز المستخدم، مثل ملفات تعريف الارتباط وlocalStorage وsessionStorage وindexedDB وCacheStorage وأي مخازن بيانات محلية أخرى.
  • تأكَّد من عرض أي موارد تحتوي على بيانات حساسة، لا سيما مستندات HTML، مع عنوان HTTP Cache-control: no-store لكي لا يخزّن المتصفّح هذه الموارد في مساحة تخزين دائمة (على سبيل المثال، على القرص). وبالمثل، يجب أيضًا ضبط عنوان HTTP Cache-Control: no-store على طلبات XHR أو طلبات fetch التي تعرض بيانات حساسة لمنع أي تخزين مؤقت.
  • تأكَّد من أنّ أي علامات تبويب مفتوحة على جهاز المستخدم تتضمّن آخر عمليات إبطال الوصول من جهة الخادم.

تنظيف البيانات الحسّاسة عند تسجيل الخروج

عند تسجيل الخروج، ننصحك بمحو البيانات الحساسة المخزَّنة مؤقتًا والمخزَّنة محليًا. إنّ التركيز على البيانات الحسّاسة ناتج عن أنّ محو كل شيء سيؤدي إلى تجربة مستخدم أسوأ بكثير لأنّ هذا المستخدم قد يعود في أي وقت. على سبيل المثال، إذا محوت جميع البيانات المخزّنة محليًا، سيضطر المستخدمون إلى إعادة الموافقة على طلبات الموافقة على ملفات تعريف الارتباط، واتّباع إجراءات أخرى كما لو أنّهم لم يزوروا موقعك الإلكتروني من قبل.

كيفية تنظيف ملفات تعريف الارتباط

في الردّ على الصفحة التي تؤكّد حالة تسجيل الخروج، أرفِق عناوين 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 فقط، وملف تعريف ارتباط عادي يمكن الوصول إليه من خلال JavaScript. إذا كان المستخدم يحاول تسجيل الخروج أثناء عدم الاتصال بالإنترنت، يمكنك محو ملف تعريف ارتباط JavaScript والمتابعة في تنفيذ عمليات التنظيف الأخرى إذا أمكن ذلك. إذا كان لديك عامل خدمة، يمكنك أيضًا الاستفادة من واجهة برمجة التطبيقات 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: عند تسجيل الخروج، احذف أي بيانات حساسة ربما خزّنتها باستخدام واجهات برمجة التطبيقات هذه، علمًا بأنّ هذه البيانات ستظل محفوظة في جميع الجلسات.

    // 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 وبشأن محو ملفات تعريف الارتباط الحسّاسة (مثل ملفات تعريف الارتباط الآمنة التي تستخدم HTTPS فقط والمرتبطة بالمصادقة) عند تسجيل المستخدمين الخروج، لن تحتاج إلى القلق بشأن الاحتفاظ بالبيانات الحسّاسة في ذاكرة التخزين المؤقت للخلف/للأمام. في الواقع، ستؤدي ميزة "التخزين المؤقت للصفحات" إلى إزالة الصفحات من المصدر نفسه التي يتم عرضها باستخدام عنوان HTTP Cache-control: no-store إذا رصدت إشارة واحدة أو أكثر من الإشارات التالية:
    • تم تعديل أو حذف ملف واحد أو أكثر من ملفات تعريف الارتباط الآمنة التي تستخدم 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();
  }
});

  • واجهة برمجة التطبيقات Broadcast Channel 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.
    // ...
  }
}

الخاتمة

من خلال اتّباع الإرشادات الواردة في هذا المستند، ستتمكّن من تصميم تجربة مستخدم رائعة لتسجيل الخروج تمنع عمليات تسجيل الخروج غير المقصودة وتحمي المعلومات الشخصية للمستخدم.