تحدّي المطورين: اختبر عزل جلستين في Electron وشارك نتائج قابلة للتحقق

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

التحدي مناسب للمطور الذي يعرف أساسيات JavaScript و Node.js ويريد التعرف إلى هندسة Electron. ستنشئ بيئة اختبار محلية بالكامل، تستخدم حسابات وهمية داخلية لا تخص أي أشخاص حقيقيين، وتتحقق من جلستين مستقلتين. كل خطوة يجب أن تنتج دليلًا يمكن مراجعته، وكل نتيجة نجاح لها حدود معلنة.

الهدف الهندسي ومعيار النجاح

هدفك إنشاء جلستين مستقلتين تسميهما alpha و beta. لكل واحدة Cookie خاصة باسم qa_profile وقيمة مساوية لاسمها، ولكل واحدة بروكسي HTTP محلي مختلف. عندما يستقبل خادم الاختبار الطلبات، ينبغي أن يرى في كل حالة قيمة الكوكي الصحيحة ومسار البروكسي المقصود، وألا تظهر قيمة البروفايل الآخر إطلاقًا.

اكتب معيار النجاح قبل أن تشغّل البرنامج. حدد عدد الطلبات المتوقع، واسم طريقة الاتصال، والقيم المفترضة، وحالة PASS أو FAIL. إذا فشل تحميل الصفحة أو انتهت المهلة، فهذه ليست علامة نجاح؛ أبلغ عن حالة مستقلة مثل TIMEOUT أو ERROR مع حفظ السبب. هكذا تصبح نتيجة الاختبار قابلة لإعادة القياس بدل أن تكون انطباعًا عامًا.

أنشئ خادمًا محليًا يعكس البيانات

ابدأ بخادم HTTP صغير يعمل على localhost فقط، مثل المنفذ 4100. دوره إعادة كائن JSON يضم قيمة ترويسة Cookie وقيمة ترويسة x-lab-route التي أضافها بروكسي المراقبة. لا يتصل هذا الخادم بجهات خارجية ولا يحتفظ بمعلومات مستخدمين، فهو مجرد مستقبل للبيانات المصطنعة التي أنشأتها بنفسك.

بعد ذلك أنشئ خادمي بروكسي محليين على منفذين مستقلين، مثل 4101 و 4102. يضيف الأول x-lab-route: alpha إلى الطلب الصادر من الجلسة الأولى، والثاني x-lab-route: beta إلى الثانية. تلك الترويسة ليست جزءًا من خصوصية الشبكة الحقيقية، بل علامة تجربة تساعدك على رصد مسار الطلب. النجاح هنا لا يثبت إخفاء IP على الإنترنت أو سلامة DNS.

افصل الجلسات على مستوى Electron

استخدم session.fromPartition باسم مختلف لكل بروفايل، مثل persist:lab-alpha و persist:lab-beta. اسم التقسيم هو نقطة الفصل في مساحة التخزين، وليس مجرد نص ظاهر في عنوان النافذة. اضبط إعداد بروكسي الجلسة قبل إجراء الطلب، ثم اكتب Cookie اختبار في كل Session عبر واجهة cookies.set.

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

const { app, session } = require('electron');
app.whenReady().then(async () => {
  const origin = process.env.LOCAL_TEST_ORIGIN;
  if (!origin) throw new Error('Configure a local test endpoint');
  for (const [id, key] of [['alpha', 'LOCAL_PROXY_ALPHA'], ['beta', 'LOCAL_PROXY_BETA']]) {
    const proxyAddress = process.env[key];
    if (!proxyAddress) throw new Error('Configure a local proxy');
    const ses = session.fromPartition(`persist:lab-${id}`);
    await ses.setProxy({proxyRules: `http=${proxyAddress}`, proxyBypassRules: '<-loopback>'});
    await ses.cookies.set({url:origin, name:'qa_profile', value:id});
  }
});

اختبر أربع طرق اتصال مستقلة

بعد إعداد الجلسات، ابدأ بطلب session.fetch، ثم افتح صفحة اختبار داخل BrowserWindow مرتبطة بالجلسة المقصودة واستخدم XMLHttpRequest، ثم fetch العادية داخل renderer. أضف في مرحلة لاحقة Web Worker ينفذ fetch مستقلًا. ليس المقصود جمع أكبر عدد من الاستدعاءات، بل التأكد أن كل مسار يمر عبر الجلسة وإعداد الشبكة المتوقعين.

سجّل لكل طلب اسم البروفايل واسم النقل وقيمة الكوكي المستلمة وترويسة المسار. اجعل Assertions توقف نجاح الاختبار إذا ظهرت alpha عند طلب beta أو العكس، أو إذا خرج الطلب عبر البروكسي الآخر. من الأفضل إظهار نتيجة واضحة لكل مسار بدل الاكتفاء بطباعة مصفوفة طويلة في console.

لا تنس اختبار الفشل المتعمّد

أهم اختبار للتجربة نفسها هو أن تتأكد أنها تفشل عند إدخال خطأ مقصود. اربط جلسة beta مؤقتًا ببروكسي alpha في بيئة التطوير المحلية، وشغّل الفحص من جديد. ينبغي أن تخرج نتيجة FAIL مفسرة سبب الخطأ. إن استمر ظهور PASS، فمعايير الاختبار ناقصة مهما بدا البرنامج منظمًا.

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

كيف توثق التجربة؟

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

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

معيار تقييم تعليمي من 100 نقطة

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

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

حدود التجربة ومتى لا تكفي نتائجها

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

من تجربة محدودة إلى منهج اختبار متكامل

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

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

قراءة مرتبطة وخطوتك التالية

نشر مختبر إيجي تاج دراسة حالة حقيقية عن بروفايلين منفصلين في بيئة اختبار Electron خاصة بمشروع Social Browser. أظهرت الدراسة نجاح ثمانية فحوص عبر أربع طرق اتصال، مع خادمي بروكسي محليين، وصرحت بوضوح أن ذلك لا يثبت سلامة كل مسارات الشبكة في التطبيق النهائي. اقرأ المنهج والتقرير وقارن بين بيئتك وبيئة الاختبار قبل أن تبدأ.

الدراسة المرجعية: https://egytag.com/ar/articles/social-browser-electron-profile-cookie-proxy-isolation-lab . والمختبر: https://egytag.com/ar/topics/مختبر-إيجي-تاج-للتجارب-التقنية . ويمكن التعرف على مشروع المتصفح عبر https://social-browser.com/ar . ما يتعلمه المطور هنا ليس مجرد إنشاء جلستين، بل عادة قول ما أثبته الاختبار تحديدًا وما يحتاج إلى دليل جديد.