<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 10, 2014 at 11:04 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"><div style="word-wrap:break-word">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></div></div></blockquote><div>Yes, it does. For example, if module accepts parameter of type string, parser checks nothing in this case. However, web UI (1) should have the information (obtained from `--interface-description` XML) that it is a string and restrict the string to 255 characters (just an example).</div>
<div><br></div><div>(1) Actually, both the web GUI and something which is behind it on server side should have this check. In GUI, you want to tell the user that the input is invalid before sending the data for processing but also once data are at the server they should be checked again for case that somebody is not using the GUI but just sending the data to server side of the application (in order to bypass the GUI check). The web development framework may (or may not) solve these two steps for you at once.</div>
<div><br></div><div>Vaclav</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"><div style="word-wrap:break-word">
<div><div><div></div><div>Massimo.</div><div><div class="h5"><div><br><div><div>On Mar 10, 2014, at 10:32 PM, Vaclav Petras <<a href="mailto:wenzeslaus@gmail.com" target="_blank">wenzeslaus@gmail.com</a>> wrote:</div>
<br><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" target="_blank">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" target="_blank">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">
Massimo.<br>
<div><div><br>
On Mar 10, 2014, at 12:02 PM, Glynn Clements <<a href="mailto:glynn@gclements.plus.com" target="_blank">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" target="_blank">glynn@gclements.plus.com</a>><br>
<br>
_______________________________________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org" target="_blank">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></div></div></div></blockquote></div><br></div></div>