BrowserAct ನ ಸ್ಟೆಲ್ತ್ ಬ್ರೌಸರ್ (stealth browser) ಬಾಟ್-ಡಿಟೆಕ್ಷನ್ ಚೆಕ್ ಅನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಪಾಸಾಯಿತು, ಆದರೆ Playwright ನ ಡಿಫಾಲ್ಟ್ ಹೆಡ್‌ಲೆಸ್ ರನ್ ಅನ್ನು ಬಾಟ್ ಎಂದು ಗುರುತಿಸಲಾಯಿತು. ಎರಡೂ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ಒಂದೇ ರೀತಿಯ ಲಾಗಿನ್ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪೂರ್ಣಗೊಳಿಸಿದರೂ ಸಹ ಈ ವ್ಯತ್ಯಾಸ ಕಂಡುಬಂದಿದೆ. ಆಟೊಮೇಷನ್ ಅನ್ನು ತಡೆಯುವ ಸೈಟ್‌ಗಳೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಬೇಕಾದಾಗ ಏಜೆಂಟ್-ಆಧಾರಿತ ವಿಧಾನವು ಏಕೆ ಹೆಚ್ಚು ಸುರಕ್ಷಿತವಾಗಿರಬಹುದು ಎಂಬುದನ್ನು ಈ ವ್ಯತ್ಯಾಸವು ತೋರಿಸುತ್ತದೆ.

ಈ ಪರೀಕ್ಷೆಯ ಮಹತ್ವವೇನು

ಆಟೊಮೇಷನ್ ಪರಿಕರಗಳು ಟೆಸ್ಟಿಂಗ್, ಡೇಟಾ ಸಂಗ್ರಹಣೆ ಮತ್ತು ಅಕೌಂಟ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಅನ್ನು ಸುಗಮಗೊಳಿಸುತ್ತವೆ. ಹೆಚ್ಚಿನ ડેವಲಪರ್‌ಗಳು Playwright ನಂತಹ ಸೆಲೆಕ್ಟರ್-ಚಾಲಿತ (selector-driven) ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳನ್ನು ಬಳಸುತ್ತಾರೆ, ಏಕೆಂದರೆ ಅವುಗಳು "ಈ CSS ಸೆಲೆಕ್ಟರ್ ಇರುವ ಬಟನ್ ಕ್ಲಿಕ್ ಮಾಡಿ" ಎಂಬಂತಹ ನಿಖರವಾದ ಸೂಚನೆಗಳನ್ನು ಬರೆಯಲು ಮತ್ತು ಫಲಿತಾಂಶಗಳನ್ನು ವೇಗವಾಗಿ ಪರಿಶೀಲಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತವೆ. ಆದರೆ, ಆಧುನಿಕ ಸೈಟ್‌ಗಳು ಹೆಡ್‌ಲೆಸ್ ಬ್ರೌಸರ್‌ಗಳನ್ನು ಪತ್ತೆಹಚ್ಚುವ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ: ಉದಾಹರಣೆಗೆ ಸಾಮಾನ್ಯ user-agent ಸ್ಟ್ರಿಂಗ್, webdriver ಪ್ರಾಪರ್ಟಿ ಅಥವಾ ಮಾನವನಂತಹ ಸಂವಹನ ಮಾದರಿಗಳ ಕೊರತೆ. ಇಂತಹ ಸಂಕೇತಗಳು ಕಂಡುಬಂದಾಗ, ಸೈಟ್ ಆ ವಿನಂತಿಯನ್ನು (request) ತಡೆಯುತ್ತದೆ ಅಥವಾ CAPTCHA ಅನ್ನು ತೋರಿಸುತ್ತದೆ, ಇದರಿಂದ ಸ್ಕ್ರಿಪ್ಟ್ ತನ್ನ ಕೆಲಸವನ್ನು ಮಾಡಲು ಅಸಮರ್ಥವಾಗುತ್ತದೆ.

