ប្រភព 3 ប្រភេទនៃស្នាមស្វ័យប្រវត្តិកម្ម Selenium និងព្រំដែននៃការកំណត់រចនាសម្ព័ន្ធ

នៅពេលដំណើរការ automation ជាមួយ Selenium អាចមានករណីដែល logic របស់ script ត្រឹមត្រូវ ប៉ុន្តែមិនទទួលបានលទ្ធផលដែលរំពឹងទុក។ មនុស្សជាច្រើននឹងគិតដំបូងថាត្រូវប្តូរ parameter មួយឬពីរ ប៉ុន្តែអ្វីដែលធ្វើឱ្យ environment មើលទៅខុសពីធម្មតា ជាទូទៅមិនមែនជា switch តែមួយទេ។ វាច្រើនកើតពីភាពខុសគ្នាជាច្រើននៅលើស្រទាប់ផ្សេងៗ។ ការបែងចែកស្រទាប់ទាំងនេះឱ្យច្បាស់ ជួយឱ្យដឹងថាអ្វីគួរកំណត់ និងអ្វីដែលធ្វើហើយក៏ប្រហែលមិនមានប្រយោជន៍។

ច្រក debugging និង runtime artifacts

វិធីដែល Selenium គ្រប់គ្រង browser អាចទុកស្នាមពីរប្រភេទ។ ប្រភេទទីមួយគឺ debugging port ដែល browser អាចបើកនៅពេលចាប់ផ្តើម ហើយ software ខាងក្រៅអាចប្រើវាដើម្បីគ្រប់គ្រង page។ ប្រភេទទីពីរគឺវត្ថុបន្ថែមនៅក្នុង runtime environment ដូចជា global variables ដែល driver ចាក់បញ្ចូល និងមាន prefix cdc_, driver objects បន្ថែមលើ window និងផ្នែកខ្លះនៃ object prototypes ដែលត្រូវបានផ្លាស់ប្តូរ។

វត្ថុទាំងនេះមិនមកពី webpage ទេ ប៉ុន្តែមកពី driver ផ្ទាល់។ ប្រសិនបើចាប់ផ្តើម browser តាមវិធីស្តង់ដារ វានឹងមាននៅទីនោះ មិនថា script ត្រូវបានសរសេរល្អប៉ុណ្ណាក៏ដោយ។

លក្ខណៈដែល page អាចអានបាន

ស្នាមមួយប្រភេទទៀតមិនស្ថិតនៅក្នុង driver ទេ ប៉ុន្តែនៅក្នុង JavaScript environment ដែល page អាចអានបាន។ ឧទាហរណ៍ដែលគេនិយាយដល់ញឹកញាប់បំផុតគឺ navigator.webdriver។

លក្ខណៈនេះអាចមានតម្លៃ 3 ប្រភេទ។ true មានន័យថា browser កំពុងត្រូវបានគ្រប់គ្រងដោយ automation tool, false មានន័យថាមិនត្រូវបានគ្រប់គ្រង ហើយ undefined មានន័យថាព័ត៌មានពាក់ព័ន្ធមិនអាចទទួលបាន ជាទូទៅព្រោះ browser មិនបង្ហាញ property នេះ ឬវាត្រូវបានដំណើរការផ្លាស់ប្តូរ។ នៅពេលមនុស្សប្រើប្រាស់ធម្មតា វាជា false ឬ undefined ខណៈ Selenium ចាប់ផ្តើមតាមលំនាំដើមជាមួយ true។

នៅជុំវិញវាមាន parameters ជាច្រើនទៀត៖ User-Agent, ប្រព័ន្ធប្រតិបត្តិការ និង browser version, screen resolution, time zone, ភាសា, Canvas, WebGL, AudioContext, បញ្ជី fonts, GPU model និងចំនួន CPU cores។ ព័ត៌មានទាំងនេះបញ្ចូលគ្នាជាអ្វីដែលជាទូទៅហៅថា browser fingerprint។ ឧបករណ៍របស់អ្នកប្រើប្រាស់ពិតប្រាកដមានភាពខុសគ្នាដោយសារប្រព័ន្ធ software និងទម្លាប់ប្រើប្រាស់ ដូច្នេះ fingerprints ក៏បែកចេញពីគ្នាតាមធម្មជាតិ។ ផ្ទុយទៅវិញ browser ដែលដំណើរការជាមួយ default automation configuration អាចបង្ហាញការរួមបញ្ចូលដែលស្រដៀងគ្នាខ្លាំង ហើយងាយត្រូវចាត់ចូលក្នុង pattern ដែលគេស្គាល់។

