Վարդակով անցնող Mechanize HTTPS հարցման հետևում գտնվող շերտերը

Տեսեք, թե ինչպես Mechanize-ը, LWP-ի HTTPS արձանագրության մոդուլը և SSL backend-ը համագործակցում են մեկ HTTPS հարցում երթուղավորելու, թունելավորելու և ստուգելու համար:

Սահմանեք երթուղին Mechanize օբյեկտի վրա՝ նախքան բեռնումը:

use WWW::Mechanize;

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

Օգտագործեք օրինակում նախատեսված HTTP լսողը. թույլատրելի հանրային նպատակակետերին ուղղված հարցումների համար թեկնածուները գտնվում են HTTP վարդակների ցանկում: Զանգվածը նշում է նպատակակետի սխեմաները: http:// վերջնակետը HTTPS-ի համար տրամադրում է սովորական CONNECT երթուղի՝ HTTP դեպի վարդակ, թունել դեպի նպատակակետ, ապա նպատակակետի TLS: Եթե տեղակայումը փոխարենը օգտագործում է միջավայրի կարգավորումներ, $mech->env_proxy այլընտրանքն է. դրանք ավելի ուշ ներմուծելը կարող է փոխել կոդում նշանակված երթուղին:

Mechanize-ը ժառանգում է LWP::UserAgent ցանցային հնարավորությունները՝ փոխարենը առանձին HTTPS վարդակային շարժիչ տրամադրելու:

  • Mechanize-ը տրամադրում է հղումներ, ձևեր և ընթացիկ էջի վարքագիծ:
  • LWP::UserAgent-ը և նրա HTTP փոխադրումը ընտրում են երթուղին և կազմակերպում CONNECT-ը:
  • LWP::Protocol::https-ը տրամադրում է HTTPS մշակում և բարձրացնում կապը:
  • Net::HTTPS-ը իր SSL backend-ով տրամադրում է TLS-ունակ սոկետ, սովորաբար IO::Socket::SSL ժամանակակից կարգավորումներում:

Տեղադրված SSL backend-ը ինքնուրույն վարդակ չի ընտրում: Պահպանեք բնօրինակ HTTPS հոսթի անունը URL-ում. CONNECT-ի ընդունումը չի ստուգում այդ կայքի վկայագիրը:

Հին բաղադրիչները սպասարկելիս տարբերեք այս սահմանները: libwww-perl 6.06-ը և առանձին տարածվող LWP::Protocol::https 6.06-ը ներկայացրին համաձայնեցված ուղղումներ սովորական HTTP CONNECT-ի համար: Միայն UserAgent տարբերակը չի նույնականացնում HTTPS մոդուլը: LWP::Protocol::https 6.15-ը ավելացրեց ուղղում TLS-ով վարդակային վերջնակետերի համար, որոնց https:// սխեման TLS է ավելացնում վարդակին նախքան նպատակակետի TLS-ը:

Ավելի հին Net::SSL/Crypt::SSLeay կարգավորումները կարող են փոխարենը օգտագործել այդ backend-ի փաստաթղթավորված HTTPS_PROXY միջավայրի մեխանիզմը: Մի կիրառեք դրա բաղադրատոմսը ժամանակակից IO::Socket::SSL ուղու վրա, որտեղ LWP-ն է տնօրինում երթուղավորումը:

Առաջին ձախողված փուլով ընտրեք բաղադրիչը. բացակայող HTTPS մշակիչը վերաբերում է արձանագրության մոդուլին. մերժված CONNECT-ը վերաբերում է երթուղուն, հավատարմագրերին կամ քաղաքականությանը. թունելից հետո վկայագրի սխալը վերաբերում է նպատակակետի ինքնությանը և վստահությանը: Պահպանեք ստուգումը, մինչ փոխում եք այն բաղադրիչը, որին այդ ապացույցն է աջակցում:

Առնչվող հոդվածներ