[mapserver-users] New limitations with mapserver 5 CGI

[Graeme Watmuff]

Hi Steve,

Comment in line.

Graeme
On Mon, 2008-07-14 at 23:10 -0500, Steve Lime wrote:
> Well, we're getting feedback from the current framework now I guess. You should be able
> to set METADATA, just not keys of a certain format. 

I presume you mean the layer's metadata object because the map web
metadata obj is not changeable via URL (unless you plan to alter that)

> By wildcard I'm assuming you mean
> on the pattern side so to allow any FILTER you'd do:
> 
>   filter_validation_pattern '.'
> 
> Or something like that.

Correct

> 
> One problem with the current proposal is how to handle nested objects, especially 
> class expressions since classes don't have metadata. This will have to take the form of an
> RFC I guess.

Haven't found the need to alter CLASS EXPRESSION on the fly yet if
that's what you mean and we have been using mapserver a number of years
now. I gather from your comment this property of the class object is
also not over-rideable via URL in mapserver 5. 

> 
> Steve
> 
> >>> Graeme Watmuff <gwatmuff at geographicweb.com.au> 07/14/08 10:22 PM >>>
> Hi Steve,
> 
> That sounds okay. We don't have to be able to set the MAP METADATA
> object's properties on the fly - it was just a convenience thing.
> 
> Changing the LAYER object's FILTER and TILEINDEX properties are crucial
> though. I presume a valid '_validation_pattern' pattern would allow a
> wildcard (*) in case we need that degree of flexibility.
> 
> Its hard to predict what other presently disallowed LAYER properties may
> be important to change via URL, but I guess if the new framework you
> propose is in place, users can let you know if the boat needs a bit more
> cargo!
> 
> Thanks for this and the tremendous job you and the mapserver team are
> doing.
> 
> Regards
> 
> Graeme
>  
>  Mon, 2008-07-14 at 10:05 -0500, Steve Lime wrote:
> > Graeme: Did you look at my last reply in the thread? I outlined a possible
> > solution that I would be willing to implement for 5.2.1/5.4 if ok with the
> > PSC. Does that seem workable for you?
> > 
> > Steve
> > 
> > >>> On 7/10/2008 at 7:22 PM, in message
> > <1215735745.2481.71.camel at bongolx.ringo.net>, Graeme Watmuff
> > <gwatmuff at geographicweb.com.au> wrote:
> > > Hi Steve,
> > > 
> > > Thanks for replying and thanks for the coding pointers. You are right
> > > about the mapserv 4.10 tileindex syntax. Like filter, it is simply
> > > ignored by v5 rather than throwing an error. My apologies.
> > > 
> > > Would it make sense to create a 'secure' version for the paranoid and a
> > > another version with full functionality? I realize this would create
> > > more maintenance work for you, but not all mapserver users are going to
> > > be able to climb inside the code themselves to modify functionality
> > > (fortunately we can).
> > > 
> > > Regarding security, I presume you are concerned about mapserver exposing
> > > sensitive data to unintended users. If so, should you be taking that
> > > responsibility on yourself by limiting mapserver or should the onus be
> > > upon mapserver users to manage their own data more responsibly? I am a
> > > great believer in personal responsibility. If the security risk is made
> > > clear to users, they can make their own decisions as to the data they
> > > potentially expose to the world.
> > > 
> > > We have greatly appreciated and benefited from the tremendous work you
> > > and your associates have done in bringing mapserver to the world and we
> > > have always looked forward to the added features of each new version.
> > > But upgrading now comes at some degree of inconvenience for us and maybe
> > > others unless someone wants to publish the workaround to resurrect lost
> > > functionality for all to simply acquire.
> > > 
> > > I am not convinced that limiting the previous functionality is the right
> > > direction for mapserver unless you fear say a litigious threat from
> > > security breaches that people may bring upon themselves (hardly your
> > > responsibility). Those with seriously sensitive data are not going to
> > > want expose the CGI to all the world via a browser-sent URL anyway. I
> > > would expect them to send URLs from say, a java web app embedded in a
> > > secured tomcat container.
> > >  
> > > Just my thoughts.
> > > 
> > > Regards and best wishes
> > > 
> > > Graeme
> > > 
> > > On Thu, 2008-07-10 at 17:13 -0500, 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+<datasou
> > > rce>
> > >> 
> > >> > 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
> > >> 
-- 
Graeme Watmuff
Geographic Web Solutions Pty Ltd
17 Tay Road
Woodforde
South Australia  5072
ph:  + 61 8 83364463