يرجع المستخدم إلى صفحة عميل فتظهر فورًا كما تركها، مع أن بيانات العميل تغيرت في شاشة أخرى. قد يكون المتصفح أعاد الصفحة من bfcache بدل تحميل مستند جديد. سرعة الرجوع مفيدة، لكن يجب ألا تُفهم كدليل على حداثة البيانات أو استمرار صلاحية الجلسة.
تعرف إلى الاستعادة بدل افتراض إعادة التحميل
تشرح وثائق web.dev عن Back/forward cache استعادة حالة الصفحة عند التنقل للخلف أو للأمام، وتوصي باستخدام pageshow مع persisted لمعرفة الاستعادة. وتوضح MDN لحدث pageshow أن الحدث لا يقتصر على تحميل أولي؛ يمكن أن يقع عند العودة إلى الصفحة.
في نموذج افتراضي، افتح سجل عميل تجريبي ثم انتقل إلى صفحة أخرى. عدل حالته من حساب مخول في جلسة اختبار ثانية، ثم عد بزر الرجوع في الأولى. افحص هل يخبر النظام المستخدم بحداثة البيانات ويعيد التحقق من الحالة المناسبة قبل تنفيذ إجراء يعتمد عليها.
حالتان لا تعالجهما بالطريقة نفسها
| ما تغير؟ | ما يحتاجه التصميم |
|---|---|
| بيانات السجل فقط | تحديث مفهوم مع الحفاظ على ما يحرره المستخدم |
| صلاحية الجلسة أو الوصول | تحقق خادمي ومسار واضح عند الرفض |
لا تنفذ تحديثًا أعمى يمسح نصًا غير محفوظ عند كل رجوع. حدد أي الأجزاء يمكن تحديثها مباشرة، ومتى يحتاج المستخدم مقارنة تغييرات أو إعادة فتح السجل. ولا تحول زر الرجوع إلى تنقل إجباري مختلف عن اختياره.
اختبر الخروج ثم الرجوع ببيانات مصطنعة
نفذ تسجيل خروج فعليًا، ثم ارجع إلى صفحة محمية وافحص ما يظهر وما تقبله الطلبات التالية. يبقى التفويض مسؤولية الخادم؛ غياب زر الحفظ لا يكفي لمنع عملية غير مصرح بها. ولا تعتبر وجود كوكي يمكن قراءتها في JavaScript دليلًا وحيدًا على صلاحية المستخدم.
إذا كانت سياسة المنتج تمنع ظهور لقطة سابقة من معلومات خاصة، يحتاج تصميم المحتوى ودورة حياة الصفحة إلى مراجعة مستقلة. حدث pageshow وحده لا يضمن منع ظهور لقطة سابقة ولا يحقق حماية أمنية كاملة. اختبر السلوك في المتصفحات المستهدفة؛ ليس كل رجوع مضمونًا أن يستخدم bfcache.
وازن العودة السريعة مع الحالة الصحيحة
في تطوير CRM سجل مسارات العودة وتحديث السجل وفقد الصلاحية، وراجعها ضمن الفحص التقني. لا تعطل تحسين المتصفح عشوائيًا لإخفاء العيب. النجاح أن يرجع المستخدم إلى رحلة مفهومة ببيانات وصلاحيات جرى التحقق منها، مع احترام المسودة التي لم يقرر التخلي عنها.
