Hi Paul, The runtime substitution and setting a querystring on the server is a good approach - have you found any drawbacks to this? Most web servers can set/add querystrings without any need for further software.
As Steve mentioned the alternative would be to generate Mapfiles for specific environments from a template. I use mappyfile for this, with a Python script that can be run as part of continuous deployment: import mappyfile mapfile = mappyfile.open("original.map") # update the web metadata settings mapfile["web"]["metadata"]["ows_onlineresource"] = "https://example.com/cgi-bin/mapserv?map={}.map".format("test") <https://example.com/cgi-bin/mapserv?map={}.map%22.format(%22test%22)> mappyfile.save(mapfile, "new.map") Typical other settings I'd change are connection strings, DEBUG level, and EXTENTs for different Mapfiles. Seth -- web:https://geographika.net twitter: @geographika On Wed, Apr 13, 2022, at 3:52 AM, Steve Lime wrote: > One other thing. One challenge with environment variables is knowing what's > consistently available within a runtime environment - CGI is different from > FastCGI and there are differences across web servers. That's one of the > reasons pre-processing is kind of attractive IMHO. I suppose the v.8 config > file could play a role but I'm unsure what that would be beyond a place to > set values consistently. > > On Tue, Apr 12, 2022 at 8:04 PM Steve Lime <sdl...@gmail.com> wrote: >> Hi Paul: The idea of referencing environment variables has come up before. >> Another example would be to leverage settings injected into cloud >> deployments as environment variables (I think there's an old ticket that was >> recently re-opened on the topic). I'm not sure what the best way to handle >> this would be. One possibility would be using a mechanism similar to runtime >> subs where you'd reference the variables within the mapfile using >> ${variable} or whatever. Another idea would be to use a pre-processor of >> some sort to "compile" a mapfile from the environment. The latter would >> result in better performance since you'd generate the resulting file once >> and could also do things like inlining included snippets. This functionality >> would be helpful for the cloud deployments, simplifying deployments in >> multiple (dev, test, prod) environments and for keeping secrets out of repos >> altogether. >> >> We're putzing around with the pre-processing idea a bit but haven't gotten >> anything fully baked. Others? >> >> -Steve >> >> On Tue, Apr 12, 2022 at 4:56 AM Paul via MapServer-users >> <mapserver-users@lists.osgeo.org> wrote: >>> hi list, this has probably been discussed before, but maybe there are >>> updates (on v8?) >>> >>> we would like to extract the `ows_onlineresource from the environment, >>> instead of having an administrator to configure it on the mapfile` >>> >>> currently we implement a hack where the webserver layer sends an additional >>> query parameter `ows_url` to mapserver which contains the current url >>> >>> in the mapfile this is implemented as >>> >>> ``` >>> WEB >>> VALIDATION >>> "ows_url" >>> "(\b(https?|ftp|file)://)?[-A-Za-z0-9+&@#/%?=~_|!:,.;]+[-A-Za-z0-9+&@#/%=~_|]" >>> END >>> >>> METADATA >>> "ows_onlineresource" "%ows_url%" >>> END >>> END >>> ``` >>> >>> I wonder if others run into similar challenges, or if there are much more >>> simple best practices for this case. >>> >>> I can imagine allowing a environment parameter 'proxy-url' like geoserver >>> would make sense, but it should allow some kind of template, eg: >>> >>> ``` >>> PROXY-URL https://example.com/cgi-bin/mapserv?map={map}.map >>> <https://example.com/cgi-bin/mapserv?map=%7Bmap%7D.map> >>> ``` >>> >>> which in our case would be >>> >>> ``` >>> PROXY-URL https://example.com/cgi-bin/{map} >>> <https://example.com/cgi-bin/%7Bmap%7D> >>> ``` >>> >>> Thank you, Paul. >>> _______________________________________________ >>> MapServer-users mailing list >>> MapServer-users@lists.osgeo.org >>> https://lists.osgeo.org/mailman/listinfo/mapserver-users > _______________________________________________ > MapServer-users mailing list > MapServer-users@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/mapserver-users >
_______________________________________________ MapServer-users mailing list MapServer-users@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/mapserver-users