Chrome DevTools Protocol هو بروتوكول يسمح لعميل خارجي بالتحدث مع Chromium عبر أوامر وأحداث منظمة. نفس العائلة من القدرات التي تستخدمها DevTools للوصول إلى DOM و Network و Runtime و Page يمكن لأداة أتمتة استدعاؤها برمجيًا. لكن CDP منخفض المستوى نسبيًا: يعطيك primitives قوية، ولا يعطي تلقائيًا انتظارًا ذكيًا أو selectors قابلة للصيانة أو نموذج اختبار كامل مثل Playwright. فهم الطبقتين يساعدك على استخدام CDP عند الحاجة بدون إعادة بناء إطار أتمتة كامل.
CDP منظم إلى Domains
البروتوكول مقسم إلى Domains مثل Page و Runtime و Network و DOM و Target و Browser و Storage. ترسل أمرًا يحمل method و params، وتحصل على result، وتستقبل events بصورة مستقلة. هذا النموذج يسمح بمراقبة request/response أو تنفيذ JavaScript أو إنشاء target جديد. إصدار البروتوكول مرتبط بإصدار Chromium، لذلك لا تفترض أن كل method موجودة بنفس الشكل في كل نسخة.
Network domain يعطي رؤية أعمق من UI automation
يمكنك مراقبة الطلبات والاستجابات وال headers والتوقيت، وأحيانًا اعتراض الطلبات أو تعديلها باستخدام Fetch domain. هذا مفيد لاختبار API التي تستدعيها الصفحة، التقاط download، أو تشخيص redirect. لكنه لا يعني أن كل حركة النظام تمر عبر CDP؛ أنت ترى ما يخص targets والسياق الذي تتصل به.
خطوات عملية
- فعّل Network events.
- سجل requestId مع URL و method.
- اربط responseReceived بنفس requestId.
- انتظر loadingFinished أو failure.
- احجب Authorization/Cookie قبل حفظ logs.
Targets و Sessions مهمة في المتصفح متعدد التبويبات
عند وجود عدة Tabs أو Workers تحتاج معرفة targetId وربط Session صحيحة بكل target. خطأ شائع هو إرسال command إلى التبويب القديم بعد navigation أو popup. استخدم Target events لتتبع الإنشاء والإغلاق، واحفظ mapping بين Tab في منتجك و CDP session. في Electron قد توجد طبقات إضافية بين BrowserWindow/WebContents والبروتوكول.
قائمة مراجعة
- كل tab لها target/session معروف.
- popup الجديد يدخل registry قبل التحكم.
- إغلاق tab ينظف listeners.
- Reconnect لا يترك sessions قديمة.
- الأحداث لا تُرسل لكل Profiles في قناة مشتركة بلا routing.
لماذا تستخدم Playwright فوق CDP؟
Playwright يوفر locators و auto-waiting و browser contexts و assertions وتجريدًا بين Chromium و Firefox/WebKit. هو أنسب لمعظم اختبارات الويب. استخدم CDP مباشرة عندما تحتاج قدرة Chromium-specific لا يكشفها الإطار، أو عندما تبني متصفحك نفسه وتحتاج ربطًا أعمق. يمكن أيضًا استخدام CDP session من داخل Playwright لحالة خاصة بدل تحويل كل المشروع إلى بروتوكول منخفض المستوى.
أمّن منفذ ال ـdebugging
Remote debugging endpoint قد يمنح قدرة كبيرة على الصفحات والبيانات. لا تعرضه على شبكة عامة بلا مصادقة وعزل. في منتج desktop الأفضل الوصول محليًا أو عبر قناة داخلية موثوقة، مع عدم طباعة websocket URL حساس في logs عامة. إذا كان لديك عدة Profiles، لا تجعل اتصالًا واحدًا يعطي وصولًا غير مقصود لكل بيئات المستخدم.
قائمة مراجعة
- المنفذ غير مكشوف للعامة.
- الاتصال مقيد بالعملية/المستخدم المتوقع.
- Logs لا تكشف tokens أو websocket endpoints بلا حاجة.
- الأوامر الحساسة لها طبقة authorization في منتجك.
- DevTools access لا يتجاوز Profile boundaries.
شارك في تقييم ونقاش المقال
رأيك يضيف قيمة للمقال ويساعدنا على تحسين المحتوى والنقاش حوله.
النقاش
جارٍ تحميل التعليقات…