Authlib-proksejaj agordoj: Requests kontraŭ HTTPX

Kontrolu la importon de Authlib antaŭ ol elekti proksejan argumenton. Ĝiaj integriĝoj Requests kaj HTTPX montras malsaman transportan agordon.

La Requests OAuth2Session heredas la konduton de Session en Requests:

from authlib.integrations.requests_client import OAuth2Session

client = OAuth2Session(client_id=client_id)
client.proxies.update({
    "http": "http://proxy.example.net:8080",
    "https": "http://proxy.example.net:8080",
})

La responda nesinkrona HTTPX-integriĝo prenas la proksejan argumenton je klienta nivelo dum konstruado:

from authlib.integrations.httpx_client import AsyncOAuth2Client

client = AsyncOAuth2Client(
    client_id=client_id,
    proxy="http://proxy.example.net:8080",
)

La HTTPX-ekzemplo uzas la ununuran proksejan opcion subtenatan de Authlib 1.9.1. Tiu integriĝo transdonas rekonitajn transportajn opciojn al sia suba HTTP-kliento. Vortaro proxies laŭ stilo de Requests ne estas interŝanĝebla konstrua argumento. Por publikaj tokenaj kaj APIaj finpunktoj sur permesita publika prokseja vojo, la listo de HTTP-proksejoj provizas kandidatojn por la HTTP-proksejaj URLoj de ambaŭ ekzemploj.

Konservu la ekzistantan OAuth-registradon de la aplikaĵo, la redirect-URI, la scopes kaj la tokenan traktadon kiam vi aplikas iun ajn agordon. Uzu la agorditan klienton por la tokenaj kaj protektitaj-rimedaj operacioj, kaj fermu ĝin per sia kutima sinkrona aŭ nesinkrona vivociklo.

Kadraj helpiloj povas krei tiujn klientojn nome de la aplikaĵo. Esploru la integriĝon de la helpilo kaj la klient-konstruajn opciojn antaŭ ol transdoni argumentojn je petotempo. Ŝlosilvorto proxies akceptata de Requests-tokena peto ne pruvas, ke nesinkrona HTTPX-peto akceptas ĝin.