[MapServer-dev] Handling additional parameters in OGC Features API URLs

[Seth G]

Hi devs,

We've been discussing at the OSGeo codesprint how to handle extra parameters when working with the OGC Features API. The issue is that additional parameters, such as a security token, are not persisted to the URLs constructed by MapServer. For example, a user might request:

https://demo.mapserver.org/cgi-bin/mapserv/localdemo/ogcapi/collections/?f=json&token=98127319283

However, MapServer will return a JSON response with URLs like:

"links": [
    {"href": "https://demo.mapserver.org/cgi-bin/mapserv/localdemo/ogcapi/collections/ocean?f=json"}
]

Client applications can append extra parameters with every request, but this is not always possible, for example when using ArcGIS Pro or QGIS.

MapServer already supports adding parameters for WxS services using Runtime Substitution, since all WEB METADATA values can accept parameters. For example, the ows_onlineresource returned in a GetCapabilities response can include URLs with tokens:

"ows_onlineresource" "http://my.host.com/cgi-bin/mapserv?map=/path/to/your-mapfile.map&%TOKEN%"

OGC Features URLs, however, are constructed in code by building paths and then appending querystring parameters, so runtime substitution cannot be used here. While HTML templates can be modified to include additional parameters, this does not affect URLs returned in f=json responses and updating all templates is time-consuming:

{"href", api_root + "/collections/" + std::string(id_encoded) + "?f=json"}

A proposed solution is to add a new METADATA item to allow extra parameters to be appended to these URLs:

"ows_extraparams" "token=%TOKEN%&userid=%USER_ID%"

- This would use the same Runtime Substitution approach as other METADATA items.
- Mapfile authors would be responsible for adding VALIDATION blocks for the parameters.
- All URL construction in mapogcapi.cpp would be updated to append extra_parameters to the end of URLs, handling edge cases such as ending ampersands or empty strings:
{"href", api_root + "/collections/" + std::string(id_encoded) + "?f=json" + extra_parameters}

As with other METADATA items, LAYER-level metadata would take precedence over WEB-level metadata. This would allow collection-level parameters to be supported when required.

Thoughts / comments welcome,

Seth

--
web:https://geographika.net & https://mapserverstudio.net
mastodon: @geographika at mastodon.social