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

[Vaclav Petras]

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

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

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/f10958be/attachment-0001.html>