في حزمة Rust المسماة headless_chrome يحدد إعداد تشغيل المتصفح وسيط HTTP. ويوفر معالج Fetch في التبويب الحساب عندما يطلبه Chromium:

let proxy = "http://proxy.example:8080";
let options = headless_chrome::LaunchOptions::default_builder()
    .proxy_server(Some(proxy))
    .build()?;
let browser = headless_chrome::Browser::new(options)?;
let tab = browser.new_tab()?;

tab.enable_fetch(None, Some(true))?;
tab.authenticate(Some(proxy_user), Some(proxy_password))?;
tab.navigate_to("https://www.example.org/")?;
tab.wait_until_navigated()?;

تنقل الدالة المحيطة الأخطاء، وproxy_user وproxy_password قيمتان من نوع String تأتيان من إعداد الحساب القائم في التطبيق. أعدّ المصادقة قبل أن يتمكن التنقل من إطلاق التحدي.

الوسيط الثاني في enable_fetch يفعّل أحداث المصادقة. ولا يعتبر Chromium معلومات المستخدم المضمنة في --proxy-server بمثابة تبادل بيانات الاعتماد هذا.

أبق المتصفح والتبويب حيّين طوال العمل. وإذا كان هناك أيضا اعتراض Fetch مخصص مثبت، فحدد من يكمل الطلبات الموقوفة ومن يجيب عن التحديات؛ فترك طلب موقوف دون حل قد يعطل التنقل.

يفترض إعداد المصادقة البسيط هذا في التبويب أنه التحدي المقصود للوكيل. أما سير عمل يتضمن مصادقة أصل غير ذي صلة فيحتاج تحديد نطاق التحدي صراحة بدلا من إعادة استخدام حساب الوسيط لكل خادم. كما أن قيد Chromium في SOCKS5 على اسم المستخدم وكلمة المرور منفصل عن مسار مصادقة HTTP هذا.

مقالات ذات صلة