mapserver 5 expression

[Steve Lime]

You are correct. Even if we re-enabled that functionality applications
will
break because of the syntax change in how URL configuration is handled.
The migration guide talks about these changes.

I agree that EXPRESSIONs are not as likely to suffer from security
problems
although I don't like the idea of allowing it since there is no way to
validate
an expression without evaluating it. No security problems with that
functionality
have been reported. I still prefer using the runtime subs where you can
apply
your own checks. You can substitute entire expressions that way too.

Cc'ing mapserver-dev

Steve

>>> Jan Hartmann <j.l.h.hartmann at uva.nl> 08/31/07 7:31 AM >>>
Am I right that expressions could be changed by URLS in version 4 and 
cannot be changed any more in version 5? In that case I would strongly 
propose to reintroduce that possibility. It would break many of my 
applications, and I would need to use MapScript for those. Generally I 
only use CGI, because not all webservers I have to write for support 
MapScript. It's really a big restriction on MapServer CGI

If there are security problems, I would like to see examples of those. 
Perhaps  more specific solution can be found then. Anayway, the DATA 
statement is protected by the DATAPATTERN statement in the mapfile, so 
if someone sets that open, he takes a risk anayway. Prohibiting changes 
to expressions in that situation is overkill IMO.

Jan

Steve Lime wrote:
> Expressions are not changable via URL configuration, at least not in
> their entirety like
> you are doing. I took a conservative approach to exposing parameters
to
> URL when
> that support was re-written for 5.0. I was concerned that unchecked
> manipulation of
> expressions and filters *could* be a security problem, so that is
> unavailable.
> 
> What do folks think?
> 
> Note that it is easy to re-enable. Just change line 162 in maplexer.l:
> 
> from <INITIAL>expression ...
> to <INITIAL,URL_STRING>expression ...
> 
> You can also work around this using runtime substitution. Presumably
> you'd write the mapfile
> entry like so:
> 
>   LAYER
>     NAME 'fastvisa'
>     ...
>     CLASS
>         EXPRESSION ([FNR]=%myid%)
>     END
>   END
> 
> and would have a URL like ...&myid=210176493&...
> 
> The advantage here is the you make the decision to enable that level
of
> configuration, plus you
> can apply a regex filter to the value passed in from the URL and if
the
> value doesn't match that
> pattern then no substitution is made:
> 
>   LAYER
>     NAME 'fastvisa'
>     ...
>     METADATA
>        myid_validation_pattern   '^\d{9}$'
>     END
>     CLASS
>         EXPRESSION ([FNR]=%myid%)
>     END
>   END
> 
> In this example the input value for myid must consist of exactly 9
> digits.
> 
> Steve
> 
>>>> On 8/29/2007 at 7:28 AM, in message
> <BAY116-F20CE60F662031E0BD05A8182CC0 at phx.gbl>, Lars-Göran Edholm
> <lged_morris at HOTMAIL.COM> wrote:
>> Hi again!
>> Tried with
>> &map.layer[fastvisa].class[0]=EXPRESSION+([FNR]=210176493)
>> gives the error:
>> loadClass(): Unknown identifier. Parsing error near
> (EXPRESSION):(line 1)
>> with
>> &map.layer[fastvisa].class[0].EXPRESSION=([FNR]=210176493)
>> i get
>> loadClass(): Unknown identifier. Parsing error near (():(line 1)
>>
>> Seems that there is something with Expression that is wrong.
>> Lars-Göran Edholm
>>
>> _________________________________________________________________
>> Upptäck kärleken på MSN 
>> http://match.se.msn.com/channel/index.aspx?trackingid=1002962
>