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

Et kartlag lastes gjennom kontorproxyen, mens et plugins API-kall mislykkes. Begge handlingene kjører inne i QGIS, men de kan bruke ulike 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 å bygge opp disse innstillingene på nytt uavhengig. Sjekk API-et som passer for QGIS-versjonen du støtter, inkludert asynkron 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 pluginen som feiler når du sammenligner atferd. En karttjeneste og et urelatert API kan ha ulike 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.