نجح متصفح BrowserAct المتخفي (stealth browser) في تجاوز فحص كشف البوتات الذي صنف تشغيل Playwright الافتراضي في وضع headless كبوت، على الرغم من أن كلا السكريبتين أكملوا نفس عملية تسجيل الدخول. يوضح هذا التباين سبب كون النهج القائم على الوكيل (agent-based approach) أكثر أمانًا عندما تحتاج إلى التفاعل مع المواقع التي تحمي نفسها ضد الأتمتة.
لماذا يكتسب هذا الاختبار أهمية
تدعم أدوات الأتمتة عمليات الاختبار، وجمع البيانات، وإدارة الحسابات. يلجأ معظم المطورين إلى أطر العمل القائمة على المحددات (selector-driven frameworks) مثل Playwright لأنها تتيح لك كتابة تعليمات دقيقة — "انقر على الزر الذي يحمل محدد CSS هذا" — والتحقق من النتائج بسرعة. ومع ذلك، تقوم المواقع الحديثة بتضمين سكريبتات تكتشف المتصفحات التي تعمل في وضع headless: مثل سلسلة user-agent عامة، أو خاصية webdriver ، أو غياب أنماط التفاعل الشبيهة بالبشر. وعندما تظهر هذه الإشارات، يقوم الموقع بحظر الطلب أو عرض اختبار CAPTCHA، مما يؤدي فعليًا إلى تعطيل السكريبت.
تحاول متصفحات الوكيل (Agent browsers) محاكاة المستخدم البشري دون الاعتماد على محددات مكتوبة مسبقًا. فهي تتعامل مع الصفحة كمجموعة من العناصر القابلة للتنفيذ، حيث تختار عنصرًا واحدًا بناءً على موقعه في فهرس داخلي بدلاً من مسار CSS. قارن الاختبار بين النهجين في صفحة تسجيل دخول يتم عرضها بواسطة JavaScript وفي موقع يتحقق عمدًا من وجود بوتات.
التجربة
كتبت سكريبتين يقومان بنفس الخطوات: تحميل صفحة تسجيل الدخول، إدخال بيانات الاعتماد، الإرسال، والوصول إلى صفحة المخزون. استخدم أحد السكريبتين Playwright في وضع headless الافتراضي؛ بينما استخدم الآخر متصفح BrowserAct المتخفي، الذي يخفي البصمات الرقمية (fingerprints) التي تطلق عملية كشف البوتات.
قام كلا السكريبتين بالمصادقة عبر موقع تجريبي (sandbox site)، مما أثبت أن تدفق تسجيل الدخول الأساسي يعمل بغض النظر عن الأداة. ظهر الاختلاف عندما زار السكريبتان صفحة مخصصة لكشف البوتات تعيد علامة JSON باسم isBot. أبلغ Playwright عن isBot: true ، مما أدى إلى تفعيل خمس عمليات فحص منفصلة للكشف. بينما أعاد BrowserAct قيمة isBot: false ، مما يشير إلى أن الصفحة تعاملت معه كزائر بشري عادي.
تتبعت الفرق ووجدته في تفصيلين تقنيين. ترسل تهيئة Playwright الافتراضية سلسلة user-agent عامة وتترك علامة webdriver مكشوفة — وكلاهما يسهل على سكريبت الكشف رصده. أما وضع التخفي في BrowserAct فيقوم بإعادة كتابة الـ user-agent، وإزالة خاصية webdriver ، ومواءمة بصمته الرقمية مع بصمة متصفح سطح المكتب النموذجي.
كيف تختلف الأدوات من الداخل
| الجانب | Playwright (الافتراضي) | BrowserAct (المتخفي) |
|---|---|---|
| نموذج التفاعل | قائم على المحددات، حتمي | قائم على الوكيل، يعتمد على الفهرس |
| الحاجة إلى محددات مكتوبة مسبقًا | إلزامية؛ يجب أن يعرف السكريبت بنية DOM الدقيقة | غير مطلوبة؛ يكتشف الوكيل العناصر القابلة للتنفيذ أثناء التشغيل |
| التعامل مع تغييرات التخطيط | يتعطل إذا تغيرت المحددات | يستمر طالما ظلت مواقع العناصر ضمن القائمة المفهرسة |
| التعرض لفحوصات البوتات | تظل الـ user-agent و webdriver دون تغيير |
يتم إخفاء البصمات الرقمية عمدًا |
| حالة الاستخدام النموذجية | المواقع الداخلية، واجهة مستخدم مستقرة، دورات اختبار سريعة | المواقع العامة التي تحتوي على تدابير مضادة للأتمتة، والصفحات التي تتغير باستمرار |
يلخص الجدول المقايضات العملية. يتألق Playwright عندما تتحكم في الموقع ويمكنك ضمان معرفات عناصر مستقرة. بينما يتألق متصفح الوكيل عندما لا يمكنك التنبؤ ببنية الصفحة أو عندما يحاول الموقع بنشاط حظر السكريبتات.
من المستفيد ومن المعرض للخطر
يمكن للمطورين الذين يبنون مجموعات اختبار التراجع (regression suites) لتطبيقاتهم الخاصة الحفاظ على انخفاض التكاليف وسرعة الاختبار العالية من خلال الاستمرار في استخدام Playwright. فطبيعته الحتمية تشير إلى أخطاء الكود مباشرة، كما أن غياب طبقات التخفي الإضافية يقلل من التعقيد.
وعلى العكس من ذلك، فإن الفرق التي تقوم بكشط البيانات (scraping data)، أو أتمتة إنشاء الحسابات، أو مراقبة مواقع المنافسين غالبًا ما تصطدم بعقبات لأن الصفحات المستهدفة تتغير كثيرًا أو تتضمن كشفًا عدوانيًا للبوتات. في هذه السيناريوهات، يتجنب متصفح الوكيل طريق المسدود المباشر "أنت بوت" ويستمر في الوصول إلى البيانات التي يحتاجها.
التكاليف الخفية لـ "لقد نجح الأمر"
أحذر من أن رمز الخروج (exit code) الناجح لا يضمن أن الأتمتة سلكت المسار المقصود. في تشغيل Playwright، انتهى السكريبت دون إظهار خطأ، ومع ذلك لا تزال الصفحة تعتبر الطلب بوتًا. كانت النتيجة فشلاً خفيًا: الخطوات اللاحقة التي تعتمد على محتوى مخصص للبشر فقط لم تتلقَّ البيانات المتوقعة أبدًا.
للكشف عن مثل هذه الإخفاقات الصامتة، افحص أدلة الصفحة بعد كل عملية تشغيل: موضع التمرير، وارتفاع المستند، واستدعاءات الشبكة. إذا بدا الـ DOM مختلفاً عما قد يراه الإنسان، أو إذا تضمنت حركة مرور الشبكة عمليات إعادة توجيه غير متوقعة إلى تحديات التحقق، فمن المرجح أن الأتمتة قد أخفقت في تحقيق هدفها.
الخلاصة
إذا كنت تملك الموقع ويمكنك كتابة سكربتات تعتمد على محددات (selectors) مستقرة، يظل Playwright هو الخيار العملي — فهو سريع، وغير مكلف، وسهل الدمج في مسارات التكامل المستمر (CI pipelines). أما عندما تواجه تخطيطات غير معروفة، أو دفاعات شرسة ضد الأتمتة، أو تغييرات متكررة في واجهة المستخدم، فإن متصفح وكيل (agent browser) مثل BrowserAct يوفر مساراً أكثر مرونة. لا تثق في نجاح عملية التشغيل بشكل أعمى؛ بل تحقق من أن الصفحة تصرفت كما يفعل الإنسان، واختر الأداة التي تتناسب مع طبيعة المخاطر في موقعك المستهدف.