Chromote-ის სესია ესაუბრება Chrome-ის პროცესს. ბრაუზერის მოთხოვნები მიჰყვება ამ პროცესის პროქსის კონფიგურაციას, ამიტომ არგუმენტები მის შექმნამდე დააყენეთ:

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)

ეს ინარჩუნებს Chromote-ის არსებულ ნაგულისხმევ არგუმენტებს და ამატებს HTTP მსმენელს; HTTP პროქსების სიიდან აღებულმა საბოლოო წერტილმა შეიძლება შეავსოს მაგალითის URL დაშვებული საჯარო დათვალიერებისთვის. ნაცვლად ამისა გამოიყენეთ socks5 URL მხოლოდ მაშინ, როცა საბოლოო წერტილი ნამდვილად ლაპარაკობს SOCKS5-ზე. არგუმენტების ვექტორის აწყობისას მოხსენით კონფლიქტური არსებული პროქსის გადამრთველი.

შეასრულეთ განზრახული CDP ოპერაციები session-ის მეშვეობით, შემდეგ დახურეთ სესია, კონტროლერი და თქვენი საკუთარი ბრაუზერი R დატვირთვის გასუფთავების ნაწილად. try/finally სტილის R გასუფთავების გზა სასარგებლოა, თუ ნავიგაცია შეცდომას აგდებს.

აპლიკაციებისთვის, რომლებიც იყენებენ Chromote-ის საერთო ნაგულისხმევ ბრაუზერს, set_chrome_args ცვლის ნაგულისხმევ მნიშვნელობებს მომავალი ბრაუზერის აგებისთვის. ის არ გადაამუშავებს არსებულ პროცესს. გამოკვეთილი Chrome ობიექტის შექმნა, როგორც ზემოთ, თვალსაჩინოს ხდის საკუთრებას და გაშვების დროს.

R-ის საკუთარ http_proxy ან https_proxy გარემოს შეუძლია R ჩამომტვირთავის კონფიგურაცია ამ ბრაუზერის შეუცვლელად. ანალოგიურად, Chrome-ის მარშრუტის შეცვლა არ აკონფიგურირებს ცალკე R API გამოძახებას. დაადგინეთ, CDP კავშირის რომელი მხარე აგზავნის მოთხოვნას.

დაკავშირებული სტატიები