Katika crate ya Rust headless_chrome, mpangilio wa kuanzisha kivinjari huchagua mpatanishi wa HTTP. Kishughulikia Fetch cha kichupo hutoa akaunti wakati Chromium inaiomba:

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()?;

Kitendakazi kinachozunguka husambaza hitilafu, na proxy_user na proxy_password ni thamani za String kutoka kwenye usanidi wa akaunti uliopo wa programu. Weka uthibitishaji kabla uvinjari haujasababisha changamoto.

Hoja ya pili ya enable_fetch huwasha matukio ya uthibitishaji. Chromium haichukui taarifa za mtumiaji zilizopachikwa katika --proxy-server kama ubadilishanaji huu wa vitambulisho.

Weka kivinjari na kichupo hai kwa muda wa kazi. Ikiwa pia kuna uingiliaji wa Fetch maalum uliosakinishwa, bainisha nani anaendelea na maombi yaliyosimamishwa na nani anajibu changamoto; ombi lililosimamishwa ambalo halijatatuliwa linaweza kusimamisha uvinjari.

Usanidi huu rahisi wa uthibitishaji kwenye kichupo unadhani changamoto ya proksi iliyokusudiwa. Mtiririko wa kazi wenye uthibitishaji wa origin isiyohusiana unahitaji upeo wa changamoto ulio wazi badala ya kutumia tena akaunti ya mpatanishi kwa kila seva. Kizuizi cha Chromium kwenye SOCKS5 kwa jina la mtumiaji na nenosiri pia ni tofauti na njia hii ya uthibitishaji wa HTTP.

Makala zinazohusiana