Open kannes opened 1 year ago
duplicate of #14949
Hm, are you sure? That one seems to have been about layer sources in general, I had no issues there and my test setup did successfully fail to access WFS layers if a broken proxy was set.
This one is about calls to the executable binaries, e.g. ogr2ogr
, by the processing tools.
edit: Maybe my terminology is wrong, with "provider" I meant "provider of processing tools" :)
Just hit this issue, it's not possible to add a COG layer (which uses GDAL) behind proxy:
2024-02-06T11:07:12 INFO Remote layer : loading /vsicurl/https://sentinel-cogs.s3.us-west-2.amazonaws.com/sentinel-s2-l2a-cogs/36/Q/WD/2020/7/S2A_36QWD_20200701_0_L2A/TCI.tif, please wait …
2024-02-06T11:13:03 CRITICAL Unsupported Data Source : /vsicurl/https://sentinel-cogs.s3.us-west-2.amazonaws.com/sentinel-s2-l2a-cogs/36/Q/WD/2020/7/S2A_36QWD_20200701_0_L2A/TCI.tif is not a supported raster data source
HTTP response code on https://sentinel-cogs.s3.us-west-2.amazonaws.com/sentinel-s2-l2a-cogs/36/Q/WD/2020/7/S2A_36QWD_20200701_0_L2A/TCI.tif: 0
This was reported before in https://github.com/qgis/QGIS/issues/42870 (which is closed but not fixed).
I think also related to https://github.com/qgis/QGIS/issues/53351, from @rouault's comment in https://github.com/qgis/QGIS/issues/53351#issuecomment-1593655413:
Those requests are issued by GDAL itself, using curl. To be able to log such requests, it would require changes both in GDAL (similar to the CPLHTTPPushFetchCallback() infrastrcture that was added for the vector side) and QGIS. Not a trivial change
@kannes for the COG issue it's possible to work around with setting the env variable https_proxy
. Likely it solves also your reported issue with processing - but I do agree that this should work out-of-the-box.
What is the bug or the crash?
When a proxy is set in Options -> Network, QGIS and its tools should use this proxy to ensure connectivity, prevent data leakage, etc. The GDAL processing provider is ignoring these settings though, it's calls to native GDAL/OGR tools happen without the configured proxy settings.
I realize that this is probably pretty complicated and hairy (one would need to explicitly pass proxy options to GDAL), but it caught me by surprise when things did not work in a workflow where at some stage
ogr2ogr
was called on a WFS source which was inaccessible because of this. I think that users would expect proxy settings to be honored by core providers.Steps to reproduce the issue
ms:inv80_lgeomorph
fromhttp://maps.zh.ch/wfs/FnsNSWFS
(random result from web search)localhost
and the port to a port where you do not have a proxy running (e.g.34567
probably)gdal:ogrinfo
) for the layerThe tool should not bypass the proxy settings. For the test case, it should not be able to access a remote source.
Versions
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd">
QGIS-Version | 3.28.3-Firenze | QGIS-Codeversion | c12bcb2f76 -- | -- | -- | -- Qt-Version | 5.15.3 Python-Version | 3.10.6 GDAL-Version | 3.4.1 PROJ-Version | 8.2.1 EPSG-Registraturdatenbankversion | v10.041 (2021-12-03) GEOS-Version | 3.10.2-CAPI-1.16.0 SQLite-Version | 3.37.2 PDAL-Version | 2.3.0 PostgreSQL-Client-Version | unknown SpatiaLite-Version | 5.0.1 QWT-Version | 6.1.4 QScintilla2-Version | 2.11.6 BS-Version | Ubuntu 22.04.1 LTS | | | Aktive Python-Erweiterungen Qgis2threejs | 2.7.1 QuickOSM | 2.1.1 processing | 2.12.99 sagaprovider | 2.12.99 grassprovider | 2.12.99 MetaSearch | 0.3.6 db_manager | 0.1.20Supported QGIS version
New profile
Additional context
Sibling issue for the GRASS provider is #51957, I did not test SAGA or other providers.