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

كنجي باهيو
كنجي باهيو

الخروج

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

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

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

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

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

الإجراءات المستحسنة

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

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

تجربة مستخدم متسقة في علامات التبويب

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

طريقة التنفيذ

لتسجيل الدخول بطريقة متسقة في جميع علامات التبويب، يمكنك استخدام مزيج من أحداث pageshow/pagehide وواجهة برمجة تطبيقات قناة Broadcast Channel.

  • حدث 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.
    // ...
  }
}

الخلاصة

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