مرورگر stealth شرکت BrowserAct توانست از بررسی تشخیص ربات عبور کند؛ در حالی که اجرای headless پیشفرض Playwright به عنوان ربات شناسایی شد، هر دو اسکریپت همان جریان ورود (login flow) را با موفقیت انجام دادند. این تضاد نشان میدهد که چرا وقتی نیاز به تعامل با سایتهایی دارید که در برابر اتوماسیون محافظت میکنند، رویکرد مبتنی بر عامل (agent-based) میتواند ایمنتر باشد.
چرا این آزمایش اهمیت دارد
ابزارهای اتوماسیون، قدرت بخشنده تست، جمعآوری داده و مدیریت حسابها هستند. اکثر توسعهدهندگان به سراغ فریمورکهای مبتنی بر انتخابگر (selector-driven) مانند Playwright میروند، زیرا به شما اجازه میدهند دستورالعملهای دقیقی بنویسید — مانند «روی دکمهای با این CSS selector کلیک کن» — و نتایج را به سرعت تأیید کنید. با این حال، سایتهای مدرن اسکریپتهایی را در خود جای دادهاند که به دنبال مرورگرهای headless میگردند: یک رشته user-agent عمومی، ویژگی webdriver یا نبود الگوهای تعامل مشابه انسان. وقتی این سیگنالها ظاهر میشوند، سایت درخواست را مسدود کرده یا یک CAPTCHA نمایش میدهد و عملاً اسکریپت را از کار میاندازد.
مرورگرهای عامل (Agent browsers) سعی میکنند بدون تکیه بر انتخابگرهای از پیش نوشته شده، از یک کاربر انسانی تقلید کنند. آنها با یک صفحه به عنوان مجموعهای از عناصر قابل اجرا (actionable elements) برخورد میکنند و یکی را به جای مسیر CSS، از طریق موقعیت آن در یک ایندکس داخلی انتخاب میکنند. این آزمایش، دو رویکرد را در یک صفحه ورود با رندر JavaScript و سایتی که عمداً رباتها را بررسی میکند، با هم مقایسه کرد.
آزمایش
من دو اسکریپت نوشتم که مراحل یکسانی را انجام میدادند: بارگذاری صفحه ورود، وارد کردن اطلاعات کاربری، ارسال و رسیدن به صفحه موجودی (inventory). یک اسکریپت از Playwright در حالت headless پیشفرض استفاده کرد؛ اسکریپت دیگر از مرورگر stealth شرکت BrowserAct استفاده کرد که اثرانگشتهای دیجیتال (fingerprints) باعث تشخیص ربات را پنهان میکند.
هر دو اسکریپت در یک سایت sandbox احراز هویت کردند که ثابت کرد جریان اصلی ورود، صرفنظر از ابزار مورد استفاده، کار میکند. تفاوت زمانی آشکار شد که اسکریپتها از یک صفحه اختصاصی تشخیص ربات بازدید کردند که یک پرچم JSON به نام isBot را برمیگرداند. Playwright مقدار isBot: true را گزارش کرد که باعث فعال شدن پنج بررسی تشخیص مجزا شد. BrowserAct مقدار isBot: false را برگرداند که نشان میداد صفحه با آن مانند یک بازدیدکننده انسانی معمولی برخورد کرده است.
من دلیل این تفاوت را در دو جزئیات فنی یافتم. پیکربندی پیشفرض Playwright یک رشته user-agent عمومی ارسال میکند و پرچم webdriver را بدون تغییر باقی میگذارد — هر دو مورد برای یک اسکریپت تشخیص، به راحتی قابل شناسایی هستند. حالت stealth در BrowserAct، رشته user-agent را بازنویسی میکند، ویژگی webdriver را حذف میکند و اثرانگشت خود را با یک مرورگر دسکتاپ معمولی همسو میکند.
تفاوت ابزارها در لایههای زیرین
| جنبه | Playwright (پیشفرض) | BrowserAct (stealth) |
|---|---|---|
| مدل تعامل | مبتنی بر انتخابگر، قطعی (deterministic) | مبتنی بر عامل، مبتنی بر ایندکس |
| نیاز به انتخابگرهای از پیش نوشته شده | اجباری؛ اسکریپت باید ساختار دقیق DOM را بداند | الزامی نیست؛ عامل عناصر قابل اجرا را در زمان اجرا کشف میکند |
| مدیریت تغییرات چیدمان | اگر انتخابگرها تغییر کنند، از کار میافتد | تا زمانی که موقعیت عناصر در لیست ایندکسشده باقی بماند، به کار خود ادامه میدهد |
| قرارگیری در معرض بررسیهای ربات | user-agent و webdriver بدون تغییر باقی میمانند |
اثرانگشتها عمداً پنهان شدهاند |
| مورد استفاده معمول | سایتهای داخلی، رابط کاربری پایدار، چرخههای تست سریع | سایتهای عمومی با اقدامات ضد اتوماسیون، صفحات دائماً در حال تغییر |
این جدول توازنهای عملی (trade-offs) را نشان میدهد. Playwright زمانی میدرخشد که شما کنترل سایت را در دست دارید و میتوانید شناسههای پایدار عناصر را تضمین کنید. یک مرورگر عامل زمانی میدرخشد که نمیتوانید ساختار صفحه را پیشبینی کنید یا زمانی که سایت فعالانه سعی در مسدود کردن اسکریپتها دارد.
چه کسی سود میبرد و چه کسی در معرض خطر است
توسعهدهندگانی که مجموعههای تست رگرسیون (regression suites) برای برنامههای خود میسازند، میتوانند با استفاده از Playwright، هزینهها را پایین و سرعت تست را بالا نگه دارند. ماهیت قطعی آن، شکستها را مستقیماً به رگرسیونهای کد مربوط میکند و نبود لایههای اضافی stealth، پیچیدگی را کاهش میدهد.
در مقابل، تیمهایی که دادهها را استخراج (scrape) میکنند، ساخت حساب کاربری را خودکار میکنند یا سایتهای رقبا را زیر نظر دارند، اغلب به دلیل تغییرات مکرر صفحات هدف یا وجود سیستمهای تشخیص ربات تهاجمی، با بنبست مواجه میشوند. در این سناریوها، یک مرورگر عامل از بنبست فوریِ «شما یک ربات هستید» جلوگیری کرده و به دریافت دادههای مورد نیاز خود ادامه میدهد.
هزینههای پنهانِ «کار کرد»
من هشدار میدهم که یک کد خروج (exit code) موفقیتآمیز، تضمین نمیکند که اتوماسیون طبق برنامه عمل کرده باشد. در اجرای Playwright، اسکریپت بدون پرتاب خطا به پایان رسید، اما صفحه همچنان درخواست را به عنوان ربات در نظر گرفت. نتیجه یک شکست پنهان بود: مراحل پاییندستی که به محتوای مخصوص انسان متکی بودند، هرگز دادههای مورد انتظار را دریافت نکردند.
برای شناسایی این شکستهای خاموش، شواهد صفحه را پس از هر اجرا بررسی کنید: موقعیت اسکرول، ارتفاع سند و فراخوانیهای شبکه. اگر DOM با آنچه یک انسان میبیند متفاوت باشد، یا اگر ترافیک شبکه شامل تغییر مسیرهای غیرمنتظره به چالشهای تأیید هویت باشد، احتمالاً اتوماسیون به هدف خود نرسیده است.
خلاصه کلام
اگر مالک سایت هستید و میتوانید با استفاده از selectorهای پایدار اسکریپتنویسی کنید، Playwright همچنان انتخابی عملگرایانه است؛ سریع، ارزان و با قابلیت ادغام آسان در خط لولههای CI. زمانی که با چیدمانهای ناشناخته، دفاعهای تهاجمی ضد اتوماسیون یا تغییرات مکرر در UI روبرو هستید، یک مرورگر عامل (agent browser) مانند BrowserAct مسیر منعطفتر و مقاومتری را ارائه میدهد. به اجرای موفقیتآمیز کورکورانه اعتماد نکنید؛ تأیید کنید که صفحه همانگونه رفتار کرده است که یک انسان رفتار میکند، و ابزاری را انتخاب کنید که با پروفایل ریسک سایت هدف شما مطابقت داشته باشد.