QGIS använder proxyn, men ett Requests-baserat plugin gör det inte

Ett kartlager läses in via kontorets proxy, medan pluginets API-anrop misslyckas. Båda åtgärderna körs i QGIS, men de kan använda olika HTTP-klienter.

QGIS exponerar QgsNetworkAccessManager för nätverksåtgärder. Den för QGIS nätverkskonfiguration vidare till förfrågningar som görs via den hanteraren. Ett Python-plugin som importerar Requests skapar en annan klient med eget proxy- och autentiseringsbeteende.

Välj den konfiguration du vill dela

För ett plugin som ska följa användarens QGIS-nätverksinställningar undviker QGIS nätverkshanterare att dessa inställningar byggs upp separat. Kontrollera det API som passar den QGIS-version du stöder, inklusive dess asynkrona beteende och autentiseringsintegrering.

Om Requests behövs av en annan anledning, konfigurera det medvetet. Dess proxydictionary och miljöhantering följer Requests-dokumentationen. En proxy som valts i QGIS inställningar blir inte automatiskt en Requests-sessionsinställning.

Var noggrann med omfattningen när du provar Qt-exempel från ett forum. Att ange en proxy för Qt-applikationen påverkar Qt-nätverk. Det visar inte att Requests, som använder en annan nätverksimplementation, har ändrat sin väg.

Jämför samma destination

Använd pluginets misslyckade URL när du jämför beteende. En karttjänst och ett orelaterat API kan ha olika kringgåenderegler, proxybehörigheter eller certifikatkedjor. En lyckad kartförfrågan visar bara att dess egen väg fungerar.

Notera HTTP-klientens namn, målvärden, om proxyautentisering begärdes och det faktiska felsteget. Uteslut lösenord från pluginets loggar. Den lilla jämförelsen brukar visa om du ska åtgärda QGIS nätverksintegrering eller den oberoende Python-klienten, utan att återställa proxyinställningar som redan fungerar för användaren.