ភាពខុសគ្នាពី startup mode និង rendering timing

ប្រភេទទីបីមិនពឹងលើ property ណាមួយតែមួយទេ ប៉ុន្តែមកពីរបៀបចាប់ផ្តើម និង render browser ជារួម។

ការចាប់ផ្តើមជាមួយ automation flags, ដំណើរការក្នុង headless mode, window size និង screen parameters មិនត្រូវគ្នា, ការរួមបញ្ចូល font rendering និង graphics driver មិនសមហេតុផល ឬពេលវេលាពី page load ដល់អាចប្រើបានមានភាពស្មើពេក មួយៗដោយឡែកមិនមែនជាភស្តុតាងទេ។ ប៉ុន្តែបើកើតរួមគ្នា វាអាចបង្កើត environment ដែលមើលទៅមិនសូវដូចឧបករណ៍ដែលមនុស្សពិតប្រើ។

Headless គឺជាឧទាហរណ៍ជាក់ស្តែង។ headless mode របស់ Chrome ជំនាន់ថ្មីៗស្រដៀង browser ធម្មតាច្រើនជាងប៉ុន្មានឆ្នាំមុន ប៉ុន្តែបើប្រៀបនឹង regular mode វានៅតែងាយបង្ហាញ automation characteristics ជាពិសេសនៅលើ site ដែលមាន risk controls តឹងរ៉ឹង។

អ្វីដែលអាចកំណត់ដោយសមហេតុផល

Time zone, ភាសា, screen resolution និងបញ្ជី fonts មិនមែនមានតែក្នុង automation ទេ។ ឧបករណ៍ពិតប្រាកដក៏មានភាពខុសគ្នាតាមធម្មជាតិ។ អ្វីសំខាន់គឺ internal consistency៖ time zone គួរត្រូវគ្នានឹងតំបន់ network exit, ភាសាគួរត្រូវគ្នានឹងតំបន់ដែលប្រើជាទូទៅ ហើយ resolution មិនគួរផ្ទុយនឹង hardware profile។

និយាយឱ្យសាមញ្ញ គោលដៅមិនមែនធ្វើឱ្យ environment មើលទៅពិសេសទេ ប៉ុន្តែធ្វើឱ្យវាសមហេតុផលនៅខាងក្នុង។ ប្រសិនបើឧបករណ៍មួយមើលទៅថាចូលពីអាល្លឺម៉ង់ ប៉ុន្តែ browser រាយការណ៍ U.S. West Coast time zone, system language មានតែអង់គ្លេស ហើយ screen resolution ជាប្រភេទដែលជាញឹកញាប់ឃើញនៅ virtual display នោះ ការរួមបញ្ចូលទាំងនេះគ្រប់គ្រាន់ឱ្យមើលទៅខុសពីធម្មតា។

ហេតុនេះហើយ environment settings គួរត្រូវបានរក្សាទុកក្នុងប្រព័ន្ធដែលអាចនៅបានយូរ។ ប្តូរ time zone ថ្ងៃនេះ ហើយភ្លេច language ថ្ងៃស្អែក អាចបង្កើត inconsistency អាក្រក់ជាងមិនប្តូរអ្វីទាំងអស់។

អ្វីដែលព្យាយាមលាក់ automation ខ្លួនវា និងហេតុអ្វីមិនគួរធ្វើ

មាន technique មួយប្រភេទទៀតដែលផ្តោតដោយផ្ទាល់លើស្នាម៖ លុប navigator.webdriver, លុប variables ដែល driver ចាក់បញ្ចូល, លាក់ driver objects ឬរារាំង detector មិនឱ្យអាន automation status។

