Python urllib: спалучыць маршрутызацыю праз проксі з Basic-аўтэнтыфікацыяй сайта

Спалучайце маршрутызацыю urllib і Basic-аўтэнтыфікацыю пункта прызначэння ў адным яўным opener, не замяняючы глабальны opener двойчы.

Выклік install_opener() двойчы не дадае другі opener да першага. Ён замяняе стандартны opener модуля. Калі адзін аб'ект ведае проксі, а другі — лагін сайта, пабудуйце адзіны opener з патрэбнымі handlers.

import os
from urllib.request import (ProxyHandler, HTTPBasicAuthHandler,
                            HTTPPasswordMgrWithDefaultRealm, build_opener)

passwords = HTTPPasswordMgrWithDefaultRealm()
passwords.add_password(None, 'https://example.com/private/',
                       os.environ['SITE_USER'], os.environ['SITE_PASSWORD'])
opener = build_opener(
    ProxyHandler({'https': 'http://203.0.113.10:8080'}),
    HTTPBasicAuthHandler(passwords),
)
with opener.open('https://example.com/private/report', timeout=10) as response:
    body = response.read()

Проксі і пункт прызначэння — прыклады. Для публічнай службы, да якой можна дабрацца праз публічны HTTP-проксі, спіс HTTP-проксі дае кандыдатаў у endpoints для handler маршрутызацыі. Гэты opener накіроўвае HTTPS-запыт праз HTTP-проксі і апрацоўвае Basic-выклік прызначэння. Ён не наладжвае аўтэнтыфікацыю проксі.

Калі проксі таксама патрабуе лагін, выберыце падтрыманую схему аўтэнтыфікацыі проксі асобна. 407 пры CONNECT узнікае раней, чым прызначэнне можа выставіць уласны выклік. Даданне ўліковых даных сайта ў менеджар пароляў не задаволіць той ранейшы абмен.

Прамы выклік opener.open() захоўвае канфігурацыю разам з аперацыяй. Няма патрэбы змяняць стандарт на ўзроўні модуля, калі толькі праграма свядома не хоча, каб усе зручныя выклікі выкарыстоўвалі гэты opener.

Падобныя артыкулы