Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Preventing DOS situation with WMS-T service specifying effective huge TIME range #4524
I'm running the WMS-T service shown as the example in the MS documentation here :)
The problem is that when a user specifies a CGI variable of 'TIME=2011', the database query ends up returning every raster for the year 2011 (a raster every 5 minutes). This causes mapserver to do a lot of work and eventually DOSs the server...
The documentation notes that setting the metadata wms_timeformat should help limit the potential timestamp queries coming to the server, but this feature may not be implemented for PostGIS backed WMS-T queries?
tbonfort kindly helped me with this on IRC and asked if I might have a suggestion on how to deal with this. I am not sure if the issue here is if the postgis backend is not supporting the wms_timeformat setting and implementing that would resolve this or if some syntax to the SQL query is needed to limit the number of rows that could be potentially returned. In my mind, the wms_timeformat would be best and I would want to make sure a request has at least the minutes specified in the TIME CGI variable.
I got 6.2.0-rc running and debugged the resulting SQL from just a &TIME=2010
interesting. Still digging :)
I think the problem is that msSetLimitedPattersToUse() is never getting called, because the ms_limited_pattern is not getting set early enough. The only place it gets set is within msSetLimitedPattersToUse() . I think this circular logic is the problem , but my head is spinning at the moment.
Here's a test case.
pushed a commit
Apr 9, 2013
I still believe there is nothing much we can do on the mapserver side, as from what I understand its behavior in this case is correct. The logic of ordering and limiting the number of features from the tileindex is very specific to each scenario, and can't really be hardcoded into mapserver. I suggest you either use MAXFEATURES on your tileindex layer, or use a LIMIT+ORDER BY clause in your sql query.
@tbonfort Thank you for your response. For your suggestions,
Perhaps a PROCESSING or METADATA option could be added to disable this functionality entirely? With 6.4.1, I simply made this change
I see the code has changed for 7.0.0, so will try to manually hack it out of the code again.
EDIT: I got MAXFEATURES to work, thanks.