បញ្ហាគឺ វាប្តូរតែផ្ទៃខាងក្រៅ មិនមែនអាកប្បកិរិយាមូលដ្ឋានទេ។ Detection យូរមកហើយមិនពិនិត្យតែ property មួយទេ ហើយការអាន attributes គ្រាន់តែជាស្រទាប់ខាងលើបំផុត។ Driver update, ការផ្លាស់ប្តូរ execution order របស់ detection script ឬ detector ដែលរំលង JavaScript ហើយទៅមើល low-level rendering results និងការរួមបញ្ចូល device characteristics ដោយផ្ទាល់ អាចធ្វើឱ្យការកែចាស់ៗអស់ប្រសិទ្ធភាព។ Maintenance cost នៅតែខ្ពស់ ខណៈអត្ថប្រយោជន៍បន្តថយចុះ។

ជាក់ស្តែងជាងនេះ សកម្មភាពបែបនេះជាញឹកញាប់ស្ថិតត្រង់តំបន់ដែល terms of service របស់ platform កំណត់ថាជាការរំលង technical protection measures។ ការសរសេរ script ឱ្យស្អាតមិនផ្លាស់ប្តូរធម្មជាតិរបស់សកម្មភាពទេ គ្រាន់តែព្រោះបានកែ properties មួយចំនួន។

Network layer មិនអាចដោះស្រាយដោយ script បាន

ទោះ browser environment មើលទៅមិនមានបញ្ហា ក៏ network layer នៅតែអាចសម្គាល់ session បាន។ វាអាចពិនិត្យថា IP មកពី data center, cloud server ឬ proxy network; historical reputation និង ASN របស់ IP range; geolocation; request density ពី IP ដូចគ្នា; និងថា IP នោះចូលទៅ accounts ឬ pages ជាច្រើនក្នុងរយៈពេលខ្លីឬអត់។ Cookies, Sessions និង login state ក្នុង requests ក៏អាចត្រូវបានយកមកភ្ជាប់គ្នាផងដែរ។

បញ្ហាទាំងនេះមិនអាចដោះស្រាយនៅក្នុង script បានទេ ត្រូវគ្រប់គ្រងនៅ environment layer៖ មាន network exit ផ្សេងសម្រាប់ task នីមួយៗ, exit region និង environment region ត្រូវគ្នា និងអាចគ្រប់គ្រង request pacing បាន។ នៅពេលបំបែក multi-task, សមត្ថភាពដូច PurpleMark ជាទូទៅស្ថិតនៅស្រទាប់នេះ ដោយផ្តល់ independent browser environment និង network exit សម្រាប់ task នីមួយៗ ខណៈរក្សា geographic parameters ឱ្យស្របគ្នា។

លំដាប់ពិនិត្យជាក់ស្តែងនៅពេលត្រូវបាន block

លំដាប់សមហេតុផលគឺ៖ មុនដំបូងពិនិត្យ network layer សម្រាប់ IP type, stability និង geographic consistency; បន្ទាប់មកពិនិត្យថា environment ខាងក្នុងស្របគ្នារវាង time zone, ភាសា, resolution និង fonts ឬអត់; បន្ទាប់ពិនិត្យ behavior timing ដូចជា waits មានតម្លៃថេរជានិច្ច ឬ input បញ្ចប់ភ្លាមៗ; ហើយចុងក្រោយទើបពិនិត្យ driver-level automation properties។

ហេតុផលគឺសាមញ្ញ៖ driver-level artifacts មិនមែនជាចំណុចសំខាន់នៃ detection ទៀតទេ។ ដាក់វាជាជំហានដំបូងនៃ troubleshooting ជាទូទៅគ្រាន់តែខាតពេល។

ព្រំដែន

វិធានបច្ចេកទេសអាចកាត់បន្ថយឱកាសត្រូវបានសម្គាល់ ប៉ុន្តែមានបន្ទាត់ខ្លះមិនគួរឆ្លងកាត់៖ គោរព robots rules និង terms of service របស់ target site, មិនប្រមូល personal information, មិនរំលង technical protection measures, គ្រប់គ្រង request frequency និងមិនរំខានដល់ការដំណើរការធម្មតារបស់ service។