ផ្នែកបន្ថែមកម្មវិធីរុករកអាចជួបបញ្ហាប្រឈមផ្ទៀងផ្ទាត់ពីពីរកន្លែងផ្សេងគ្នា៖ ប្រូកស៊ីដែលដឹកសំណើ និងគេហទំព័រគោលដៅ។ ពួកវាមិនត្រូវទទួលគណនីដូចគ្នាដោយស្វ័យប្រវត្តិទេ។

អ្នកបែងចែកដែលមានប្រយោជន៍នៅក្នុងព្រឹត្តិការណ៍ webRequest.onAuthRequired របស់ Chrome គឺ isProxy។ ការហៅត្រឡប់ដែលដកការពិនិត្យនោះ គ្រាន់តែដើម្បីឱ្យការជំរុញបាត់ អាចចាប់ផ្តើមផ្តល់ព័ត៌មានសម្គាល់ប្រូកស៊ីទៅបញ្ហាប្រឈមប្រភព។

ផ្គូផ្គងប្រូកស៊ីដែលអ្នកចង់ទុកចិត្ត

ការពិនិត្យ isProxy គឺជាការចាប់ផ្តើម។ ដាក់កម្រិតការគ្រប់គ្រងផងដែរទៅអ្នកប្រកួតប្រជែងប្រូកស៊ីដែលរំពឹងទុក និងបរិបទសំណើ។ ផ្នែកបន្ថែមដែលគ្រប់គ្រងចំណុចបញ្ចប់ជាច្រើន គួរជ្រើសរើសគណនីដែលជាកម្មសិទ្ធិរបស់ចំណុចបញ្ចប់នោះ មិនមែនពាក្យសម្ងាត់សកលមួយសម្រាប់រាល់បញ្ហាប្រឈមទេ។

កុំសន្មតថាការកំណត់ផ្លូវប្រូកស៊ី និងការគ្រប់គ្រងការចូលរបស់វា គឺជាការអនុញ្ញាតមួយ ឬការហៅ API មួយ។ Chrome ចងក្រងវាដោយឡែក។ ប្រើឯកសារយោង webRequest បច្ចុប្បន្នសម្រាប់ទិន្នន័យព្រឹត្តិការណ៍ និងការអនុញ្ញាតផ្ទៀងផ្ទាត់។ ឧទាហរណ៍នៃការចុះឈ្មោះអ្នកស្តាប់ Manifest V3 បង្ហាញការចុះឈ្មោះស្របគ្នា និងការជ្រើសរើសគណនីនៅក្នុងការហៅត្រឡប់។

ពិនិត្យជំនាន់ manifest

ឧទាហរណ៍ដែលនិយាយដល់ API WebRequest ពិសោធន៍ មកពីការចេញផ្សាយផ្នែកបន្ថែមចាស់។ តម្រូវការការអនុញ្ញាតបច្ចុប្បន្នអាស្រ័យលើជំនាន់ manifest របស់ផ្នែកបន្ថែម និងគំរូដាក់ពង្រាយ។ ជាពិសេស ការគ្រប់គ្រងការផ្ទៀងផ្ទាត់មានផ្លូវអនុញ្ញាតដែលគាំទ្រដោយខ្លួនឯង។ ឧទាហរណ៍អ្នកស្តាប់រារាំងដែលហួសសម័យមិនគ្រប់គ្រាន់ដើម្បីបង្ហាញថាផ្នែកបន្ថែម Manifest V3 អាចដំណើរការវាដោយមិនផ្លាស់ប្តូរ។

អ្នកគ្រប់គ្រងត្រឹមត្រូវក៏ត្រូវជៀសវាងការព្យាយាមឡើងវិញគ្មានទីបញ្ចប់លើព័ត៌មានសម្គាល់ដែលត្រូវបានបដិសេធដូចគ្នា។ ចាត់ទុកបញ្ហាប្រឈមទីពីរបន្ទាប់ពីផ្តល់គណនី ជាភស្តុតាងដែលត្រូវស៊ើបអង្កេត មិនមែនជាសំណើដើម្បីចាក់ពាក្យសម្ងាត់ឡើងវិញជារៀងរហូត។

ព័ត៌មានសម្គាល់គួរតែនៅក្នុងផ្លូវគ្រប់គ្រងការពារសមស្របរបស់ផ្នែកបន្ថែម។ កុំបោះពុម្ពផ្សាយវានៅក្នុងឯកសារ PAC ឬដាក់កូដរឹងក្នុងគំរូដែលចែកចាយ។ គោលដៅគឺការចូលប្រូកស៊ីដែលមានវិសាលភាពចង្អៀត មិនមែនជាច្បាប់ទូទាំងកម្មវិធីរុករក ដែលឆ្លើយតបនឹងរាល់បញ្ហាប្រឈមផ្ទៀងផ្ទាត់ដោយអាថ៌កំបាំងដូចគ្នា។

អត្ថបទពាក់ព័ន្ធ