BrowserAct ਦੇ stealth browser ਨੇ ਇੱਕ bot-detection ਚੈੱਕ ਪਾਸ ਕਰ ਲਿਆ ਜਿਸ ਨੇ Playwright ਦੇ default headless run ਨੂੰ ਇੱਕ bot ਵਜੋਂ ਫਲੈਗ ਕੀਤਾ ਸੀ, ਭਾਵੇਂ ਦੋਵੇਂ ਸਕ੍ਰਿਪਟਾਂ ਨੇ ਇੱਕੋ ਜਿਹਾ login flow ਪੂਰਾ ਕੀਤਾ ਸੀ। ਇਹ ਅੰਤਰ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਜਦੋਂ ਤੁਹਾਨੂੰ ਅਜਿਹੀਆਂ ਸਾਈਟਾਂ ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜੋ automation ਦੇ ਵਿਰੁੱਧ ਸੁਰੱਖਿਆ ਕਰਦੀਆਂ ਹਨ, ਤਾਂ agent-based ਪਹੁੰਚ ਕਿਉਂ ਵਧੇਰੇ ਸੁਰੱਖਿਅਤ ਹੋ ਸਕਦੀ ਹੈ।
ਇਹ ਟੈਸਟ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ
Automation ਟੂਲ ਟੈਸਟਿੰਗ, ਡਾਟਾ ਇਕੱਠਾ ਕਰਨ ਅਤੇ ਅਕਾਊਂਟ ਮੈਨੇਜਮੈਂਟ ਨੂੰ ਸ਼ਕਤੀ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ। ਜ਼ਿਆਦਾਤਰ ਡਿਵੈਲਪਰ Playwright ਵਰਗੇ selector-driven frameworks ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਤੁਹਾਨੂੰ ਸਹੀ ਨਿਰਦੇਸ਼ ਲਿਖਣ—“ਇਸ CSS selector ਵਾਲੇ ਬਟਨ 'ਤੇ ਕਲਿੱਕ ਕਰੋ”—ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ ਅਤੇ ਨਤੀਜਿਆਂ ਦੀ ਤੇਜ਼ੀ ਨਾਲ ਜਾਂਚ ਕਰਦੇ ਹਨ। ਹਾਲਾਂਕਿ, ਆਧੁਨਿਕ ਸਾਈਟਾਂ ਅਜਿਹੇ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਇਨਬੈਡ ਕਰਦੀਆਂ ਹਨ ਜੋ headless browsers ਦੀ ਪਛਾਣ ਕਰਦੀਆਂ ਹਨ: ਜਿਵੇਂ ਕਿ ਇੱਕ generic user-agent string, webdriver property, ਜਾਂ ਮਨੁੱਖੀ ਵਰਗੇ interaction patterns ਦੀ ਘਾਟ। ਜਦੋਂ ਉਹ ਸੰਕੇਤ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ, ਤਾਂ ਸਾਈਟ ਰਿਕਵੈਸਟ ਨੂੰ ਬਲੌਕ ਕਰ ਦਿੰਦੀ ਹੈ ਜਾਂ CAPTCHA ਦਿਖਾਉਂਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਸਕ੍ਰਿਪਟ ਪ੍ਰਭਾਵਸ਼ੀਲ ਰਹਿਣ ਤੋਂ ਰਹਿ ਜਾਂਦੀ ਹੈ।
Agent browsers ਪਹਿਲਾਂ ਤੋਂ ਲਿਖੇ ਹੋਏ selectors 'ਤੇ ਨਿਰਭਰ ਕੀਤੇ ਬਿਨਾਂ ਇੱਕ ਮਨੁੱਖੀ ਉਪਭੋਗਤਾ ਦੀ ਨਕਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ। ਉਹ ਇੱਕ ਪੇਜ ਨੂੰ actionable elements ਦੇ ਸੰਗ੍ਰਹਿ ਵਜੋਂ ਮੰਨਦੇ ਹਨ, ਅਤੇ CSS path ਦੀ ਬਜਾਏ ਇੱਕ ਅੰਦਰੂਨੀ index ਵਿੱਚ ਆਪਣੀ ਸਥਿਤੀ ਦੇ ਆਧਾਰ 'ਤੇ ਕਿਸੇ ਇੱਕ ਨੂੰ ਚੁਣਦੇ ਹਨ। ਇਸ ਟੈਸਟ ਵਿੱਚ ਇੱਕ JavaScript-rendered login ਪੇਜ ਅਤੇ ਇੱਕ ਅਜਿਹੀ ਸਾਈਟ 'ਤੇ ਦੋਵਾਂ ਪਹੁੰਚਾਂ ਦੀ ਤੁਲਨਾ ਕੀਤੀ ਗਈ ਜੋ ਜਾਣਬੁੱਝ ਕੇ bots ਦੀ ਜਾਂਚ ਕਰਦੀ ਹੈ।
ਪ੍ਰਯੋਗ
ਮੈਂ ਦੋ ਸਕ੍ਰਿਪਟਾਂ ਲਿਖੀਆਂ ਜੋ ਇੱਕੋ ਕਦਮਾਂ ਨੂੰ ਪੂਰਾ ਕਰਦੀਆਂ ਹਨ: login ਪੇਜ ਲੋਡ ਕਰਨਾ, credentials ਭਰਨਾ, submit ਕਰਨਾ, ਅਤੇ inventory ਪੇਜ ਤੱਕ ਪਹੁੰਚਣਾ। ਇੱਕ ਸਕ੍ਰਿਪਟ ਨੇ Playwright ਨੂੰ ਇਸਦੇ default headless mode ਵਿੱਚ ਵਰਤਿਆ; ਦੂਜੀ ਨੇ BrowserAct ਦੇ stealth browser ਦੀ ਵਰਤੋਂ ਕੀਤੀ, ਜੋ ਉਹ fingerprints ਨੂੰ ਮਾਸਕ (mask) ਕਰਦਾ ਹੈ ਜੋ bot detection ਨੂੰ ਟ੍ਰਿਗਰ ਕਰਦੇ ਹਨ।
ਦੋਵਾਂ ਸਕ੍ਰਿਪਟਾਂ ਨੇ ਇੱਕ sandbox ਸਾਈਟ ਵਿਰੁੱਧ authentication ਕੀਤਾ, ਜੋ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਟੂਲ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ ਮੁੱਖ login flow ਕੰਮ ਕਰਦਾ ਹੈ। ਅੰਤਰ ਉਦੋਂ ਦਿਖਾਈ ਦਿੱਤਾ ਜਦੋਂ ਸਕ੍ਰਿਪਟਾਂ ਇੱਕ ਸਮਰਪਿਤ bot-detection ਪੇਜ 'ਤੇ ਗਈਆਂ ਜੋ ਇੱਕ JSON flag isBot ਰਿਟਰਨ ਕਰਦਾ ਹੈ। Playwright ਨੇ isBot: true ਰਿਪੋਰਟ ਕੀਤਾ, ਜਿਸ ਨਾਲ ਪੰਜ ਵੱਖ-ਵੱਖ detection ਚੈੱਕ ਟ੍ਰਿਗਰ ਹੋ ਗਏ। BrowserAct ਨੇ isBot: false ਰਿਟਰਨ ਕੀਤਾ, ਜੋ ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਪੇਜ ਨੇ ਇਸਨੂੰ ਇੱਕ ਆਮ ਮਨੁੱਖੀ ਵਿਜ਼ਿਟਰ ਵਜੋਂ ਮੰਨਿਆ।
ਮੈਂ ਇਸ ਅੰਤਰ ਦਾ ਕਾਰਨ ਦੋ ਤਕਨੀਕੀ ਵੇਰਵਿਆਂ ਵਿੱਚ ਲੱਭਿਆ। Playwright ਦੀ default configuration ਇੱਕ generic user-agent string ਭੇਜਦੀ ਹੈ ਅਤੇ webdriver flag ਨੂੰ ਖੁੱਲ੍ਹਾ ਛੱਡ ਦਿੰਦੀ ਹੈ—ਇਹ ਦੋਵੇਂ ਚੀਜ਼ਾਂ ਇੱਕ detection script ਲਈ ਪਛਾਣਨਾ ਆਸਾਨ ਹਨ। BrowserAct ਦਾ stealth mode user-agent ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਦਾ ਹੈ, webdriver property ਨੂੰ ਹਟਾ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਇਸਦੇ fingerprint ਨੂੰ ਇੱਕ ਆਮ desktop browser ਦੇ ਨਾਲ ਮਿਲਾ ਦਿੰਦਾ ਹੈ।
ਟੂਲ ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਕਿਵੇਂ ਵੱਖਰੇ ਹਨ
| ਪਹਿਲੂ (Aspect) | Playwright (default) | BrowserAct (stealth) |
|---|---|---|
| Interaction model | Selector-driven, deterministic | Agent-driven, index-based |
| ਪਹਿਲਾਂ ਤੋਂ ਲਿਖੇ selectors ਦੀ ਲੋੜ | ਲਾਜ਼ਮੀ; ਸਕ੍ਰਿਪਟ ਨੂੰ ਸਹੀ DOM structure ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ | ਲੋੜ ਨਹੀਂ; agent runtime 'ਤੇ actionable elements ਦੀ ਖੋਜ ਕਰਦਾ ਹੈ |
| Layout ਤਬਦੀਲੀਆਂ ਨੂੰ ਸੰਭਾਲਣਾ | ਜੇਕਰ selectors ਬਦਲਦੇ ਹਨ ਤਾਂ ਇਹ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ | ਜਦੋਂ ਤੱਕ element ਦੀਆਂ ਸਥਿਤੀਆਂ indexed list ਦੇ ਅੰਦਰ ਰਹਿੰਦੀਆਂ ਹਨ, ਇਹ ਚਲਦਾ ਰਹਿੰਦਾ ਹੈ |
| Bot ਚੈੱਕਾਂ ਦਾ ਖ਼ਤਰਾ | User-agent ਅਤੇ webdriver ਨੂੰ ਬਿਨਾਂ ਕਿਸੇ ਬਦਲਾਅ ਦੇ ਛੱਡ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ |
Fingerprints ਨੂੰ ਜਾਣਬੁੱਝ ਕੇ ਮਾਸਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ |
| ਆਮ ਵਰਤੋਂ ਦਾ ਮਾਮਲਾ | ਅੰਦਰੂਨੀ ਸਾਈਟਾਂ, ਸਥਿਰ UI, ਤੇਜ਼ ਟੈਸਟ ਚੱਕਰ | Anti-automation ਉਪਾਅਾਂ ਵਾਲੀਆਂ ਜਨਤਕ ਸਾਈਟਾਂ, ਲਗਾਤਾਰ ਬਦਲਦੇ ਪੇਜ |
ਇਹ ਟੇਬਲ ਵਿਵਹਾਰਕ ਸਮਝੌਤਿਆਂ (trade-offs) ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। Playwright ਉਦੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਸਾਈਟ ਨੂੰ ਕੰਟਰੋਲ ਕਰਦੇ ਹੋ ਅਤੇ ਸਥਿਰ element identifiers ਦੀ ਗਾਰੰਟੀ ਦੇ ਸਕਦੇ ਹੋ। ਇੱਕ agent browser ਉਦੋਂ ਵਧੀਆ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਪੇਜ ਦੇ ਢਾਂਚੇ ਦੀ ਭਵਿੱਖਬਾਣੀ ਨਹੀਂ ਕਰ ਸਕਦੇ ਜਾਂ ਜਦੋਂ ਸਾਈਟ ਸਰਗਰਮੀ ਨਾਲ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਬਲੌਕ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੀ ਹੈ।
ਕਿਸ ਨੂੰ ਫਾਇਦਾ ਹੁੰਦਾ ਹੈ ਅਤੇ ਕੌਣ ਜੋਖਮ ਵਿੱਚ ਹੈ
ਆਪਣੇ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ regression suites ਬਣਾਉਣ ਵਾਲੇ ਡਿਵੈਲਪਰ Playwright ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਲਾਗਤ ਘੱਟ ਅਤੇ ਟੈਸਟ ਦੀ ਰਫ਼ਤਾਰ ਉੱਚਾ ਰੱਖ ਸਕਦੇ ਹਨ। ਇਸਦੀ deterministic ਪ੍ਰਕਿਰਤੀ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਸਿੱਧੇ ਤੌਰ 'ਤੇ code regressions ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ, ਅਤੇ ਵਾਧੂ stealth ਲੇਅਰਾਂ ਦੀ ਘਾਟ ਗੁੰਝਲਤਾ ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ।
ਇਸਦੇ ਉਲਟ, ਉਹ ਟੀਮਾਂ ਜੋ ਡਾਟਾ ਸਕ੍ਰੈਪ ਕਰਦੀਆਂ ਹਨ, ਅਕਾਊਂਟ ਬਣਾਉਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਆਟੋਮੇਟ ਕਰਦੀਆਂ ਹਨ, ਜਾਂ ਮੁਕਾਬਲੇਬਾਜ਼ਾਂ ਦੀਆਂ ਸਾਈਟਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਦੀਆਂ ਹਨ, ਅਕਸਰ ਰੁਕਾਵਟਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਨਿਸ਼ਾਨਾ ਬਣਾਏ ਗਏ ਪੇਜ ਅਕਸਰ ਬਦਲਦੇ ਰਹਿੰਦੇ ਹਨ ਜਾਂ ਉਹਨਾਂ ਵਿੱਚ ਹਮਲਾਵਰ bot detection ਇਨਬੈਡ ਹੁੰਦਾ ਹੈ। ਅਜਿਹੇ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਇੱਕ agent browser ਤੁਰੰਤ "you are a bot" ਵਾਲੀ ਰੁਕਾਵਟ ਤੋਂ ਬਚਦਾ ਹੈ ਅਤੇ ਲੋੜੀਂਦੇ ਡਾਟਾ ਤੱਕ ਪਹੁੰਚਣਾ ਜਾਰੀ ਰੱਖਦਾ ਹੈ।
“ਇਹ ਕੰਮ ਕਰ ਗਿਆ” ਦੀਆਂ ਲੁਕੀਆਂ ਹੋਈਆਂ ਲਾਗਤਾਂ
ਮੈਂ ਚੇਤਾਵਨੀ ਦਿੰਦਾ ਹਾਂ ਕਿ ਇੱਕ ਸਫਲ exit code ਇਸ ਗੱਲ ਦੀ ਗਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦਾ ਕਿ automation ਉਮੀਦ ਅਨੁਸਾਰ ਹੋਇਆ ਹੈ। Playwright ਦੇ ਰਨ ਵਿੱਚ, ਸਕ੍ਰਿਪਟ ਬਿਨਾਂ ਕਿਸੇ ਗਲਤੀ (error) ਦੇ ਖਤਮ ਹੋ ਗਈ, ਫਿਰ ਵੀ ਪੇਜ ਨੇ ਅਜੇ ਵੀ ਰਿਕਵੈਸਟ ਨੂੰ ਇੱਕ bot ਮੰਨਿਆ। ਨਤੀਜਾ ਇੱਕ ਲੁਕੀ ਹੋਈ ਅਸਫਲਤਾ ਸੀ: ਅਗਲੇ ਕਦਮ (downstream steps) ਜੋ ਸਿਰਫ ਮਨੁੱਖੀ ਸਮੱਗਰੀ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਕਦੇ ਵੀ ਉਮੀਦ ਮੁਤਾਬਕ ਡਾਟਾ ਨਹੀਂ ਮਿਲਿਆ।
To surface such silent failures, inspect page evidence after each run: scroll position, document height, and network calls. If the DOM looks different from what a human would see, or if network traffic includes unexpected redirects to verification challenges, the automation likely missed its goal.
Bottom line
If you own the site and can script against stable selectors, Playwright remains the pragmatic choice—fast, cheap, and easy to integrate into CI pipelines. When you face unknown layouts, aggressive anti-automation defenses, or frequent UI churn, an agent browser like BrowserAct offers a more resilient route. Don’t trust a successful run blindly; verify that the page behaved as a human would, and pick the tool that matches the risk profile of your target site.