<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Vaclav,<div><br></div><div>Is my understanding that the grass parsing code has to be “less restrictive” for the desktop app<div>while the sanitizer has to be implemented on the web-ui side.</div><div><div><br></div><div>Develop the sanitizer on the web-ui code and do not touch the g.parser source code.</div><div><br></div><div>The sanitizer code will following the guidelines found at the page [thanks] you pointed : </div><div>“Complete Structure Members Table” </div><div><br></div><div>but extending the restrictions to what Glynn suggested :</div><div>size constraint, alphanumeric characters, maximum number of items in a list and more.</div><div><br></div><div>this restriction will be true for the web-ui but not for the desktop gui </div><div>hence the need to leave untouched the grass command line parser code.</div><div><br></div><div>does this make sense for you ?</div><div><br></div><div>Massimo.</div><div><br><div><div>On Mar 10, 2014, at 10:32 PM, Vaclav Petras <<a href="mailto:wenzeslaus@gmail.com">wenzeslaus@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 10, 2014 at 10:19 PM, epi <span dir="ltr"><<a href="mailto:massimodisasha@gmail.com" target="_blank">massimodisasha@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Glynn,<br>
<br>
I understood the risk and I agree in toto with you.<br>
For the web-ui interface we can define the rules for each kind of entry<br>
and publish the rules/restriction on a help page .<br>
Then when an invalid input exception is raised the ui will point the user to read the rules page.<br>
<br></blockquote><div>This is what GRASS parser system [1] is trying to define, so you should/need to use it for that. However, it might not be sufficient (1). In this case, you should not try to workaround it but suggest and improvement for GRASS parser instead.</div>
<div><br></div><div>(1) E.g. standard options [2] are defined in the library and modules are using them but they are not visible in the interface (since they are translated to more basic types), so some information is lost.</div>
<div><br></div><div>[1] <a href="http://grass.osgeo.org/programming7/gislib_cmdline_parsing.html">http://grass.osgeo.org/programming7/gislib_cmdline_parsing.html</a><br></div><div>[2] <a href="http://grass.osgeo.org/programming7/parser__standard__options_8c.html">http://grass.osgeo.org/programming7/parser__standard__options_8c.html</a><br>
</div><div><br></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto;">
Massimo.<br>
<div class=""><div class="h5"><br>
On Mar 10, 2014, at 12:02 PM, Glynn Clements <<a href="mailto:glynn@gclements.plus.com">glynn@gclements.plus.com</a>> wrote:<br>
<br>
><br>
> epi wrote:<br>
><br>
>> I guess the code behind the web-ui has to sanitize each text entry,<br>
>> will be this enough ?<br>
>><br>
>> A "sanitize inspection" on all the �input� coming from the web-ui<br>
>> can be performed and this will be part of the UI itself, not of the<br>
>> grass modules. with the aim to avoid people doing something like ..<br>
>> <a href="http://xkcd.com/327/" target="_blank">http://xkcd.com/327/</a> ;)<br>
><br>
> That's the main thing.<br>
><br>
> If you allow the user to e.g. provide names for maps, such names<br>
> should be limited to alphanumeric characters and limited to a<br>
> reasonable length.<br>
><br>
> If you allow the user to provide a list of inputs, limit both the<br>
> maximum number of items and the total length of the resulting textual<br>
> representation.<br>
><br>
> And so on.<br>
><br>
> In short, GRASS modules are designed for use by local users who<br>
> already have shell access, so there hasn't been any need to program<br>
> defensively. The OS prevents people from e.g. reading or writing files<br>
> which they aren't supposed to.<br>
><br>
> --<br>
> Glynn Clements <<a href="mailto:glynn@gclements.plus.com">glynn@gclements.plus.com</a>><br>
<br>
_______________________________________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-dev</a></div></div></blockquote></div><br></div></div>
</blockquote></div><br></div></div></div></body></html>