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

[Seth G]

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/70b56b10/attachment.html>