Hello, We're helping the national land survey of Sweden to improve how their data can be consumed in QGIS. One of the items we're looking at is adding support for OAuth2 authentication to the pointcloud processing algorithms when working with COPC files (as they provide their national laser scanning results over STAC/COPC, however behind OAuth2 authentication).
As I see it, there are a few alternatives for this, and I wanted to get some input before going further: 1. Add support for passing headers through pdal_wrench to PDAL, do the OAuth dance in QGIS and just pass the final header to pdal_wrench Relatively simple and likely the quickest solution, however it depends on the access token from QGIS being valid during the entire process which might or might not hold true and would be quite frustrating for end-users if it doesn't. 2. By-pass pdal_wrench and add instead integrate the code now in pdal_wrench directly into the QGIS algorithm, then pass the headers as in 1. Would be somewhat cleaner overall and could open up for other tighter integrations, but we'd have duplicated functionality with pdal_wrench, as well as the issue with token lifetime as in 1. It would also mean pretty much completely rewriting the current processing algorithms in QGIS. 3. As 2., but also add the ability to pass a callback function to PDAL which could be used to update the headers with a new token if needed Feels like the most "proper" solution, however based on reading the PDAL code it feels like it assumes that inputs to readers are always scalars and thus no functions, so it might require a deeper change in PDAL. One could even go as far as making it possible to override the HTTP client used by PDAL, in which case we would get a full integration of proxy settings, requests showing in the debug panel, etc. No idea if PDAL would accept such a change though, and on which time frame. 4. Add OAuth2 functionality directly to PDAL, so that it can get and refresh tokens by itself Would be a relatively large bit of code in PDAL for what might be a relatively uncommon use-case. And though in our case it'd suffice with just the Client Credentials flow (which is very simple to implement) that'd open the door for others to request more complicated flows in PDAL. 5. When running a processing algorithm on an authenticated COPC, start a HTTP server in QGIS that proxies the requests while adding authentication and pass the URL to that server to PDAL This would contain the entire solution to QGIS. It is dependent on being able to open a port, but that should be possible on pretty much all systems. A similar solution is already used for some OAuth2 flows (external/o2/src/o2replyserver.cpp). It does feel a little like a work-around, but maybe that's just me? Has, uniquely amongst these solutions, the upside that the same functionality could be used for any processing algorithm that has the same need, not just those using PDAL. ---------- Though I initially discarded it for feeling like a work-around, I'm currently leaning towards 5. as it would be the most straight-forward solution and not require changes in a third-party dependency. 3. is tempting, but it risks getting bogged down in getting a somewhat fundamental change through PDAL. >From a QGIS-perspective, which solutions would be preferred (read: have the >highest likelihood to be accepted as a PR)? Or is there another approach I've >missed which should be considered? Regards, Jan Dalheimer Sweco Sverige AB | Gävle
_______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
