QGIS folosește proxy-ul, dar un plugin bazat pe Requests nu

Un strat de hartă se încarcă prin proxy-ul biroului, în timp ce apelul API al unui plugin eșuează. Ambele acțiuni rulează în QGIS, dar pot folosi clienți HTTP diferiți.

QGIS expune QgsNetworkAccessManager pentru operațiile de rețea. Acesta transmite configurația de rețea a QGIS în cererile făcute prin acel manager. Un plugin Python care importă Requests creează un alt client, cu propriul comportament de proxy și autentificare.

Alegeți configurația pe care doriți să o partajați

Pentru un plugin menit să urmeze preferințele de rețea QGIS ale utilizatorului, folosirea managerului de rețea QGIS evită reconstruirea independentă a acelor preferințe. Verificați API-ul potrivit versiunii QGIS pe care o acceptați, inclusiv comportamentul său asincron și integrarea autentificării.

Dacă Requests este necesar dintr-un alt motiv, configurați-l în mod deliberat. Dicționarul său de proxy și tratarea variabilelor de mediu urmează documentația Requests. Un proxy selectat în setările QGIS nu devine automat o setare de sesiune Requests.

Fiți precis cu privire la domeniu când încercați exemple Qt de pe un forum. Setarea unui proxy pentru aplicația Qt afectează rețeaua Qt. Nu demonstrează că Requests, care folosește o altă implementare de rețea, și-a schimbat ruta.

Comparați aceeași destinație

Folosiți URL-ul pluginului care eșuează când comparați comportamentul. Un serviciu de hărți și un API fără legătură pot avea reguli de ocolire, permisiuni de proxy sau lanțuri de certificate diferite. O cerere de hartă reușită demonstrează doar că ruta proprie funcționează.

Înregistrați numele clientului HTTP, gazda de destinație, dacă s-a solicitat autentificare prin proxy și etapa reală a erorii. Excludeți parolele din jurnalele pluginului. Acea comparație mică vă spune de obicei dacă trebuie să reparați integrarea de rețea QGIS sau clientul Python independent, fără a reseta preferințele de proxy care funcționează deja pentru utilizator.