[GRASS-dev] GSoC 2014: GRAS GIS Web UI

[epi]

On Mar 11, 2014, at 12:22 AM, Vaclav Petras <wenzeslaus at gmail.com> wrote:

> 
> 
> 
> On Mon, Mar 10, 2014 at 11:04 PM, epi <massimodisasha at gmail.com> wrote:
> 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 ?
> 
> 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).
> 

That’s how we’d like to design the gui modules, using g.parser to generate the module descriptions and then use this information to generate the code to render each module. i Guess wx gui works this way.
PyQt does something similar with  .ui files generated in designer. In our case the .ui is the module description and  is generated by g.parser.

> (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.

I can see your idea of having the gui code to do a first check when the module is filled on the client and a second check server side when the instruction is received. thanks to share it.  
Essentially any command string received by the server will be parsed and checked for the validity of each entry (in regards of the module being executed) .
This make perfectly sense to me.


Massimo.


> 
> Vaclav
> Massimo.
> 
> On Mar 10, 2014, at 10:32 PM, Vaclav Petras <wenzeslaus at gmail.com> wrote:
> 
>> 
>> 
>> 
>> On Mon, Mar 10, 2014 at 10:19 PM, epi <massimodisasha at 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 <glynn at 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 <glynn at gclements.plus.com>
>> 
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140311/0d145b0e/attachment.html>