[mapserver-dev] Version 8.0, more opt in and less opt out...

Wed Oct 13 16:53:51 PDT 2021

I see what you mean, I just think that gets really complicated and you have
to look at a bunch of different contexts to see what's allowed and you're
still adding an object, and a more complex one. At least for me, I've
tended to use this feature sparingly, for specialized use cases. Others may
have different experiences.

Note that allowing multiple keywords takes the form of something like (for
a scalebar):

  URLUPDATE "size|units" # two keywords
  URLUPDATE "." # all (supported) keywords

The string is interpreted as a case-insensitive regex. If you have a bunch
of styles and only want to tweak one dynamically then this allows that
because the expression lives with the object definition - no need to look
elsewhere.

I'd actually want to pull *all* properties that support runtime
substitution out of this setup so in the end you end up with relatively few
mutable parameters. I mean, it's much easier to use/validate smaller
substitution patterns for something like a connection or expression than
replacing the whole thing. When Thomas added default values for runsub it
really limited the need for this stuff. Still, runsub isn't useful for
everything.

--Steve

On Wed, Oct 13, 2021 at 3:24 PM Seth G <sethg at geographika.co.uk> wrote:

> Hi Steve,
>
> The functionality seems good, however I'm not convinced of the Mapfile
> syntax to support this.
> A few downsides are that It doesn't easily allow global settings, it would
> add a new keyword to all objects. Also I'm not clear on how to allow
> modification of multiple keywords within a block.
>
> A possibile syntax alternative (with no regard to ease of implementation!)
> is to use a combination of the VALIDATION...END block approach and the
> syntax used for enabling services for OWS requests, similar to
> https://mapserver.org/ogc/wms_server.html#web-object-metadata e.g.
> "wms_enable_request" "* !GetFeatureInfo"
> The block could be named MUTABLE and placed at any level.
>
> For example as a top-level object - this could be set in a MAP..END *or*
> in a global CONFIG..END
>
> MUTABLE
> "layer" "data" # all layer's DATA keywords would be mutable
> "scalebar" "* !unitsize" # everything in the scalebar would be mutable
> *except* for unitsize
> END
>
> Then for fine-grained control the same block could be placed in child
> objects, for example:
>
> LAYER
> ...
> MUTABLE
>   "layer" "filter data" # this layer's filter and data keywords would be
> mutable, but not the DATA clause
>   "class" "* !text" # all CLASS keywords are mutable except for TEXT
> END
>   CLASS
>     MUTABLE
>       "class" "text" # however the TEXT for this class would be mutable
>     END
>   END
> END
>
> It would make it easier to validate if the properties are supported by
> run-time substitution and are in the list at
> https://mapserver.org/cgi/runsub.html#parameters-supported
> Drawbacks of this syntax- I don't really like having the object name as
> the key *within" a block e.g. having to set "layer" in a MUTABLE block
> within a LAYER object, but I can't think of a nicer approach at the moment.
> Also having the object in quotes seems..wrong - MUTABLE LAYER "*" END
> seems more appropriate.
>
> Just some initial thoughts so feel free to consider and discard!
>
>
> Seth
>
>
>
> --
> web:http://geographika.co.uk
> twitter: @geographika
>
>
> On Wed, Oct 13, 2021, at 5:29 PM, Steve Lime wrote:
>
> I have a branch started that adds this functionality (currently for just a
> scalebar) at https://github.com/sdlime/mapserver/tree/urlupdate. It's
> essentially what I mentioned back in June (time flies). It adds a new
> attribute called URLUPDATE (more descriptive) that would specify properties
> that can be updated. The default would be nothing so users would explicitly
> have to choose what is allowed (from an already limited subset).
>
> SCALEBAR
>   ...
>   URLUPDATE "UNITS|SIZE"
> END
>
> We would apply the same approach to all relevant objects. So by default no
> updates would be allowed. I can create a WIP pull request later today...
>
> --Steve
>
>
>
> On Mon, Jun 14, 2021 at 9:46 AM Steve Lime <sdlime at gmail.com> wrote:
>
> Thinking about this, I'd guess I'd propose adding a mutable parameter to
> structures that support runtime updates. It wouldn't be a boolean but
> rather a string. Default would be NULL so everything is immutable by
> default. If a value is present the value would be interpreted as a
> case-insensitive regex against the allowed attributes. So, for example you
> could have:
>
> SCALEBAR
>   ...
>   MUTABLE "UNITS"
> END
>
> So, in this case the units of scalebar could be changed via the syntax
> given in RFC 44 but nothing else.
>
> --Steve
>
> On Tue, May 18, 2021 at 8:51 AM Steve Lime <sdlime at gmail.com> wrote:
>
> Thanks for the explanation Dan! FWIW I can work up a pull request to
> illustrate what I was thinking by adding a mutable parameter... I think
> that can be a simple, easy to understand and explicit approach. --Steve
>
> On Tue, May 18, 2021 at 8:47 AM Daniel Morissette <
> dmorissette at mapgears.com> wrote:
>
> FYI mode=OWS was added to deal with OGC compliance testing which
> requires the server to produce an exception in some cases if the
> SERVICE/REQUEST parameters are missing... and since MapServer falls back
> on the CGI mode by default if SERVICE/REQUESTS are not present then the
> only way we could imagine to produce that exception and be compliant was
> to add a mode=OWS vendor-specific param in the onlineresource.  More
> info here:
>
> https://github.com/MapServer/MapServer/issues/2512
>
> and
>
> https://github.com/MapServer/MapServer/issues/2531
>
>
> P.S. I'm following this thread and think it may be a good idea to have
> "more opt in and less opt out" for security reasons as long as the
> mechanism to handle this is clear and easy to understand, but I don't
> have a strong opinion on the proposed changes, that's why I'm staying
> quiet.
>
> --
> Daniel Morissette
> Mapgears Inc
> T: +1 418-696-5056 #201
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
> _______________________________________________
> MapServer-dev mailing list
> MapServer-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20211013/9ecf13f2/attachment-0001.html>