ಏಜೆಂಟ್ ಬ್ರೌಸರ್‌ಗಳು ಮೊದಲೇ ಬರೆದಿಟ್ಟ ಸೆಲೆಕ್ಟರ್‌ಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗದೆ, ಒಬ್ಬ ಮಾನವ ಬಳಕೆದಾರರನ್ನು ಅನುಕರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತವೆ. ಅವು ಪೇಜ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಎಲಿಮೆಂಟ್‌ಗಳ (actionable elements) ಸಂಗ್ರಹವಾಗಿ ಪರಿಗಣಿಸುತ್ತವೆ ಮತ್ತು CSS ಪಾತ್ ಬದಲಿಗೆ ಆಂತರಿಕ ಇಂಡೆಕ್ಸ್‌ನಲ್ಲಿರುವ ಅದರ ಸ್ಥಾನದ ಆಧಾರದ ಮೇಲೆ ಒಂದು ಎಲಿಮೆಂಟ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತವೆ. ಈ ಪರೀಕ್ಷೆಯು JavaScript-ರೆಂಡರ್ ಮಾಡಲಾದ ಲಾಗಿನ್ ಪೇಜ್ ಮತ್ತು ಬಾಟ್‌ಗಳನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಪತ್ತೆಹಚ್ಚುವ ಸೈಟ್ ಮೇಲೆ ಈ ಎರಡು ವಿಧಾನಗಳನ್ನು ಹೋಲಿಕೆ ಮಾಡಿತು.

ಪ್ರಯೋಗ

ನಾನು ಒಂದೇ ರೀತಿಯ ಹಂತಗಳನ್ನು ಅನುಸರಿಸುವ ಎರಡು ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಬರೆದಿದ್ದೇನೆ: ಲಾಗಿನ್ ಪೇಜ್ ಲೋಡ್ ಮಾಡುವುದು, ಕ್ರೆಡೆನ್ಶಿಯಲ್ಸ್ (credentials) ನಮೂದಿಸುವುದು, ಸಬ್ಮಿಟ್ ಮಾಡುವುದು ಮತ್ತು ಇನ್ವೆಂಟರಿ ಪೇಜ್ ತಲುಪುವುದು. ಒಂದು ಸ್ಕ್ರಿಪ್ಟ್ Playwright ಅನ್ನು ಅದರ ಡಿಫಾಲ್ಟ್ ಹೆಡ್‌ಲೆಸ್ ಮೋಡ್‌ನಲ್ಲಿ ಬಳಸಿತು; ಇನ್ನೊಂದು BrowserAct ನ ಸ್ಟೆಲ್ತ್ ಬ್ರೌಸರ್ ಅನ್ನು ಬಳಸಿತು, ಇದು ಬಾಟ್ ಡಿಟೆಕ್ಷನ್ ಅನ್ನು ಪ್ರಚೋದಿಸುವ ಫಿಂಗರ್‌ಪ್ರಿಂಟ್‌ಗಳನ್ನು ಮರೆಮಾಚುತ್ತದೆ.

ಎರಡೂ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ (sandbox) ಸೈಟ್‌ನಲ್ಲಿ ಯಶಸ್ವಿಯಾಗಿ ಲಾಗಿನ್ ಆದವು, ಇದು ಯಾವುದೇ ಪರಿಕರವನ್ನು ಬಳಸಿದರೂ ಮೂಲ ಲಾಗಿನ್ ಪ್ರಕ್ರಿಯೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಸಾಬೀತುಪಡಿಸಿತು. ಆದರೆ, ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು isBot ಎಂಬ JSON ಫ್ಲಾಗ್ ಅನ್ನು ನೀಡುವ ಬಾಟ್-ಡಿಟೆಕ್ಷನ್ ಪೇಜ್ ಅನ್ನು ಭೇಟಿ ಮಾಡಿದಾಗ ವ್ಯತ್ಯಾಸ ಕಂಡುಬಂದಿತು. Playwright isBot: true ಎಂದು ವರದಿ ಮಾಡಿತು, ಅಂದರೆ ಅದು ಐದು ಪ್ರತ್ಯೇಕ ಡಿಟೆಕ್ಷನ್ ಚೆಕ್‌ಗಳನ್ನು ಪಾಸು ಮಾಡಲು ವಿಫಲವಾಯಿತು. BrowserAct isBot: false ಎಂದು ನೀಡಿತು, ಅಂದರೆ ಆ ಪೇಜ್ ಅದನ್ನು ಸಾಮಾನ್ಯ ಮಾನವ ಭೇಟಿಗಾರನನ್ನಾಗಿ ಪರಿಗಣಿಸಿತು.

