QGIS bruker proxyen, men en Requests-basert plugin gjør det ikke

Et kartlag lastes gjennom kontorets proxy, mens en plugins API-kall mislykkes. Begge handlingene kjører inne i QGIS, men de kan bruke forskjellige HTTP-klienter.

QGIS eksponerer QgsNetworkAccessManager for nettverksoperasjoner. Den fører QGIS' nettverkskonfigurasjon inn i forespørsler som gjøres gjennom den behandleren. En Python-plugin som importerer Requests lager en annen klient med sin egen proxy- og autentiseringsatferd.

Velg konfigurasjonen du vil dele

For en plugin som skal følge brukerens QGIS-nettverksinnstillinger, unngår bruk av QGIS' nettverksbehandler å gjenoppbygge disse innstillingene uavhengig. Sjekk API-et som passer for QGIS-versjonen du støtter, inkludert dets asynkrone atferd og autentiseringsintegrasjon.

Hvis Requests trengs av en annen grunn, konfigurer det bevisst. Proxy-ordboken og håndteringen av miljøvariabler følger Requests-dokumentasjonen. En proxy valgt i QGIS' innstillinger er ikke automatisk en Requests-sesjonsinnstilling.

Vær presis om omfanget når du prøver Qt-eksempler fra et forum. Å sette en Qt-applikasjonsproxy påvirker Qt-nettverket. Det beviser ikke at Requests, som bruker en annen nettverksimplementasjon, har endret ruten sin.

Sammenlign samme destinasjon

Bruk URL-en til plugin-en som feiler når du sammenligner atferd. En karttjeneste og et urelatert API kan ha forskjellige omgåelsesregler, proxy-tillatelser eller sertifikatkjeder. En vellykket kartforespørsel beviser bare at dens egen rute fungerer.

Registrer HTTP-klientens navn, destinasjonsverten, om proxy-autentisering ble forespurt, og den faktiske feilfasen. Utelat passord fra plugin-logger. Den lille sammenligningen forteller deg vanligvis om du skal fikse QGIS-nettverksintegrasjonen eller den uavhengige Python-klienten, uten å tilbakestille proxy-innstillinger som allerede fungerer for brukeren.