حذف بيانات موقع واحد دون تسجيل خروج باقي المواقع: اختبار حدود المسح في المتصفح

ابدأ بتعريف معنى «موقع واحد»

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

ما الذي يمكن أن يُخزن محليًا؟

لا تختزل بيانات الموقع في Cookies. قد يحفظ التطبيق إعداداته في localStorage، وسجلاته في IndexedDB، وموارد العمل دون اتصال في Cache Storage، كما قد يسجل Service Worker يتعامل مع الطلبات. توجد أيضًا sessionStorage المرتبطة بسياق التصفح وذاكرة داخل الصفحة المفتوحة. Cookie نفسها لها نطاق Domain ومسار Path وخصائص Secure و HttpOnly و SameSite، ولا تستطيع قراءة كل أنواعها من JavaScript. لهذا ينبغي أن يحتوي خط الأساس على قائمة بالفئات الموجودة قبل الحذف. إذا اختفت Cookie وبقيت قاعدة IndexedDB فلا يصح وصف النتيجة بأنها «مسح كامل» إلا إذا كان الإجراء مصممًا لذلك.

لماذا قد تعود الجلسة بعد الحذف؟

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

أنشئ ثلاثة أصول اختبار لا تحتوي بيانات حساسة

جهز أصلًا مستهدفًا مثل app.example.test وأصلًا شقيقًا مثل docs.example.test وأصلًا مستقلًا مثل unrelated.test، أو بدائل محلية تملك التحكم فيها. ضع في كل أصل مفتاح localStorage فريدًا وسجل IndexedDB و Cookie تجريبية تحمل رقم التجربة. اجعل الصفحة تعرض القيم قبل وبعد من دون إرسالها إلى طرف ثالث. افتح الأصول الثلاثة داخل بروفايل واحد، ثم جهز بروفايلًا ثانيًا للمقارنة. هذا التصميم يعطيك ثلاث مجموعات ضابطة: الهدف، الجار، والبروفايل المنفصل. من دونها لن تعرف هل كانت عملية المسح موضعية أم أثرت في كل جلسات المتصفح.

وثق الخط الأساس قبل أي تغيير

سجل إصدار المتصفح ومحرك Chromium ونظام التشغيل واسم البروفايل وطريقة فتح الصفحة. افتح أدوات المطور وافحص Cookies بنطاقاتها ومساراتها، و localStorage و IndexedDB و Cache Storage و Service Workers. لا تكتف بصورة شاشة واحدة؛ دوّن عدد السجلات ومفتاحًا يمكن مقارنته بعد المسح. إذا كانت الصفحة تستعمل SSO، سجّل أن نطاق مزود الهوية منفصل. وإذا كانت هناك Service Worker نشطة فدوّن نطاق سيطرتها. احتفظ بالنتائج في جدول يميز «موجود» و«غير موجود» و«لم يُختبر»، لأن الخانة الأخيرة لا يمكن تحويلها إلى نجاح بمجرد غياب الخطأ.

اختر عملية الحذف المناسبة

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

اختبر الأصل المستهدف بعد إعادة فتحه

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

تأكد من سلامة المواقع الأخرى

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

أين تدخل ترويسة Clear-Site-Data؟

تتيح ترويسة HTTP المسماة Clear-Site-Data للخادم أن يطلب من المتصفح إزالة فئات معينة من البيانات وفق دعم المتصفح وتفسير نطاق الاستجابة. لكنها ليست مرادفًا مضمونًا لأمر «احذف هذا الأصل فقط» في كل إصدار أو منصة. افحص الترويسة الفعلية في Network، وحدد ما إذا كانت تشمل cookies أو storage أو cache، واختبر النطاقات المتأثرة. لا ترسل هذه الترويسة في الإنتاج على سبيل التجربة؛ فقد تخرج مستخدمين من جلساتهم. ارجع إلى وثائق MDN الخاصة بالترويسة وحدود الدعم، واستخدم بيئة اختبار مستقلة قبل إدخالها في تدفق تسجيل الخروج.

كيف تفرق بين خلل المتصفح وسلوك التطبيق؟

قد تعيد JavaScript إنشاء قيمة محذوفة من استجابة API، وقد يعيد Service Worker تقديم بيانات مخزنة، وقد يحتفظ الخادم بجلسة قابلة للاستئناف. لا تصف هذه الحالات كلها بأنها «تسرب تخزين». اختبر أولًا صفحة ثابتة تتحكم فيها بلا مكتبات خارجية، ثم كرر على التطبيق الفعلي. إذا نجح المسح في الصفحة الثابتة وفشل في التطبيق، فابدأ بتتبع إعادة إنشاء الحالة داخل التطبيق. وإذا اختلفت النتيجة بين إصدار Chromium ومتصفح مبني على Electron، فافصل أثر الإصدار والتعديلات الخاصة بالمتصفح قبل إصدار حكم عن المحرك الأساسي.

جدول القرار والتوثيق

عندما تريد إنهاء جلسة، راقب Cookies وتدفق SSO وإبطال الرمز لدى الخادم. وعندما تريد إصلاح عرض قديم، افحص Cache Storage و Service Worker قبل حذف إعدادات المستخدم. وعندما تريد إعادة ضبط تطبيق ويب، اختبر IndexedDB و localStorage مع Cookies. وعندما تريد إثبات عزل البروفايلات، قارن بيانات الأصل نفسه في بروفايلين مختلفين. لكل حالة معيار نجاح مختلف، لذلك لا يصح استخدام عبارة «نجح تنظيف الموقع» دون تحديد الفئات. ضع في التقرير النتيجة المتوقعة والفعلية والاختلاف والتفسير المقترح وخطوة التحقق التالية، ثم اربطها بسجل إصدار المتصفح.

أخطاء تتكرر عند مراجعة النتائج

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

مصادر موثوقة وقراءة مكملة

تشرح MDN تعريف Origin في https://developer.mozilla.org/en-US/docs/Glossary/Origin وتوثق ترويسة Clear-Site-Data في https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Clear-Site-Data . وتوضح وثائق Chrome طريقة فحص التخزين في https://developer.chrome.com/docs/devtools/application/ . للمقارنة مع خريطة أنواع التخزين اقرأ دليل إيجي تاج https://egytag.com/ar/articles/storage-isolation-map-dina-fathy-2026-10-03 ، وللتوسع في حالة البيانات بعد حذف Cookies راجع https://egytag.com/ar/articles/storage-isolation-map-dina-fathy-2026-10-04-followup . الخلاصة: عرّف نطاق الحذف، أنشئ مجموعة ضابطة، وافصل ما حُذف عما أعيد إنشاؤه تلقائيًا قبل الحكم على نجاح العملية.