השכבות שמאחורי בקשת Mechanize HTTPS דרך פרוקסי

ראה כיצד Mechanize, מודול פרוטוקול ה-HTTPS של LWP וה-backend של SSL משתפים פעולה כדי לנתב, לבצע מנהרה ולאמת בקשת HTTPS אחת.

הגדר את המסלול על אובייקט ה-Mechanize לפני השליפה:

use WWW::Mechanize;

my $mech = WWW::Mechanize->new(timeout => 30);
$mech->proxy(
    ['http', 'https'],
    'http://proxy.example.net:8080',
);

השתמש במאזין ה-HTTP המיועד בדוגמה; לבקשות מורשות ליעדים ציבוריים, המועמדים נמצאים ברשימת פרוקסי HTTP. המערך מפרט את סכימות היעד. נקודת הקצה http:// מספקת מסלול CONNECT רגיל ל-HTTPS: HTTP אל הפרוקסי, מנהרה אל היעד, ואז TLS של היעד. אם הפריסה משתמשת במקום זאת בהגדרות סביבה, $mech->env_proxy היא החלופה; ייבואן לאחר מכן עלול לשנות מסלול שהוקצה בקוד.

Mechanize יורש את רשת ה-LWP::UserAgent במקום לספק מנוע פרוקסי HTTPS נפרד:

  • Mechanize מספק קישורים, טפסים והתנהגות של הדף הנוכחי.
  • LWP::UserAgent והעברת ה-HTTP שלו בוחרים את המסלול ומארגנים את CONNECT.
  • LWP::Protocol::https מספק טיפול ב-HTTPS ומשדרג את החיבור.
  • Net::HTTPS עם ה-backend של SSL מספק את השקע בעל יכולת TLS, בדרך כלל IO::Socket::SSL בתצורות מודרניות.

backend של SSL מותקן אינו בוחר בעצמו פרוקסי. שמור את שם המארח המקורי של HTTPS בכתובת ה-URL: קבלת CONNECT אינה מאמתת את התעודה של אותו אתר.

בתחזוקת רכיבים ישנים, הבחן בין הגבולות האלה. libwww-perl 6.06 ו-LWP::Protocol::https 6.06 המופץ בנפרד הציגו תיקונים מתואמים ל-CONNECT רגיל ב-HTTP. גרסת UserAgent לבדה אינה מזהה את מודול ה-HTTPS. LWP::Protocol::https 6.15 הוסיף תיקון לנקודות קצה של פרוקסי עם TLS, שסכימת ה-https:// שלהן מוסיפה TLS לפרוקסי לפני TLS של היעד.

תצורות ישנות יותר של Net::SSL/Crypt::SSLeay יכולות להשתמש במקום זאת במנגנון הסביבה המתועד HTTPS_PROXY של אותו backend. אל תחיל את המתכון שלו על מסלול IO::Socket::SSL המודרני, שבו LWP אחראי על הניתוב.

השתמש בשלב הראשון שנכשל כדי לבחור את הרכיב: מטפל HTTPS חסר נוגע למודול הפרוטוקול; CONNECT שנדחה נוגע למסלול, לאישורים או למדיניות; שגיאת תעודה לאחר המנהרה נוגעת לזהות היעד ולאמון בו. שמור על האימות בעת החלפת הרכיב שאותו ראיה תומכת בו.

מאמרים קשורים