ಈ ವ್ಯತ್ಯಾಸಕ್ಕೆ ಎರಡು ತಾಂತ್ರಿಕ ಕಾರಣಗಳನ್ನು ನಾನು ಪತ್ತೆಹಚ್ಚಿದೆ. Playwright ನ ಡಿಫಾಲ್ಟ್ ಕಾನ್ಫಿಗರೇಶನ್ ಸಾಮಾನ್ಯ user-agent ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ಕಳುಹಿಸುತ್ತದೆ ಮತ್ತು webdriver ಫ್ಲಾಗ್ ಅನ್ನು ಬಹಿರಂಗವಾಗಿ ಬಿಡುತ್ತದೆ—ಇವೆರಡನ್ನೂ ಡಿಟೆಕ್ಷನ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ಸುಲಭವಾಗಿ ಪತ್ತೆಹಚ್ಚಬಹುದು. BrowserAct ನ ಸ್ಟೆಲ್ತ್ ಮೋಡ್ user-agent ಅನ್ನು ಮರುಬರೆಯುತ್ತದೆ, webdriver ಪ್ರಾಪರ್ಟಿಯನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ ಮತ್ತು ಅದರ ಫಿಂಗರ್‌ಪ್ರಿಂಟ್ ಅನ್ನು ಸಾಮಾನ್ಯ ಡೆಸ್ಕ್‌ಟಾಪ್ ಬ್ರೌಸರ್‌ನಂತೆಯೇ ಹೊಂದಿಸುತ್ತದೆ.

ಈ ಪರಿಕರಗಳು ಒಳಗಿನಿಂದ ಹೇಗೆ ಭಿನ್ನವಾಗಿವೆ

ಅಂಶ (Aspect) Playwright (default) BrowserAct (stealth)
ಸಂವಹನ ಮಾದರಿ (Interaction model) ಸೆಲೆಕ್ಟರ್-ಚಾಲಿತ, ಡಿಟರ್ಮಿನಿಸ್ಟಿಕ್ (deterministic) ಏಜೆಂಟ್-ಚಾಲಿತ, ಇಂಡೆಕ್ಸ್-ಆಧಾರಿತ
ಮೊದಲೇ ಬರೆದ ಸೆಲೆಕ್ಟರ್‌ಗಳ ಅಗತ್ಯತೆ ಕಡ್ಡಾಯ; ಸ್ಕ್ರಿಪ್ಟ್‌ಗೆ ನಿಖರವಾದ DOM ರಚನೆ ತಿಳಿದಿರಬೇಕು ಅಗತ್ಯವಿಲ್ಲ; ಏಜೆಂಟ್ ರನ್‌ಟೈಮ್‌ನಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಎಲಿಮೆಂಟ್‌ಗಳನ್ನು ಪತ್ತೆಹಚ್ಚುತ್ತದೆ
ಲೇಔಟ್ ಬದಲಾವಣೆಗಳ ನಿರ್ವಹಣೆ ಸೆಲೆಕ್ಟರ್‌ಗಳು ಬದಲಾದರೆ ಸ್ಕ್ರಿಪ್ಟ್ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ ಎಲಿಮೆಂಟ್‌ಗಳ ಸ್ಥಾನವು ಇಂಡೆಕ್ಸ್ಡ್ ಲಿಸ್ಟ್‌ನಲ್ಲಿ ಇರುವವರೆಗೆ ಕೆಲಸ ಮುಂದುವರಿಯುತ್ತದೆ
ಬಾಟ್ ಚೆಕ್‌ಗಳಿಗೆ ಒಳಗಾಗುವಿಕೆ User-agent ಮತ್ತು webdriver ಬದಲಾಗದೆ ಇರುತ್ತದೆ ಫಿಂಗರ್‌ಪ್ರಿಂಟ್‌ಗಳನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಮರೆಮಾಚಲಾಗುತ್ತದೆ
ಸಾಮಾನ್ಯ ಬಳಕೆ (Typical use case) ಆಂತರಿಕ ಸೈಟ್‌ಗಳು, ಸ್ಥಿರವಾದ UI, ವೇಗದ ಟೆಸ್ಟ್ ಸೈಕಲ್‌ಗಳು ಆಟೊಮೇಷನ್ ತಡೆ措施ಗಳಿರುವ ಸಾರ್ವಜನಿಕ ಸೈಟ್‌ಗಳು, ನಿರಂತರವಾಗಿ ಬದಲಾಗುವ ಪೇಜ್‌ಗಳು

