בחרו את ה-proxy של Chromote לפני ש-Chrome מתחיל
שמרו על ארגומנטי הדפדפן הקיימים של Chromote, הוסיפו את מתג ה-proxy והפעילו אובייקט Chrome חדש עבור אותו מסלול.
הפעלה של Chromote משוחחת עם תהליך Chrome. בקשות הדפדפן שלו עוקבות אחר תצורת ה-proxy של אותו תהליך, לכן הגדירו את הארגומנטים לפני יצירתו:
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; נקודת קצה מרשימת ה-proxy של HTTP יכולה למלא את כתובת הדוגמה לגלישה ציבורית מורשית. השתמשו בכתובת socks5 במקום רק כאשר נקודת הקצה באמת מדברת SOCKS5. הסירו מתג proxy קיים שמתנגש בעת הרכבת וקטור הארגומנטים.
בצעו את פעולות ה-CDP המיועדות דרך session, ואז סגרו את ההפעלה, הבקר והדפדפן שבבעלותכם כחלק מניקוי עומס העבודה של R. מסלול ניקוי ב-R בסגנון try/finally שימושי אם הניווט מעלה שגיאה.
ביישומים שמשתמשים בדפדפן ברירת המחדל המשותף של Chromote, set_chrome_args משנה את ברירות המחדל לבניית דפדפן עתידית. הוא אינו מפעיל מחדש תהליך קיים. יצירת אובייקט Chrome מפורש, כמתואר לעיל, הופכת את הבעלות ואת זמן ההתחלה לגלויים.
סביבת http_proxy או https_proxy של R עצמו יכולה להגדיר מוריד של R בלי לשנות את הדפדפן הזה. באותו אופן, שינוי המסלול של Chrome אינו מגדיר קריאת API נפרדת של R. זהו איזה צד של חיבור ה-CDP שולח את הבקשה.