اختبار عزل جلسات المتصفح: الكوكيز والبروكسي عبر أربع طرق اتصال

عندما يُشغّل تطبيق مبني على Electron أكثر من بروفايل داخل نافذة واحدة، فإن السؤال الهندسي الحقيقي ليس «هل تظهر النوافذ منفصلة؟» بل «هل يعرف محرّك الشبكة نفسه أن كل نافذة تنتمي إلى جلسة مختلفة؟». هذا الفرق بين واجهة تبدو معزولة وواقع شبكي قد يتسرّب فيه الكوكيز أو ينحرف فيه مسار البروكسي. في 13 نوفمبر 2026 نُفّذت دراسة حالة داخلية في مختبر إيجي تاج على بيئة اختبار خاصة بمشروع Social Browser في بيئة اختبار Electron، هدفها قياس هذا العزل عند مستوى الطلب الفعلي لا عند مستوى الشكل الخارجي. النتيجة كانت ناجحة، لكن قيمتها الحقيقية تكمن في وضوح ما قاسته وما لم تقسه.

لماذا يتسرّب الكوكيز وينحرف البروكسي؟

معظم حالات «cookie leakage» لا تنشأ من خطأ في واجهة المستخدم، بل من مشاركة كائن جلسة واحد بين سياقات يُفترض أنها منفصلة. في Electron توجد جلسة افتراضية defaultSession يلجأ إليها أي طلب لا يحدّد قسمًا صريحًا، فإذا استخدم ال ـ renderer دالة fetch العامة بدل session.fetch المرتبط بالبروفايل، ذهب الطلب بمرطبان الكوكيز الافتراضي. وتظهر المشكلة أيضًا عند ضبط الكوكيز بشكل غير متزامن دون انتظار انتهاء cookies.set، أو عند نسيان persist: في اسم القسم، أو عند الاعتماد على نطاق ومسار غير مطابقين للعنوان المحلي المستخدم، أو عند وجود Service Worker يخزّن استجابات من جلسة أخرى.

أما «wrong proxy routing» فينشأ من أن إعداد البروكسي في Chromium خاصية لكل جلسة، لا لكل نافذة ولا لكل تبويب. فاستدعاء app.setProxy أو ضبطه على الجلسة الافتراضية يجعل التوجيه عامًّا، كما أن ترتيب الاستدعاءات مهم: ضبط البروكسي بعد بدء الطلبات قد يترك اتصالات قائمة على المسار القديم بسبب إعادة استخدام الاتصالات. وهناك مصادر انحراف إضافية مثل أنماط PAC، أو بروكسي يُمرَّر لكل طلب على حدة، أو اختلاف سلوك WebSocket عن HTTP. لذلك لا يكفي أن «يبدو» كل بروفايل على بروكسي مختلف؛ يجب إثبات ذلك من جهة الخادم المتلقي.

سياق الاختبار داخل Social Browser

أُجري الاختبار على البنية المستخدمة فعليًا في Social Browser، وهو مشروع هندسي حقيقي لإدارة بيئات متصفح متعددة، لا على مثال منفصل عن المنتج. شُغّل Electron ببيانات مستخدم مؤقتة منفصلة، ولم تُلمس أي بروفايلات حقيقية للمستخدمين، وهذا شرط أساسي في أي اختبار عزل: لا يصح أن يكون اكتشاف التسرّب على حساب بيانات إنتاجية. الاعتماد على دليل مؤقت قابل للحذف يجعل الاختبار قابلًا للتكرار ويمنع تلويث الحالة بين التشغيلات.

محاكاة JavaScript ليست اختبار تكامل

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

بنية الاختبار: بروفايلان وبروكسيان مراقبان

استُخدم برنامج اختبار داخلي لتنسيق التشغيل، مع عملية فرعية معزولة لكل تجربة.. البروفايلان الافتراضيان alpha وbeta مستقلان عبر session.fromPartition('persist:network-isolation-' + id). على موقع HTTP محلي عند localhost ضُبط لكل بروفايل كوكي باسم profile_id وقيمته alpha أو beta. وأُعدّ خادمان محليان يعملان كبروكسي مراقبة، كل منهما يضيف ترويسة تعريف غير حساسة x-isolation-proxy بقيمتها المقابلة.

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

المسارات الأربعة وما يقيسه كل منها

فُحصت أربعة مسارات اتصال لكل بروفايل: session.fetch من العملية الرئيسية، وXMLHttpRequest، وfetch داخل renderer، وWorker.fetch داخل عامل. هذا التوزيع مقصود، لأن كل مسار يمرّ بطبقة مختلفة من التطبيق. session.fetch يختبر الربط الصريح بالجلسة؛ XMLHttpRequest يختبر المسار التقليدي الذي قد يعتمد على الجلسة الافتراضية؛ fetch في renderer يختبر ما إذا كانت الصفحة نفسها تستخدم الجلسة الصحيحة؛ وWorker.fetch يختبر سياقًا غالبًا ما يُغفل لأن العامل قد يرث جلسة غير متوقعة. بمجموع بروفايلين وأربعة مسارات صارت الفحوص الرئيسية ثمانية.

معايير النجاح والنتيجة الموثقة

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

انتهى التشغيل بمخرجات stdout موثقة:

NETWORK_PROFILE_ISOLATION_PASS {"profiles":2,"transports":["session.fetch","XMLHttpRequest","fetch","Worker.fetch"],"checks":8,"proxyHits":{"alpha":5,"beta":5}}
EXIT_CODE=0
START_UTC=2026-11-13T06:44:33Z
END_UTC=2026-11-13T06:44:38Z

ثمانية فحوص ناجحة، وخمس إصابات موثقة لكل بروكسي، ورمز خروج صفر. الإصدار الفعلي ل ـ Electron داخل بيئة الاختبار كان المستخدم أثناء التجربة وفق بيانات حزمة Electron، ويجب عدم الخلط بينه وبين إصدار Chromium المضمّن، فهما رقمان مختلفان لدورتين مختلفتين.

بروتوكول تعليمي قابل لإعادة التطبيق

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

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

ما لا يقيسه هذا الاختبار

النتيجة أعلاه لا تثبت عزل جميع البصمات: لا Canvas ولا WebGL ولا الخطوط ولا المنطقة الزمنية ولا User-Agent. ولا تثبت سلامة بروكسي إنترنت حقيقي، ولا غياب تسرّبات DNS أو IPv6 أو TLS، ولا ثبات البيانات بعد إعادة التشغيل. كذلك لا تغطي تشغيل عشرين أو مئة بروفايل، ولا الأداء تحت الضغط، ولم تُقس أي أرقام سرعة أو استهلاك RAM أو CPU، ولن تُخترع هنا. ما قيس هو عزل الكوكيز وتوجيه البروكسي عند مستوى الطلب في هذه البنية المحددة، وهذا ادعاء أضيق وأصدق.

خطة اختبارات لاحقة

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

كيف نتعامل مع نتيجة النجاح دون تعميم؟

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

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

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

الخلاصة

أثبت هذا التشغيل أن البنية المستخدمة في Social Browser تعزل كوكيز البروفايلين وتوجّه طلباتهما عبر المسار الصحيح على أربعة مسارات اتصال، في بيئة تكامل حقيقية لا محاكاة. لكن القيمة الحقيقية ليست في رقم النجاح، بل في المنهج: معيار قابل للدحض، تحقق من الطرف المستقبِل، وحدود معلنة بوضوح. هذا هو الفرق بين اختبار يطمئن واختبار يفيد. لمزيد من السياق حول المشروع، يمكن زيارة https://social-browser.com/ar.