[mapserver-users] dynamic ows_serviceurl

[Steve Lime]

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 <sdlime at 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 at 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%"    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
>> MapServer-users at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/mapserver-users
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20220412/307c6a86/attachment.htm>