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 <[email protected]> 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 < > [email protected]> 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%" >> ENDEND >> >> ``` >> >> 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 >> ``` >> >> which in our case would be >> >> ``` >> PROXY-URL https://example.com/cgi-bin/{map} >> ``` >> >> Thank you, Paul. >> _______________________________________________ >> MapServer-users mailing list >> [email protected] >> https://lists.osgeo.org/mailman/listinfo/mapserver-users >> >
_______________________________________________ MapServer-users mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/mapserver-users
