requests-oauthlib: задайце проксі OAuth2Session да выкліку fetch_token
Выкарыстоўвайце адзін і той жа сеанс з улікам проксі для атрымання токена і абароненых рэсурсаў, захоўваючы існуючы паток OAuth.
from requests_oauthlib import OAuth2Session
session = OAuth2Session(client_id=client_id, redirect_uri=redirect_uri)
session.proxies.update({
'http': 'http://proxy.example:8080',
'https': 'http://proxy.example:8080',
})OAuth2Session пашырае Session з Requests. Стварыце яго з існуючай рэгістрацыяй кліента праграмы, redirect URI, state і scopes, затым задайце маршрут да абмену токена. Для публічнага HTTP-маршруту кандыдат са спісу HTTP-проксі дае адрас у карце проксі гэтага сеансу.
Выклікайце fetch_token і аперацыі з абароненымі рэсурсамі ў гэтым сеансе. Аргумент proxies, перададзены толькі ў fetch_token, дзейнічае для гэтага абмену; ён не ўстанаўлівае пастаянны маршрут для наступных выклікаў.
Наведванне старонкі аўтарызацыі ў браўзеры выкарыстоўвае маршрут браўзера. Python робіць запыт токена асобна, таму поспех у браўзеры не наладжвае гэты сеанс.
Інтэграцыя Requests з асяроддзем можа ўплываць на выбар проксі сеансу. Для строгага маршруту, якім кіруе праграма, праглядзіце trust_env; адключэнне таксама патрабуе яўна падаць патрэбныя налады CA або аўтэнтыфікацыі.
Памылка OAuth, вернутая endpoint-ам токена, можа прыйсці праз працоўны проксі. Захоўвайце гэты адказ асобна ад аўтэнтыфікацыі проксі, бо яе ўліковыя даныя адрозніваюцца ад client secret і access token.