اختبار بقاء جلسة المتصفح بعد انقطاع الإنترنت: افصل المصادقة عن إعادة الاتصال

لماذا يختلف انقطاع الإنترنت عن انهيار المتصفح؟

قد يبقى التبويب مفتوحًا والكوكيز محفوظة بينما يفقد التطبيق اتصال WebSocket أو يفشل طلب تحديث رمز الدخول. هذه حالة مختلفة جذريًا عن انهيار العملية أو استعادة التبويبات بعد إغلاق الجهاز. اختبارنا هنا يقيس استمرارية الهوية وصحة البيانات أثناء انقطاع الشبكة ثم عودتها، لا مجرد قدرة المتصفح على فتح الصفحة القديمة. النجاح لا يعني ظهور الواجهة وحدها؛ بل أن يرى المستخدم حالة صحيحة، وألا تُكرر عمليات حساسة، وأن يستطيع متابعة العمل دون تسجيل دخول جديد غير مبرر. حدد هذا الفرق في وصف حالة الاختبار قبل تشغيل أي أداة.

عرّف معنى الجلسة في التطبيق الذي تختبره

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

ابنِ بيئة اختبار قابلة للإعادة

استخدم حسابًا تجريبيًا وبيانات غير حساسة، وسجل إصدار المتصفح ونظام التشغيل ونوع البروكسي وإعدادات التخزين. افتح صفحة لها طلبات خلفية معروفة، ثم أنشئ حدثًا قابلًا للتحقق مثل مسودة غير منشورة. نفذ الاختبار مرة بشبكة مباشرة ومرة عبر بروكسي ثابت إذا كان ذلك جزءًا من المنتج. لا تخلط انقطاع الشبكة مع تبديل عنوان IP أو تغيير DNS في التجربة نفسها؛ كل تغيير إضافي يجعل تفسير النتائج أصعب. احفظ توقيت بداية الاختبار وتوقيته النهائي بدقة واحدة، واحتفظ بسجل للأحداث من المتصفح والخادم.

حدد أربع نقاط زمنية للمراقبة

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

لا تجعل navigator.onLine مصدر الحقيقة

توثيق MDN يوضح أن navigator.onLine إشارة تقريبية، وقد تظل true مع تعذر الوصول إلى الخدمة المطلوبة. لهذا يجب قياس نجاح طلب حقيقي إلى نقطة صحة مناسبة ضمن النظام، مع مهلة واضحة ومعالجة لأخطاء DNS و TLS والاتصال. تجنب اعتبار أي رد HTTP دليلًا على أن المصادقة تعمل؛ فقد تعيد البوابة صفحة تسجيل الدخول برمز 200. افحص نوع المحتوى وحالة التفويض والبيانات المتوقعة. يمكن استخدام أحداث online و offline لتحديث الواجهة، لكن قرار إعادة المحاولة يجب أن يستند إلى حالة الطلب وسبب فشله.

اختبر انقطاعًا حقيقيًا لا مجرد إخفاء زر

يمكن محاكاة الانقطاع بأدوات تطوير المتصفح أو من طبقة الشبكة في بيئة اختبار مضبوطة. احرص على أن يشمل القطع الاتصالات الجديدة والمستمرة، ثم تحقق أن التبويب لا يستطيع الوصول إلى نقطة فحص خارج الذاكرة المؤقتة. وضع Offline في أدوات التطوير قد يختلف عن قطع كابل الشبكة أو سقوط VPN أو انقطاع البروكسي؛ لذلك وثق وسيلة المحاكاة. ابدأ بطريقة واحدة قابلة للإعادة، ثم وسع مصفوفة الاختبار إذا ظهرت فروق. لا تغير إعدادات نظام إنتاج أو شبكة يستخدمها آخرون لمجرد إجراء تجربة.

راقب الطلبات التي كانت قيد التنفيذ

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

افصل إعادة اتصال WebSocket عن تسجيل الدخول

قد يعود HTTP للعمل بينما يظل اتصال WebSocket مغلقًا، فتظهر لوحة قديمة رغم أن الجلسة صحيحة. افحص دورة الاتصال وإعادة الاشتراك في القنوات، وكيف يتعامل التطبيق مع الرسائل الفائتة أو أرقام التسلسل. بعد الاتصال الجديد، ينبغي طلب حالة موثوقة أو استكمال الأحداث من نقطة معلومة بدل افتراض عدم حدوث تغييرات. راقب أيضًا ألا يفتح التطبيق عدة اتصالات متوازية بسبب مستمعين مكررين. فشل الإشعارات اللحظية لا يساوي فشل المصادقة، لكن كلاهما يجب أن يظهر في التقرير بحالة مستقلة قابلة للتشخيص.

عامل رموز الدخول حسب عمرها الفعلي

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

افحص التخزين المحلي والتغييرات غير المحفوظة

اكتب نصًا في نموذج ثم اقطع الاتصال قبل حفظه. بعد العودة افحص هل بقي النص، وهل ظهر للمستخدم بوضوح أنه غير محفوظ على الخادم. وجود البيانات في localStorage أو IndexedDB لا يثبت إرسالها ولا صلاحيتها. إذا كان التطبيق يدعم العمل دون اتصال، تحقق من طابور المزامنة ومن ترتيب العمليات ومن كيفية حل التعارض عندما يعدل مستخدم آخر السجل نفسه. لا تعرض كلمة تم الحفظ اعتمادًا على تخزين محلي فقط. وازن بين تجربة المستخدم وخصوصية المحتوى عند اختيار ما يُخزن مؤقتًا.

لا تخلط الكاش بالاتصال السليم

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

ضع سياسة إعادة محاولة يمكن قياسها

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

صمم مصفوفة نتائج بدل اختبار نجاح واحد

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

اقرأ النتيجة من الخادم والواجهة معًا

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

معايير قبول عملية لفريق صغير

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

خلاصة وتوثيق النتائج

لا تختصر اختبار بقاء الجلسة في سؤال هل ما زلت مسجلًا؟. التقرير الجيد يوضح نوع الانقطاع ومدته، وعمر رمز الدخول، وحالة HTTP و WebSocket، ومصير الطلبات غير المؤكدة، وما إذا كانت البيانات المعروضة حديثة. ابدأ بأبسط سيناريو ثم أضف حالات انتهاء الرمز والمزامنة وتغير الشبكة تدريجيًا. هذا يجعل الإصلاح محددًا وقابلًا للقياس بدل إضافة إعادة تحميل عشوائية. للمقارنة مع انقطاع عملية المتصفح نفسه، راجع دليل إيجي تاج عن استعادة جلسات المتصفح بعد انقطاع مفاجئ؛ فالمشكلتان متقاربتان في العرض ومختلفتان في السبب.

المصادر والتوسع

توضح MDN حدود navigator.onLine وأحداث online/offline: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/onLine . وتشرح MDN دور Service Worker في العمل دون اتصال: https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API . وللمقارنة التحريرية داخل إيجي تاج، اقرأ دليل «اختبار استعادة جلسات المتصفح بعد انقطاع مفاجئ» ودليل «مراقبة فقد الحزم وتأخر DNS و TLS». هذه المراجع تشرح الآليات العامة؛ أما صلاحية الجلسة ونتائج إعادة المحاولة فتعتمد على تنفيذ التطبيق وسياساته الفعلية.