QGIS brukar proxyen, men ein Requests-basert plugin gjer det ikkje

Eit kartlag blir lasta gjennom kontorproxyen, medan API-kallet til ein plugin feilar. Begge handlingane køyrer inne i QGIS, men dei kan bruke ulike HTTP-klientar.

QGIS eksponerer QgsNetworkAccessManager for nettverksoperasjonar. Han fører nettverkskonfigurasjonen til QGIS inn i førespurnader som blir gjorde gjennom den handsamaren. Ein Python-plugin som importerer Requests lagar ein annan klient med si eiga proxy- og autentiseringsåtferd.

Vel konfigurasjonen du vil dele

For ein plugin som skal følgje QGIS-nettverksinnstillingane til brukaren, unngår bruk av nettverkshandsamen i QGIS å byggje opp att desse innstillingane uavhengig. Sjekk API-et som passar for QGIS-versjonen du støttar, inkludert den asynkrone åtferda og autentiseringsintegrasjonen.

Viss Requests trengst av ein annan grunn, konfigurer det medvite. Proxy-ordboka og handteringa av miljøvariablar følgjer Requests-dokumentasjonen. Ein proxy vald i innstillingane i QGIS er ikkje automatisk ei Requests-sesjonsinnstilling.

Ver presis om omfanget når du prøver Qt-døme frå eit forum. Å setje ein proxy for ein Qt-applikasjon påverkar Qt-nettverket. Det beviser ikkje at Requests, som brukar ein annan nettverksimplementasjon, har endra ruta si.

Samanlikn same mål

Bruk URL-en til pluginen som feilar når du samanliknar åtferd. Ein kartteneste og eit urelatert API kan ha ulike omgåingsreglar, proxy-tillatingar eller sertifikatkjeder. Ein vellukka kartførespurnad beviser berre at den eiga ruta fungerer.

Registrer namnet på HTTP-klienten, målverten, om proxy-autentisering vart føresport, og den faktiske feilfasen. Utelat passord frå plugin-loggar. Den vesle samanlikninga fortel deg vanlegvis om du skal reparere QGIS-nettverksintegrasjonen eller den uavhengige Python-klienten, utan å nullstille proxy-innstillingar som allereie fungerer for brukaren.