'n Chromote-sessie praat met 'n Chrome-proses. Sy blaaierversoeke volg daardie proses se proxy-konfigurasie, so stel die argumente voordat jy dit skep:

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 behou Chromote se bestaande verstekargumente en voeg die HTTP-luisteraar by; 'n eindpunt uit die HTTP-proxylys kan die voorbeeld-URL vul vir toegelate publieke blaaiery. Gebruik eerder 'n socks5-URL net wanneer die eindpunt werklik SOCKS5 praat. Verwyder 'n botsende bestaande proxy-skakel wanneer jy die argumentvektor saamstel.

Voer die beoogde CDP-bewerkings deur session uit, en sluit dan die sessie, beheerder en die blaaier wat jy besit as deel van die R-werklas se opruiming. 'n R-opruimingsroete in try/finally-styl is nuttig as navigasie 'n fout gee.

Vir toepassings wat Chromote se gedeelde verstekblaaier gebruik, verander set_chrome_args die verstekke vir toekomstige blaaierkonstruksie. Dit herbegin nie 'n bestaande proses nie. Om 'n eksplisiete Chrome-objek te skep, soos hierbo, maak eienaarskap en begin-tydsberekening sigbaar.

R se eie http_proxy- of https_proxy-omgewing kan 'n R-aftaai opstel sonder om hierdie blaaier te verander. Net so stel 'n verandering aan Chrome se roete nie 'n aparte R-API-oproep op nie. Identifiseer watter kant van die CDP-verbinding die versoek stuur.

Verwante artikels