Rust headless_chrome: itakda ang mga kredensyal ng HTTP proxy bago mag-navigate

Sa crate na Rust headless_chrome, pinipili ng setting ng paglunsad ng browser ang isang tagapamagitan ng HTTP. Ibibigay ng Fetch handler ng tab ang account kapag hiniling ito ng 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()?;

Ipinapasa ng nakapaligid na function ang mga error, at ang proxy_user at proxy_password ay mga halagang String mula sa umiiral na configuration ng account ng application. Itakda ang authentication bago pa mapukaw ng navigation ang hamon.

Binubuksan ng ikalawang argumento ng enable_fetch ang mga kaganapan ng authentication. Hindi itinuturing ng Chromium ang impormasyon ng user na naka-embed sa --proxy-server bilang palitan ng kredensyal na ito.

Panatilihing buhay ang browser at tab para sa gawain. Kung may naka-install ding custom na Fetch interception, tukuyin kung sino ang magpapatuloy ng mga nakapausang kahilingan at sino ang sasagot sa mga hamon; ang hindi nareresolbang nakapausang kahilingan ay maaaring huminto sa navigation.

Ipinapalagay ng simpleng authentication sa tab na ito ang inilaan na hamon ng proxy. Ang workflow na may authentication ng ibang origin ay nangangailangan ng malinaw na saklaw ng hamon sa halip na gamitin muli ang account ng tagapamagitan para sa bawat server. Hiwalay din ang limitasyon ng Chromium sa SOCKS5 sa username at password mula sa landas na ito ng HTTP authentication.