In Chromote-sesje praat mei in Chrome-proses. De browserfersiken fan dat proses folgje de proxykonfiguraasje fan dat proses, dus set de arguminten foar't jo it meitsje:

args <- c(
  chromote::get_chrome_args(),
  "--proxy-server=http://proxy.example:8080"
)
browser <- chromote::Chrome$new(args = args)
controller <- chromote::Chromote$new(browser = browser)
session <- chromote::ChromoteSession$new(parent = controller)

Dit behâldt de besteande standertarguminten fan Chromote en foegjet de HTTP-harker ta; in einpunt út 'e HTTP-proxylist kin de foarbyld-URL ynfolje foar tastien iepenbier browsen. Brûk ynstee in socks5-URL allinnich as it einpunt echt SOCKS5 praat. Ferwiderje in tsjinstridige besteande proxyskeakel by it gearstallen fan de argumintfektor.

Fier de bedoelde CDP-operaasjes út fia session, en slút dan de sesje, de controller en de eigendom-browser as ûnderdiel fan 'e opromming fan 'e R-wurklast. In R-oprommingspaad yn try/finally-styl is nuttich as navigaasje in flater smyt.

Foar applikaasjes dy't de dielde standertbrowser fan Chromote brûke, feroaret set_chrome_args de standerten foar takomstige browserbou. It start gjin besteand proses opnij. It meitsjen fan in eksplisyt Chrome-objekt, lykas hjirboppe, makket eigendom en starttiid sichtber.

R syn eigen http_proxy- as https_proxy-omjouwing kin in R-downloader konfigurearje sûnder dizze browser te feroarjen. Likegoed konfigurearret it feroarjen fan Chrome syn rûte gjin aparte R API-oprop. Identifisearje hokker kant fan 'e CDP-ferbining it fersyk stjoert.

Relatearre artikelen