ಈ ಕೋಷ್ಟಕವು ಪ್ರಾಯೋಗಿಕ ವ್ಯತ್ಯಾಸಗಳನ್ನು ತೋರಿಸುತ್ತದೆ. ನೀವು ಸೈಟ್ ಅನ್ನು ನಿಯಂತ್ರಿಸುತ್ತಿದ್ದರೆ ಮತ್ತು ಸ್ಥಿರವಾದ ಎಲಿಮೆಂಟ್ ಐಡೆಂಟಿಫೈಯರ್‌ಗಳನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬಲ್ಲಾಗಿದ್ದರೆ Playwright ಅತ್ಯುತ್ತಮವಾಗಿದೆ. ಆದರೆ ಪೇಜ್ ರಚನೆಯನ್ನು ನೀವು ಊಹಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದಾಗ ಅಥವಾ ಸೈಟ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ತಡೆಯಲು ಸಕ್ರಿಯವಾಗಿ ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದಾಗ ಏಜೆಂಟ್ ಬ್ರೌಸರ್ ಹೆಚ್ಚು ಉಪಯುಕ್ತವಾಗುತ್ತದೆ.

ಯಾರು ಪ್ರಯೋಜನ ಪಡೆಯುತ್ತಾರೆ ಮತ್ತು ಯಾರು ಅಪಾಯದಲ್ಲಿದ್ದಾರೆ

ತಮ್ಮದೇ ಆದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗಾಗಿ ರಿಗ್ರೆಷನ್ ಸೂಟ್‌ಗಳನ್ನು (regression suites) ನಿರ್ಮಿಸುವ ಅಭಿವೃದ್ಧಿಪಡಿಸುವವರು (Developers) Playwright ಅನ್ನು ಬಳಸುವ ಮೂಲಕ ವೆಚ್ಚವನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು ಮತ್ತು ಪರೀಕ್ಷೆಯ ವೇಗವನ್ನು ಹೆಚ್ಚಿಸಬಹುದು. ಇದರ ಡಿಟರ್ಮಿನಿಸ್ಟಿಕ್ ಸ್ವಭಾವವು ವೈಫಲ್ಯಗಳನ್ನು ನೇರವಾಗಿ ಕೋಡ್ ರಿಗ್ರೆಷನ್‌ಗಳಿಗೆ (code regressions) ಸೂಚಿಸುತ್ತದೆ ಮತ್ತು ಹೆಚ್ಚುವರಿ ಸ್ಟೆಲ್ತ್ ಪದರಗಳಿಲ್ಲದ ಕಾರಣ ಸಂಕೀರ್ಣತೆ ಕಡಿಮೆಯಿರುತ್ತದೆ.

ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ, ಡೇಟಾವನ್ನು ಸ್ಕ್ರೇಪ್ ಮಾಡುವ (scrape), ಅಕೌಂಟ್ ರಚನೆಯನ್ನು ಆಟೊಮೇಷನ್ ಮಾಡುವ ಅಥವಾ ಸ್ಪರ್ಧಿಗಳ ಸೈಟ್‌ಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ತಂಡಗಳು ತಾರತಮ್ಯದ ಬಾಟ್ ಡಿಟೆಕ್ಷನ್ ಅಥವಾ ಪದೇ ಪದೇ ಬದಲಾಗುವ ಪೇಜ್‌ಗಳಿಂದಾಗಿ ಅಡೆತಡೆಗಳನ್ನು ಎದುರಿಸುತ್ತವೆ. ಅಂತಹ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಏಜೆಂಟ್ ಬ್ರೌಸರ್ "ನೀವು ಬಾಟ್" ಎಂಬ ತಕ್ಷಣದ ಅಡೆತಡೆಯನ್ನು ತಪ್ಪಿಸಿ, ಅವರಿಗೆ ಬೇಕಾದ ಡೇಟಾವನ್ನು ಪಡೆಯಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.

"ಇದು ಕೆಲಸ ಮಾಡಿತು" ಎಂಬ ಮಾತಿನ ಹಿಂದಿರುವ ಗುಪ್ತ ವೆಚ್ಚಗಳು

