CZML and KML need the ability to pass query parameters

[mramato]

CzmlDataSource and KmlDataSource have no way to specify additional parameters that need to be included in url requests. The most common use for this is query-based access tokens.

Both classes' load function (and in CZML's case the process function) should take an additional query object, off of the options object. It would be a dictionary of strings that get converted to a query string via objectToQuery and globbed onto all urls requests.

[denverpierce]

I'd add geojson to this as well. A good use case is ArcGIS server, which can serve up conformant Geojson, but the API calls to build the queries are unwieldy in raw string form.

[hpinkos]

Thanks @denverpierce! Good idea

[mramato]

I didn't think GeoJSON would be necessary since there's only one url involved, which the developer specifies. You can use objectToQuery to easily do what you want in that case. In CZML/KML, they retrieve additional resources depending on the content of the file, and that's something we can't currently do.

I'm not against adding it for GeoJSON for completeness, it will be trivial.

[denverpierce]

Now that I understand the use case, I see what you're saying. They are closely related, but geojson doesn't have a burning need for that functionality, it'd just be a quality of life change.

[emackey]

Random question, does the fix here only involve query parameters? Should we support systems that transmit authentication via added headers instead of query parameters?

[ottaviohartman]

This is only for query parameters, yes.

[mramato]

Should we support systems that transmit authentication via added headers instead of query parameters?

Headers are not generally a good solution for authentication that involves browser-retrieved resources. For example, Cesium uses the HTML image element for retrieving markers, image tiles, textures, etc.. but you can't assign headers when setting image.src, your only choice is a query parameter. So even if we added header support, it would not help in 99% of Cesium's use cases.

Of course if we ever had a good reason for adding a headers object, we could; it's just outside the scope of this issue.

[denverpierce]

Isn't there limited support for reusing existing header auth via TrustedServers?

[mramato]

Isn't there limited support for reusing existing header auth via TrustedServers?

Good point in that the Authorization header, cookies, and certs would already be added in the case of the server being in the TrustedServers list, but general header support is impossible because of the reason I listed above. I think TrustedServers is the better mechanism to enable what @emackey originally described (and already works today)

[emackey]

Thanks. Was mostly asking a hypothetical. I think we have an internal project here that normally uses headers, but can optionally use query parameters if I'm not mistaken.

Feel free to close this if you're done with the implementation. Thanks again.

[ottaviohartman]

@emackey KML is in progress and very close to done.