Vaclav, Is my understanding that the grass parsing code has to be “less restrictive” for the desktop app while the sanitizer has to be implemented on the web-ui side.
Develop the sanitizer on the web-ui code and do not touch the g.parser source code. The sanitizer code will following the guidelines found at the page [thanks] you pointed : “Complete Structure Members Table” but extending the restrictions to what Glynn suggested : size constraint, alphanumeric characters, maximum number of items in a list and more. this restriction will be true for the web-ui but not for the desktop gui hence the need to leave untouched the grass command line parser code. does this make sense for you ? Massimo. On Mar 10, 2014, at 10:32 PM, Vaclav Petras <wenzesl...@gmail.com> wrote: > > > > On Mon, Mar 10, 2014 at 10:19 PM, epi <massimodisa...@gmail.com> wrote: > Glynn, > > I understood the risk and I agree in toto with you. > For the web-ui interface we can define the rules for each kind of entry > and publish the rules/restriction on a help page . > Then when an invalid input exception is raised the ui will point the user to > read the rules page. > > 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. > > (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. > > [1] http://grass.osgeo.org/programming7/gislib_cmdline_parsing.html > [2] http://grass.osgeo.org/programming7/parser__standard__options_8c.html > > Massimo. > > On Mar 10, 2014, at 12:02 PM, Glynn Clements <gl...@gclements.plus.com> wrote: > > > > > epi wrote: > > > >> I guess the code behind the web-ui has to sanitize each text entry, > >> will be this enough ? > >> > >> A "sanitize inspection" on all the �input� coming from the web-ui > >> can be performed and this will be part of the UI itself, not of the > >> grass modules. with the aim to avoid people doing something like .. > >> http://xkcd.com/327/ ;) > > > > That's the main thing. > > > > If you allow the user to e.g. provide names for maps, such names > > should be limited to alphanumeric characters and limited to a > > reasonable length. > > > > If you allow the user to provide a list of inputs, limit both the > > maximum number of items and the total length of the resulting textual > > representation. > > > > And so on. > > > > In short, GRASS modules are designed for use by local users who > > already have shell access, so there hasn't been any need to program > > defensively. The OS prevents people from e.g. reading or writing files > > which they aren't supposed to. > > > > -- > > Glynn Clements <gl...@gclements.plus.com> > > _______________________________________________ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev >
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