ಯಶಸ್ವಿ ಎಕ್ಸಿಟ್ ಕೋಡ್ (exit code) ಎಂದರೆ ಆಟೊಮೇಷನ್ ಉದ್ದೇಶಿತ ರೀತಿಯಲ್ಲಿ ನಡೆದಿದೆ ಎಂದರ್ಥವಲ್ಲ ಎಂದು ನಾನು ಎಚ್ಚರಿಸುತ್ತೇನೆ. Playwright ರನ್‌ನಲ್ಲಿ, ಸ್ಕ್ರಿಪ್ಟ್ ಯಾವುದೇ ದೋಷವಿಲ್ಲದೆ (error) ಮುಗಿಯಿತು, ಆದರೂ ಪೇಜ್ ಆ ವಿನಂತಿಯನ್ನು ಬಾಟ್ ಎಂದು ಪರಿಗಣಿಸಿತು. ಇದರ ಪರಿಣಾಮವಾಗಿ ಒಂದು ಗುಪ್ತ ವೈಫಲ್ಯ ಸಂಭವಿಸಿತು: ಮಾನವ-ಮಾತ್ರದ ಕಂಟೆಂಟ್ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುವ ಮುಂದಿನ ಹಂತಗಳು ನಿರೀಕ್ಷಿತ ಡೇಟಾವನ್ನು ಪಡೆಯಲೇ ಇಲ್ಲ.

ಇಂತಹ ಮೌನ ವೈಫಲ್ಯಗಳನ್ನು (silent failures) ಪತ್ತೆಹಚ್ಚಲು, ಪ್ರತಿ ರನ್ ನಂತರ ಪುಟದ ಪುರಾವೆಗಳನ್ನು ಪರಿಶೀಲಿಸಿ: ಸ್ಕ್ರೋಲ್ ಸ್ಥಾನ (scroll position), ಡಾಕ್ಯುಮೆಂಟ್ ಎತ್ತರ (document height) ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ಕರೆಗಳನ್ನು (network calls) ಗಮನಿಸಿ. ಒಂದು ವೇಳೆ DOM ಮನುಷ್ಯರು ನೋಡುವ ರೀತಿಯಲ್ಲಿಲ್ಲದಿದ್ದರೆ, ಅಥವಾ ನೆಟ್‌ವರ್ಕ್ ಟ್ರಾಫಿಕ್‌ನಲ್ಲಿ ವೆರಿಫಿಕೇಶನ್ ಚಾಲೆಂಜ್‌ಗಳಿಗೆ (verification challenges) ಅನಿರೀಕ್ಷಿತ ರಿಡೈರೆಕ್ಟ್‌ಗಳು ಕಂಡುಬಂದರೆ, ಆಟೊಮೇಷನ್ ತನ್ನ ಗುರಿಯನ್ನು ತಲುಪಲು ವಿಫಲವಾಗಿರಬಹುದು.

ಸಾರಾಂಶ

ನೀವು ಸೈಟ್‌ನ ಮಾಲೀಕರಾಗಿದ್ದು, ಸ್ಥಿರ ಸೆಲೆಕ್ಟರ್‌ಗಳ (stable selectors) ಮೂಲಕ ಸ್ಕ್ರಿಪ್ಟ್ ಮಾಡಬಲ್ಲವರಾಗಿದ್ದರೆ, Playwright ಒಂದು ಪ್ರಾಯೋಗಿಕ ಆಯ್ಕೆಯಾಗಿದೆ—ಇದು ವೇಗವಾಗಿದೆ, ಅಗ್ಗವಾಗಿದೆ ಮತ್ತು CI ಪೈಪ್‌ಲೈನ್‌ಗಳಿಗೆ (CI pipelines) ಸುಲಭವಾಗಿ ಸಂಯೋಜಿಸಬಹುದು. ನೀವು ಅನಿಶ್ಚಿತ ಲೇಔಟ್‌ಗಳು, ತೀವ್ರವಾದ ಆಂಟಿ-ಆಟೊಮೇಷನ್ ರಕ್ಷಣಾ ಕ್ರಮಗಳು ಅಥವಾ ಪದೇ ಪದೇ ಬದಲಾಗುವ UI ಎದುರಿಸುತ್ತಿರುವಾಗ, BrowserAct ನಂತಹ ಏಜೆಂಟ್ ಬ್ರೌಸರ್ (agent browser) ಹೆಚ್ಚು ದೃಢವಾದ ಮಾರ್ಗವನ್ನು ಒದಗಿಸುತ್ತದೆ. ಯಶಸ್ವಿ ರನ್ ಅನ್ನು ಕುರುಡಾಗಿ ನಂಬಬೇಡಿ; ಪುಟವು ಮನುಷ್ಯರು ಬಳಸುವ ರೀತಿಯಲ್ಲೇ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ ಮತ್ತು ನಿಮ್ಮ ಗುರಿ ಸೈಟ್‌ನ ರಿಸ್ಕ್ ಪ್ರೊಫೈಲ್‌ಗೆ (risk profile) ಹೊಂದಿಕೆಯಾಗುವ ಸಾಧನವನ್ನು ಆರಿಸಿ.