[mapserver-users] New limitations with mapserver 5 CGI

[Steve Lime]

That didn't get put in place, there were implementation issues at the time and I haven't revisited. For example, we use
metadata to store validation patterns you can't very well allow URL modification of metadata then. You can I guess but
at risk. Plus it's not really practical to write patterns that would match large blocks of a mapfile. A single parameter maybe,
like the runtime validation but not a block.

Perhaps the TEMPLATEPATTERN. DATAPATTERN concept could be extend to more general use for those particularly 
vulnerable variables (e.g. FILTER). If you look at mapfile.c you'll see how that comes into play when changing a TEMPLATE
via URL.

Steve

>>> On 7/10/2008 at 6:26 PM, in message <48769A94.6090000 at swoodbridge.com>, Stephen
Woodbridge <woodbri at swoodbridge.com> wrote:
> Steve L,
> 
> There was some discussion about using metadata regex's to validate 
> changes via the URL. Did this not go into play? I thought we were going 
> to do something like:
> 
> 1) default it is restricted or disabled
> 2) if metadata "validate_some_parameter" "some_regex" then allow those 
> changes that validate.
> 
> Then if someone wanted to unrestrict it they could use a regex "/./" to 
> allow anything or set it to whatever.
> 
> -Steve W
> 
> Steve Lime wrote:
>> Hi Graeme: Comments inline... I definitely underestimated the impacts
>> of those changes. Anyway...
>> 
>>>>> On 7/9/2008 at 11:23 PM, in message
>> <1215663787.2513.112.camel at bongolx.ringo.net>, Graeme Watmuff 
>> <gwatmuff at geographicweb.com.au> wrote:
>>> It has become apparent through some frustrating moments of trial
>>> and error that many of the mapfile variables that were changeable
>>> via URL with mapserver 4.10.x CGI seem no longer changeable with
>>> v5.x or 5.2.x. There is a hint from the docs that this is because
>>> of security concerns? Our java apps don't allow web users to
>>> directly interact with the CGI, so security doesn't seem so
>>> important in our case.
>> 
>> Allowing unaltered, direct modification of things like FILTERs or
>> CONNECTIONS is a potential security risk although I've never run
>> across a documented case. Filters are risky because they are passed
>> to the underlying data driver which generally trust the contents.
>> 
>>> Some examples:
>>> 
>>> map_web_metadata='text1' 'text2' map_layerName_filter=<expression> 
>>> map_layerName_tileindex=<tileindex.shp> 
>>> map_layerName_data=<datasource>
>>> 
>>> allow changes to the mapfile via URL with mapserver 4.10.x
>>> 
>>> Following the new syntax specified for v5 + I had expected
>>> 
>>> map_web=metadata+"'text1' 'text2'" or maybe 
>>> map_web_metadata[0]='text1'+'text2', 
>>> map_layer[layerName]=filter+<expression>, 
>>> map_layer[layerName]=tileindex+<tileindex.shp>, 
>>> map_layer[layerName]=data+<datasource>
>>> 
>>> to all perform in the time-honoured way.
>> 
>> And they don't... If they did you could combine modifications to a
>> layer in a single variable:
>> 
>> 
>map_layer[layerName]=filter+<expression>+tileindex+<tileindex.shp>+data+<datasourc
> e>
>> 
>> 
>>> Only 'data' could be changed with this new mapserver 5 syntax. I 
>>> happened to discover through the change logs that changing
>>> tileindex was reinstated for mapserver 5 CGI, but using the old
>>> mapserver 4.10 syntax (map_layerName_tileindex)=<tileindex.shp> -
>>> not the new mapserver 5 syntax style
>>> (map_layer[layerName]=tileindex+<tileindex.shp>).
>> 
>> Looking at the code, TILEINDEX is not changable via a URL with any
>> syntax. The change log references a bug fix to 4.10. The old syntax
>> doesn't work at all.
>> 
>>> mapserv 5 CGI throws an error (Parsing error near (filter)) when
>>> the new syntax is used for filter and ignores the old 4.10 filter
>>> syntax.
>> 
>> This is expected. It will fail with an error as opposed to the silent
>> failure of versions past.
>> 
>>> No URL syntax for changing the web object's metadata content
>>> appears acceptable to the mapserver 5.
>> 
>> Correct.
>> 
>>> I would dearly like to see changing the layer filter via URL
>>> restored also to mapserver 5. And the web object's metadata setting
>>> functionality too.
>> 
>> It's possible to customize this behavior by editing maplexer.l and
>> recompiling the code. Simply find the keyword you're interested in
>> supporting and change the states at which it is valid. So, for
>> TILEINDEX:
>> 
>> <INITIAL>tileindex
>> 
>> becomes:
>> 
>> <INITIAL,URL_STRING>tileindex
>> 
>> Same goes for the other parameters you'd want to activate.
>> 
>>> Can anyone indicate what mapfile properties are or are not going to
>>> be reinstated in mapserver 5 compared to mapserver 4 for change via
>>> URL? Obviously this has development ramifications for us when we
>>> try to upgrade mapserver.
>> 
>> If I (or anyone) can think of a way to make this tunable at runtime
>> I'd love to talk more about it. The set of parameters supported in
>> 5.2 has only changed a little bit since 5.0 based on user input. I
>> can't see exposing more without good reason. FILTER in particular is
>> worrisome and there is a work around with the runtime substitution
>> (e.g. FILTER %someval%). In that example you can pass someval via URL
>> but you have to define a validation pattern (a regex) to check it
>> against.
>> 
>>> Alternatively, am I missing something with new mapserver 5 syntax?
>> 
>> I'm curious if updating maplexer.l to fit your particular needs is
>> workable.
>> 
>>> Graeme Watmuff
>> 
>> Steve
>> 
>> _______________________________________________ mapserver-users
>> mailing list mapserver-users at lists.osgeo.org 
>> http://lists.osgeo.org/mailman/listinfo/mapserver-users 
> 
> _______________________________________________
> mapserver-users mailing list
> mapserver-users at lists.osgeo.org 
> http://lists.osgeo.org/mailman/listinfo/mapserver-users